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-211 1D Redmine <p><em><font color="#505f79"> Created on 2022-12-07 08:15:52 by Vincent Le Brun. % Done: 100</font></em></p> <p>J'ai tenté de contraindre le modele QSO avec la règle 'strongweak' et ça ne parait pas très efficace, par exemple pour cet objet <br/> <span class="error">Unable to render embedded object: File (QSO_strongweakrule/png) not found.</span> <br/> pour lequel il n'y a aucune raie forte dans la solution. Il faudrait vérifier comment sont calculé les rapports de raies, faire en sorte que la raie du spectre soit identifiée par une raie forte</p> REDMINE1D-211

[RM-7706] Vérifier la règle 'strongweak'

Task Normal Done Done Redmine-Jira Migtation Redmine-Jira Migtation Wed, 5 Jul 2023 05:22:50 +0000 Fri, 7 Jul 2023 17:06:34 +0000 Fri, 7 Jul 2023 17:06:34 +0000 0 1 <p>Comment by Vincent Le Brun on 2022-12-07 08:16:55:<br/> <span class="image-wrap" style=""><img src="https://pfspipe.ipmu.jp/jira/secure/attachment/16133/16133_QSO_strongweakrule.png" style="border: 0px solid black" /></span></p> <p>Comment by Vincent Le Brun on 2022-12-07 08:50:42:<br/> répertoire /net/CESAM/amazed/vlebrun/Euclid_FORNAX_DEEP_ELC2020/output_0.36_QSOlm</p> <p>Comment by Didier Vibert on 2023-01-18 17:57:44:<br/> Finalement ça me parait normal au vu de ce qui est codé. À voir s’il faut changer le comportement:</p> <p>la règle @strongweak@ (comme toutes les autres règles) se contente de modifier les amplitudes des raies pour respecter la contrainte.<br/> Dans le cas @strongweak@, on force les amplitudes weak à avoir une amplitude inférieure ou égale à l'amplitude strong la plus forte, si aucune raie strong n'est observée, rien ne se passe.</p> <p>Donc tu es dans le cas où, pour un z donné, il n'y a pas de raie strong. Si tu veux pénaliser ces cas là, il faut utiliser le prior @stronglinesprior@</p> <p>Comment by Vincent Le Brun on 2023-01-19 09:35:42:<br/> OK je vais tester avec le prior, par contre la règle serait plus cohérente si les raies 'weak' étaient toute plus faibles que la raie 'strong' la plus faible.</p> <p>Comment by Didier Vibert on 2023-01-19 09:45:37:<br/> Vincent Le Brun wrote in #note-6:<br/> &gt; OK je vais tester avec le prior, par contre la règle serait plus cohérente si les raies 'weak' étaient toute plus faibles que la raie 'strong' la plus faible.</p> <p>ok on peut effectivement changer la règle.</p> <p>Comment by Fanny Dufresne on 2023-06-01 14:55:33:<br/> Au delà du changement raies weak toutes plus faibles que la raie strong la plus faible vs strong, j'ai tenté de comprendre un peu ce qu'il se passe dans le code pour cette "rule strong higher than weak":</p> <p>Ce qui est actuellement fait: <br/> &lt;pre&gt;<br/> 1. on cherche la raie strong avec l'amplitude la plus forte dans l'ensemble des raies de l'ensemble des éléments (un élement c'est un ensemble de raies comme défini dans le catalog)<br/> 2. on boucle sur les éléments<br/> a. On vérifie qu'on est bien dans le cas du type de raies qu'on souhaite (émission/absorption)<br/> b. On boucle sur les raies<br/> i. On vérifie qu'on est bien dans lambda range souhaité<br/> ii. Dans le cas d'une line weak:</p> <ul class="alternate" type="square"> <li>Si son amplitude &gt; amplitude raie strong + erreur :</li> <li>Je diminue son amplitude à la limite souhaitée (amplitude raie strong + erreur)</li> <li>Je diminue l'amplitude de TOUTES les raies de l'élément, d'un ratio similaire à celle de la ligne précédente<br/> &lt;/pre&gt;</li> </ul> <p>Est-ce que c'est bien ça qu'on souhaite faire ?<br/> De ce que je comprends, ce qui me paraît étonnant:</p> <ul class="alternate" type="square"> <li>Vu qu'on diminue l'amplitude de toutes les raies, on diminue l'amplitude des raies strong également, et du coup ça ne nous fait pas beaucoup avancer ?</li> <li>Est-ce qu'on veut bien considérer l'erreur (de la raie strong uniquement) dans la comparaison des amplitudes ? amplitude raie &lt; amplitude raie strong + erreur ça ne me paraît pas très "équitable" comme comparaison</li> </ul> <p>Comment by Vincent Le Brun on 2023-06-01 15:41:59:<br/> je crois que je comprends, on est dans le cas du linemodel 'free' c'est à dire que les amplitudes individuelles des raies sont totalement libre... et dans le cas que je présente il n'y a aucune raie forte dans le lambda range pour cette solution. Donc je ne sais pas quelle comparaison est faite là<br/> &lt;pre&gt;</p> <ul class="alternate" type="square"> <li>Si son amplitude &gt; amplitude raie strong + erreur :<br/> &lt;/pre&gt;</li> </ul> <p>Comment by Didier Vibert on 2023-06-01 17:59:01:<br/> Vincent Le Brun wrote in #note-10:<br/> &gt; je crois que je comprends, on est dans le cas du linemodel 'free' c'est à dire que les amplitudes individuelles des raies sont totalement libre... et dans le cas que je présente il n'y a aucune raie forte dans le lambda range pour cette solution. Donc je ne sais pas quelle comparaison est faite là<br/> &gt; <span class="error">&#91;...&#93;</span></p> <p>&lt;pre&gt;<br/> amplitude &gt; amplitude raie strong + erreur<br/> &lt;/pre&gt;</p> <p>la comparaison est explicite non ? </p> <ul> <li>amplitude: amplitude mesurée de la raie considérée (le profil est a*exp-0.5(lbda - lbda_ref)^2/width^2 où a est l'amplitude )</li> <li>amplitude raie strong -&gt; amplitude de la plus forte rais strong observée</li> <li>erreur: racine-carrée de la variance (1 sigma uncertainty) estimée de l'amplitude de la raie considérée</li> </ul> <p>Comment by Didier Vibert on 2023-06-01 18:24:48:<br/> Fanny Dufresne wrote in #note-9:<br/> &gt; Au delà du changement raies weak toutes plus faibles que la raie strong la plus faible vs strong, j'ai tenté de comprendre un peu ce qu'il se passe dans le code pour cette "rule strong higher than weak":<br/> &gt; <br/> &gt; Ce qui est actuellement fait: <br/> &gt; <span class="error">&#91;...&#93;</span></p> <p>ok c'est bien ça. Juste pour info, un "element" est un ensemble de raies pour lesquelles une amplitude unique est fittée (ie toutes les raies d'un élément ont des rapports de raies fixés, et on fitte une amplitude unique pour un "multi" profil contenant l'ensemble des raies avec leur ratio respectifs). Dans le cas d'un "template ratio" ll y a un seul élément pour toutes les raies en emission (et un autre pour les raies en absorption). Mais l'application des règles ne concerne pas le cas "template ratio". Dans le cas linemodel "free" (ce qui veut dire pas de template-ratio), avec ou sans application de règles, la plupart des éléments n'ont qu'une seule raie, sauf quelques doublets fixés.</p> <p>&gt; Est-ce que c'est bien ça qu'on souhaite faire ?<br/> oui c'est ce qu'on souhaite faire, avec la modif proposée par cette issue de prendre la raie strong la plus faible observée plutôt que la plus forte.</p> <p>&gt; De ce que je comprends, ce qui me paraît étonnant:<br/> &gt; - Vu qu'on diminue l'amplitude de toutes les raies, on diminue l'amplitude des raies strong également, et du coup ça ne nous fait pas beaucoup avancer ?<br/> lorsqu'on "corrige" un élément, donc lorsque qu'on décide de diminuer son amplitude, nécessairement on conserve les ratio dans l'élément et on modifie donc proportionnellement toutes les amplitudes de l'élément. <br/> Ce qui t'étonne peut-être c'est la possibilité d'avoir un élément qui contiennent une raie strong et une raie weak ? <br/> Ce cas n’existe pas, mais c'est vrai que c'est implicite et que le code ne se protège pas contre ça. Si tu veux, on peut rajouter une condition pour ne corriger que les elt qui ne contiennent aucune raie strong.</p> <p>&gt; - Est-ce qu'on veut bien considérer l'erreur (de la raie strong uniquement) dans la comparaison des amplitudes ? amplitude raie &lt; amplitude raie strong + erreur ça ne me paraît pas très "équitable" comme comparaison</p> <p>Alain avait testé plusieurs façons de faire, on peut en reparler et inclure l'incertitude sur la raie à corriger éventuellement cf code commenté dans la fonction: <a href="https://gitlab.lam.fr/CPF/cpf-redshift/-/blob/release-0.42/RedshiftLibrary/src/lib/line/ruleStrongHigherThanWeak.cpp#L94" class="external-link" rel="nofollow">https://gitlab.lam.fr/CPF/cpf-redshift/-/blob/release-0.42/RedshiftLibrary/src/lib/line/ruleStrongHigherThanWeak.cpp#L94</a></p> <p>Comment by Fanny Dufresne on 2023-06-02 12:50:30:<br/> Ok génial merci pour toutes ces explications !</p> <p>Comment by Didier Vibert on 2023-06-19 09:56:03:<br/> MR: <a href="https://gitlab.lam.fr/CPF/cpf-redshift/-/merge_requests/504" class="external-link" rel="nofollow">https://gitlab.lam.fr/CPF/cpf-redshift/-/merge_requests/504</a></p> <p>Comment by Pierre-yves Chabaud on 2023-06-30 12:25:03:<br/> Merged into @develop@ (@9ca3c356@)</p> Development Rank 0|zzsy9b: