https://pfspipe.ipmu.jp/jira This file is an XML representation of an issue en-us 8.3.4 803005 13-09-2019 https://pfspipe.ipmu.jp/jira/browse/REDMINE1D-371 1D Redmine <p><em><font color="#505f79"> Created on 2023-12-13 09:00:50 by Vincent Le Brun. % Done: 100</font></em></p> <p>dans les données EDR2 PFS, il y a plusieurs spectres ou la valeur calculée de snrOII est clairement fausse<br/> /net/CESAM/amazed/aallaoui/pfs_weekly/edr/0.46.0/edr2_20231203_bis/<br/> objet 00010-00001-1,1-0099546300001228-006-0x6e85dbfdd0e3cf63<br/> snrOII est donné à 722 alors qu'on a ça<br/> <span class="image-wrap" style=""><img src="https://pfspipe.ipmu.jp/jira/secure/attachment/17131/17131_00010-00001-1%2C1-0099546300001228-006-0x6e85dbfdd0e3cf63_spec.png" style="border: 0px solid black" /></span></p> REDMINE1D-371

[RM-8541] Valeurs snrOII problématiques

Task Normal Done Done Redmine-Jira Migtation Redmine-Jira Migtation Wed, 13 Dec 2023 18:17:51 +0000 Tue, 6 Feb 2024 18:25:03 +0000 Tue, 6 Feb 2024 18:25:03 +0000 0 1 <p>Comment by Didier Vibert on 2023-12-13 18:42:37:<br/> Bon, une explication possible.<br/> Les SNR provenant du fit Gaussien en mode ratio ne sont pas très exploitables. En effet, ils sont basés sur l´incertitude de la mesure d'une amplitude unique (celle du modèle avec toutes les raies fixées), qui est assez contrainte et donc précise. Le SNR est donc trompeur. Si les ratios étaient justes, ce SNR serait bon. Il faudrait avoir des variances sur les ratios pour retrouver quelque chose de plus plausible.<br/> En attendant le SNR directIntegration est correct: 2.2 </p> <p>Comment by Vincent Le Brun on 2023-12-14 07:51:24:<br/> du coup je suggère de ne pas les calculer et encore moins de les afficher. Cela dit certains flux ont l'air très faux aussi (cf #8544)</p> <p>Comment by Didier Vibert on 2023-12-15 10:57:00:<br/> Après vérif, les SNR (en mode template ratio) de toutes les raies sont bien les mêmes (ils ne sont pas scalés par les amplitudes des ratios, car ce scaling intervient au numérateur et dénominateur du SNR, ie l'amplitude et son incertitude sont scalés par le ratio). Si on run en extended results, les ratios amplitude/amplitude_uncertainties sont bien les mêmes et correspondent au ratio amplitude_globale/amplitude_globale_uncertainty. <br/> D'ailleurs cette dernière quantité n'est pas sortie, je rajoute du code pour ça.<br/> En revanche les snr en flux ne donnent pas la même chose, car la largeur est dépendante de la longueur d'onde, même avec une LSF constante (sigma constant) à cause du terme dispersion de vitesse qui est constant en vitesse et donne donc des largeurs en longueur d'onde dépendantes de la longueur d'onde.</p> <p>Ensuite à voir si on veut conserver ces quantités individuelles par raies dans le cas des templates-ratio, vu qu'elles n'ont pas grand sens... en revanche le SNR venant du fit global de toutes les raies a un sens.</p> <p>Comment by Vincent Le Brun on 2023-12-15 11:25:23:<br/> je suis partisan de ne pas calculer ces valeurs individuelles vu qu'elles n'ont pas de sens physique</p> <p>Comment by Didier Vibert on 2023-12-19 16:36:25:</p> <ul> <li>J'ai supprimé des output (mis à NAN) les incertitudes des flux par raie dans le cas tplratio.</li> <li>J'ai ajouté l'incertitude et le SNR de l'amplitude globale du tplratio</li> <li>J'ai ajouté le SNR par raie dans les cas rules ou free (il y avait déjà le flux et l'incertitude), mais ça évite de faire le calcul et permet des filtrages avec vizu</li> </ul> <p>Comment by Didier Vibert on 2023-12-21 12:15:13:<br/> MR: <a href="https://gitlab.lam.fr/CPF/cpf-redshift/-/merge_requests/571" class="external-link" rel="nofollow">https://gitlab.lam.fr/CPF/cpf-redshift/-/merge_requests/571</a></p> <p>Comment by Didier Vibert on 2024-01-26 10:32:41:<br/> some small modifications suggested by @aallaoui </p> <p>Comment by Pierre-yves Chabaud on 2024-01-31 16:04:11:<br/> Merged into @develop@ (@c84e9cf8@)</p> Development Rank 0|zzt0nb: