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-225 1D Redmine <p><em><font color="#505f79"> Created on 2021-05-13 08:17:48 by Vincent Le Brun. % Done: 0</font></em></p> <p>dans la simulation Euclid COSMOS-EL 40% des erreurs sont des mismatch's H-alpha-OII. Si on utilise le prior strong, on baisse la pureté en forçant H-alpha plutôt que les raies faibles des galaxies à faible z (SIII, ArI, Paschen...<img class="emoticon" src="https://pfspipe.ipmu.jp/jira/images/icons/emoticons/wink.png" height="16" width="16" align="absmiddle" alt="" border="0"/>, un moyen serait un prior qui favorise H-alpha si la solution utilise une seule raie strong (OII). Est ce que c'est possible ?</p> REDMINE1D-225

[RM-6497] Prior 'H-alpha if strong line'

Task Normal Done Done Redmine-Jira Migtation Redmine-Jira Migtation Wed, 5 Jul 2023 06:36:33 +0000 Fri, 12 Jan 2024 18:46:03 +0000 Fri, 12 Jan 2024 18:46:03 +0000 0 1 <p>Comment by Didier Vibert on 2021-05-17 09:06:17:<br/> note: j 'ai basculé cette issue dans le sous-projet euclid-dev</p> <p>je pense que c'est possible. Pour résumer, tu veux un prior du style: si dans un modèle à un z donné il y a une raie strong autre que Halpha alors on pénalise cette solution. Si pas de raie strong du tout on ne change pas la vraisemblance.</p> <p>on peut essayer, mais j'ai peur qu'une partie du gain du prior strong disparaisse: tu vas effectivement récupérer les solutions bas z avec l'identification SIII, etc. mais du coup tu vas aussi confondre des vrais Ha pour ces raies faibles ? =&gt; à tester.</p> <p>Il faudrait aussi tester avec d'autres valeurs du prior strong. Aujourd'hui on met 1e-3 comme paramètre (qui est la valeur de la proba si pas de raie strong, 1.0 étant la valeur s raie strong, le tout étant normalisé de telle sorte que l'intégrale de la proba sur le range z évalué soit égale à 1.0)</p> <h2><a name="R%C3%A9capdespriorsdispoaujourd%27hui%3A"></a>Récap des priors dispo aujourd'hui:</h2> <p>tous ces priors peuvent se combiner entre eux (multiplication des proba, et normalisation de l'intégrale sur z du total à 1.0)</p> <p>1. N(z) Pozetti, paramètre @linemodelsolve.linemodel.euclidnhaemittersStrength@ gouverne la force du prior par rapport à la vraisemblance (facteur multiplicatif du log du prior)</p> <p>2. strong lines, paramètre @linemodelsolve.linemodel.stronglinesprior@, introduit une pénalisation de la vraisemblance si le modèle(z) n'a pas de raies strong (absence dans l'intervalle de longueur d'onde observé ou mesurée à zéro). Le prior pi(z) est égal à 1.0 si on mesure une raie strong et est égal à la valeur du paramètre si pas de raies strong, l'intégrale de la proba est ensuite normalisée à 1.0.</p> <p>3. Ha, paramètre @linemodelsolve.linemodel.haprior@, introduit une pénalisation de la vraisemblance (idem au prior strong lines) si le modèle(z) n'a pas la raie Ha</p> <p>4. <del>N lines above SNR (actuellement désactivé dans le code), pénalise les solutions à un z donné ayant moins de 2 raies strong pour lesquelles le SNR mesuré est &gt;3.5</del> </p> <p>En plus de ces priors P(z), il est possible dans le cas du linemodel template-ratio, et de template fitting, d'appliquer des priors sur les autres paramètres, par bin de z :</p> <ul> <li>template de continus: poids du template, amplitude du template, prior sur le coeff Ebmv, prior sur l'igm (poids des 7 courbes d'extinctions)</li> <li>linemodel template-ratios: en plus des priors sur les template de continu, poids du template-ratio, amplitude du template-ratio, prior sur l'igm (poids des 7 courbes d'extinctions)</li> </ul> <p>Comment by Vincent Le Brun on 2021-05-17 09:14:32:<br/> Didier Vibert wrote in #note-1:<br/> &gt; note: j 'ai basculé cette issue dans le sous-projet euclid-dev<br/> &gt; <br/> &gt; je pense que c'est possible. Pour résumer, tu veux un prior du style: si dans un modèle à un z donné il y a une raie strong autre que Halpha alors on pénalise cette solution. Si pas de raie strong du tout on ne change pas la vraisemblance.</p> <p>Plus exactement si dans un modèle il y a un raie strong autre que Ha, on privilégie Halpha (sinon se contenter de pénaliser le modèle va effectivement faire sortir des modèles à raie faible)<br/> &gt; <br/> &gt; on peut essayer, mais j'ai peur qu'une partie du gain du prior strong disparaisse: tu vas effectivement récupérer les solutions bas z avec l'identification SIII, etc. mais du coup tu vas aussi confondre des vrais Ha pour ces raies faibles ? =&gt; à tester.<br/> d'ou ma suggestion au dessus<br/> &gt; <br/> &gt; Il faudrait aussi tester avec d'autres valeurs du prior strong. Aujourd'hui on met 1e-3 comme paramètre (qui est la valeur de la proba si pas de raie strong, 1.0 étant la valeur s raie strong, le tout étant normalisé de telle sorte que l'intégrale de la proba sur le range z évalué soit égale à 1.0)</p> <p>&gt; <br/> &gt; h2. Récap des priors dispo aujourd'hui:<br/> &gt; <br/> &gt; tous ces priors peuvent se combiner entre eux (multiplication des proba, et normalisation de l'intégrale sur z du total à 1.0)<br/> &gt; <br/> &gt; 1. N(z) Pozetti, paramètre @linemodelsolve.linemodel.euclidnhaemittersStrength@ gouverne la force du prior par rapport à la vraisemblance (facteur multiplicatif du log du prior)<br/> &gt; <br/> &gt; 2. strong lines, paramètre @linemodelsolve.linemodel.stronglinesprior@, introduit une pénalisation de la vraisemblance si le modèle(z) n'a pas de raies strong (absence dans l'intervalle de longueur d'onde observé ou mesurée à zéro). Le prior pi(z) est égal à 1.0 si on mesure une raie strong et est égal à la valeur du paramètre si pas de raies strong, l'intégrale de la proba est ensuite normalisée à 1.0.<br/> &gt; <br/> &gt; 3. Ha, paramètre @linemodelsolve.linemodel.haprior@, introduit une pénalisation de la vraisemblance (idem au prior strong lines) si le modèle(z) n'a pas la raie Ha<br/> &gt; <br/> &gt; 4. <del>N lines above SNR (actuellement désactivé dans le code), pénalise les solutions à un z donné ayant moins de 2 raies strong pour lesquelles le SNR mesuré est &gt;3.5</del> <br/> &gt; <br/> &gt; En plus de ces priors P(z), il est possible dans le cas du linemodel template-ratio, et de template fitting, d'appliquer des priors sur les autres paramètres, par bin de z :<br/> &gt; * template de continus: poids du template, amplitude du template, prior sur le coeff Ebmv, prior sur l'igm (poids des 7 courbes d'extinctions)<br/> dans le cadre de VIPERS j'avais relevé que le poids du continu était trop fort. est ce que le paramètre est dispo dans les parameters.json actuels?<br/> &gt; * linemodel template-ratios: en plus des priors sur les template de continu, poids du template-ratio, amplitude du template-ratio, prior sur l'igm (poids des 7 courbes d'extinctions)</p> <p>Comment by Didier Vibert on 2021-05-17 11:05:38:<br/> Vincent Le Brun wrote in #note-2:<br/> &gt; Didier Vibert wrote in #note-1:<br/> &gt; &gt; je pense que c'est possible. Pour résumer, tu veux un prior du style: si dans un modèle à un z donné il y a une raie strong autre que Halpha alors on pénalise cette solution. Si pas de raie strong du tout on ne change pas la vraisemblance.<br/> &gt; <br/> &gt; Plus exactement si dans un modèle il y a une raie strong autre que Ha, on privilégie Halpha (sinon se contenter de pénaliser le modèle va effectivement faire sortir des modèles à raie faible)</p> <p>ce qu'on écrit, ce sont des p(z), donc on renforce à certain z, en fonction d'une ou pls conditions, et symétriquement on pénalise les z avec la condition inverse. Quand tu dis "si dans un modèle il y a une raie strong autre que Ha, on privilégie Halpha " tu parles de 2 z différents. Je ne vois pas bien ce que tu entends par on privilégie Ha: tu privilégies un autre modèle (ie avec un z différent)</p> <p>Ce que tu veux, si je comprends bien, c'est éviter de pénaliser les bas z sans raies strongs (pour laisser sa chance à SIII etc.) =&gt; on peut faire ça, <br/> ça donnerait:</p> <ul> <li>z tq pas de raies strong observables ou observée =&gt; prior fort</li> <li>z tq raie strong Ha =&gt; prior fort</li> <li>z tq raie strong autre que Ha =&gt; prior faible</li> </ul> <p>Mais, dans ce cas je maintiens que la présence d'une raie dans le spectre risque de conduire à des solutions raies faible (au moins pour une partie d'entre eux) au détriment des solutions Ha. À moins que dans le cas des raies faibles, on s'attende à avoir plusieurs raies faibles à peu près de même niveau ensemble ce qui évitera de les confondre avec Ha.</p> <p>rmq: au lieu de construire un prior à 2 niveaux, on pourrait le faire à 3 niveaux (ie ne pas donner le même poids à Ha et no-strong</p> <p>&gt; &gt; En plus de ces priors P(z), il est possible dans le cas du linemodel template-ratio, et de template fitting, d'appliquer des priors sur les autres paramètres, par bin de z :<br/> &gt; &gt; * template de continus: poids du template, amplitude du template, prior sur le coeff Ebmv, prior sur l'igm (poids des 7 courbes d'extinctions)<br/> &gt; dans le cadre de VIPERS j'avais relevé que le poids du continu était trop fort. est ce que le paramètre est dispo dans les parameters.json actuels?</p> <p>Il s'agit des poids relatifs des templates entre eux, et non pas du poid du template de continu par rapport au linemodel... Le paramètre est disponible, il s'agit du chemin d'un répertoire dans lequel doivent se trouver des fichiers contenant l'ensemble des poids pour tous les paramètres et tout les bins de z, dans un format spécifique. </p> <p>Pour diminuer l'impact du continu sur la vraissemblance, il faudrait plutôt rentrer une connaissance du bruit et de l'incertitude: le continu a un poids trop fort car le spectre contient des systématiques basse fréquence, qui ne sont pas modélisées.<br/> Plusieurs options:</p> <ul> <li>on ne sait pas les modéliser: il faut les soustraire du spectre pour s'en affranchir, quitte à perdre de l'info (=&gt; c'est ce qu'on fait en soustrayant un continu par filtrage)</li> <li>on sait les modéliser, et c'est déterministe (non stochastique) et paramétré et donc c'est meilleur de les rajouter au modèle plutôt que d'essayer de les soustraire en pré-processing.</li> <li>on sait les modéliser et c'est stochastique: il faut rajouter cette infos dans la description du bruit.</li> </ul> <p>Typiquement, actuellement, le fait de donner une variance par pixel sans corrélation, contribue à donner un poids fort à la forme bf du continu. Si on indique que le bruit possède une composante bf, donc une corrélation pixel à grande échelle, naturellement, le fit accordera moins d'importance à la forme à grande échelle des templates de continu tout en conservant l'adéquation à ses features (raie en absorption, break, etc.)</p> <p>Comment by Pierre-yves Chabaud on 2022-09-01 09:56:15:<br/> Refaire le test sur les nouvelles données EL2020 en utilisant la 0.36</p> <p>Comment by Didier Vibert on 2024-01-12 16:53:12:<br/> toujours d'actualité, pour faire quoi exactement ? </p> <p>Comment by Vincent Le Brun on 2024-01-12 16:55:11:<br/> je crois que les progrès sur la reliability on rendu ce truc obsolète, et en plus ça rend les choses moins claires au final. On ferme et on verra à l'usage si on en a besoin</p> Development Rank 0|zzsycf: