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-9 1D Redmine <p><em><font color="#505f79"> Created on 2021-05-20 08:30:59 by Vincent Le Brun. % Done: 100</font></em></p> <p>dans le dataset d'étoiles au format 'Roman', construit à partir des templates, un des spectres est classé en galaxies alors que le spectre est identique au template (à la résolution près), et il y a un modèle de galaxies avec une probabilismes de 1 (exactement) qui donc prend le dessus. A voir si c'est normal/attendu ?</p> REDMINE1D-9

[RM-6503] Evidences star/galaxies

Task Normal Done Done Redmine-Jira Migtation Redmine-Jira Migtation Fri, 4 Jun 2021 01:19:15 +0000 Tue, 13 Jun 2023 10:19:13 +0000 Tue, 13 Jun 2023 06:08:04 +0000 0 2 <p>Comment by Vincent Le Brun on 2021-05-20 09:05:44:<br/> Vincent Le Brun wrote:<br/> &gt; dans le dataset d'étoiles au format 'Roman', construit à partir des templates, un des spectres est classé en galaxies alors que le spectre est identique au template (à la résolution près), et il y a un modèle de galaxies avec une probabilité de 1 (exactement) qui donc prend le dessus. A voir si c'est normal/attendu ?</p> <p>Répertoire /net/CESAM/amazed/vlebrun/Roman/output</p> <p>spectre M_ukm2iii, <br/> le fit sur le modèle d'étoiles est parfait <span class="image-wrap" style=""><img src="https://pfspipe.ipmu.jp/jira/secure/attachment/15819/15819_Fit_star.png" style="border: 0px solid black" /></span> alors que celui avec les galaxies est moins bon de façon nette <span class="image-wrap" style=""><img src="https://pfspipe.ipmu.jp/jira/secure/attachment/15820/15820_Fit_gal.png" style="border: 0px solid black" /></span>, mais les évidences disent le contraire </p> <p>Comment by Didier Vibert on 2021-08-30 10:07:17:<br/> un indice d'explication possible:</p> <p>Les évidences, qui devraient être calculées en sommant les vraisemblances sur tout l'espace des paramètres, ne le font pas exactement et surtout ceci est dépendant de la méthode:</p> <div class='table-wrap'> <table class='confluenceTable'><tbody> <tr> <td class='confluenceTd'>param </td> <td class='confluenceTd'> z</td> <td class='confluenceTd'> template </td> <td class='confluenceTd'> ism </td> <td class='confluenceTd'> igm </td> <td class='confluenceTd'> amplitude </td> </tr> <tr> <td class='confluenceTd'> templatefiting </td> <td class='confluenceTd'> x</td> <td class='confluenceTd'>x</td> <td class='confluenceTd'>x</td> <td class='confluenceTd'>x</td> <td class='confluenceTd'>&nbsp;</td> </tr> </tbody></table> </div> <div class='table-wrap'> <table class='confluenceTable'><tbody> <tr> <td class='confluenceTd'>param </td> <td class='confluenceTd'> z</td> <td class='confluenceTd'> continuum template </td> <td class='confluenceTd'> continuum ism </td> <td class='confluenceTd'> continuum igm </td> <td class='confluenceTd'> continuum amplitude </td> <td class='confluenceTd'> linemodel tplratio </td> <td class='confluenceTd'> tpl ratio ism</td> <td class='confluenceTd'> tpl ratio emission amplitude </td> <td class='confluenceTd'> tpl ratio abs amplitude </td> <td class='confluenceTd'> linemodel em velocity </td> <td class='confluenceTd'> tpl ratio abs velocity </td> </tr> <tr> <td class='confluenceTd'> linemodelsolve</td> <td class='confluenceTd'>x</td> <td class='confluenceTd'>&nbsp;</td> <td class='confluenceTd'>&nbsp;</td> <td class='confluenceTd'>&nbsp;</td> <td class='confluenceTd'>&nbsp;</td> <td class='confluenceTd'> x</td> <td class='confluenceTd'>x </td> <td class='confluenceTd'>&nbsp;</td> <td class='confluenceTd'>&nbsp;</td> <td class='confluenceTd'>&nbsp;</td> </tr> </tbody></table> </div> <p>=&gt; il manque notoirement, pour le linemodel, la somme sur les templates de continus (déclinés avec la variation ism/igm) , ce qui donc déséquilibre la balance template_fitting/linemodel en faveur du linemodel.</p> <p>ce n'est pas simple à modifier, car les vraisemblances des modèles correspondants ne sont pas calculées (il faudrait refaire tourner le linemodel avec chaque continu)...</p> <p>Comment by Didier Vibert on 2022-02-21 11:01:13:</p> <h3><a name="r%C3%A9sultatsapr%C3%A8smodifs"></a>résultats après modifs</h3> <p>après développement de la prise en compte de tous les continus pour le calcul de l'évidence du linemodel, le problème montré dans cet exemple persiste.</p> <p>En fait, avec un classifieur basé sur le best chi2 on aurait le même pb:<br/> best_chi2_tpl_model_galaxy = 27171 (galaxy template fitting only)<br/> best_chi2_tpl_model_star = 26993<br/> best_chi2_full_model_galaxy = 25578 (galaxy linemodel with template fitting)</p> <p>(j'ai vérifié sous python que le caclul des chi2 effectué par amazed est correct, une fois les modèles sortis)</p> <p>=&gt; le pb vient du bruit du template d'étoile (je vais les lisser à la resol qui est dans le parameter.json pour voir)</p> <h3><a name="corrections%C3%A0effectuer%3A"></a>corrections à effectuer:</h3> <p>en cherchant à résoudre le pb, j'ai identifié plusieurs points supplémentaires à traiter:</p> <ul> <li>tplfitauto: avec ce mode, le modèle galaxy bascule sur un ajustement du modèle sur un spectre donné sans continu. =&gt; il ne devient plus possible de faire une classification bayesienne, que ce soit avec la comparaison des évidences ou des chi2, entre 2 modèles ajustés sur des données différentes.</li> </ul> <ul> <li>Une possibilité consiste à mettre en œuvre l'équivalent du tplfitauto dans le solver templatefitting, pas très difficile à implémenter avec la structure du code actuel, le templatefittingSolve est prévu pour fonctionner en mode sans continu, par soustraction du continu median à la fois sur le spectre et sur le template. Est-ce que ça a un sens, avec les template d'étoile ?</li> </ul> <ul> <li>il faudra ensuite une heuristique, pour déterminer la classif si les modèles ne basculent pas tous sans continu</li> </ul> <ul> <li>évidence star, en mode "bestchi2"</li> </ul> <p>la pdf du modèle étoile n'est habituellement pas obtenue par marginalisation sur le template, mais correspond à la pdf du meilleur template. (option pdfcombination="bestchi2")<br/> et donc l'évidence utilisée est la somme de cette PDF sur z. Il faudrait sommer aussi sur les templates pour l'évidence servant à la classification.</p> <p>=&gt; rajouter une variable 'valEvidenceMargLog' à la classe `CPdfMargZLogResult` qui contient la PDF (et qui porte mal son nom, car ce n'est pas nécessairement "marg"), et la calculer systématiquement qq soit l'option pfdcombination</p> <p>Comment by Vincent Le Brun on 2022-02-22 08:31:58:<br/> Didier Vibert wrote in #note-18:</p> <p>&gt; h3. corrections à effectuer:<br/> &gt; <br/> &gt; en cherchant à résoudre le pb, j'ai identifié plusieurs points supplémentaires à traiter:<br/> &gt; <br/> &gt; * tplfitauto: avec ce mode, le modèle galaxy bascule sur un ajustement du modèle sur un spectre donné sans continu. =&gt; il ne devient plus possible de faire une classification bayesienne, que ce soit avec la comparaison des évidences ou des chi2, entre 2 modèles ajustés sur des données différentes. <br/> &gt; <br/> &gt; * Une possibilité consiste à mettre en œuvre l'équivalent du tplfitauto dans le solver templatefitting, pas très difficile à implémenter avec la structure du code actuel, le templatefittingSolve est prévu pour fonctionner en mode sans continu, par soustraction du continu median à la fois sur le spectre et sur le template. Est-ce que ça a un sens, avec les template d'étoile ?<br/> non le continu est fondamental pour les étoiles...<br/> &gt; <br/> &gt; * il faudra ensuite une heuristique, pour déterminer la classif si les modèles ne basculent pas tous sans continu<br/> &gt; <br/> &gt; * évidence star, en mode "bestchi2" <br/> &gt; <br/> &gt; la pdf du modèle étoile n'est habituellement pas obtenue par marginalisation sur le template, mais correspond à la pdf du meilleur template. (option pdfcombination="bestchi2")<br/> &gt; et donc l'évidence utilisée est la somme de cette PDF sur z. Il faudrait sommer aussi sur les templates pour l'évidence servant à la classification.<br/> &gt; <br/> &gt; =&gt; rajouter une variable 'valEvidenceMargLog' à la classe `CPdfMargZLogResult` qui contient la PDF (et qui porte mal son nom, car ce n'est pas nécessairement "marg"), et la calculer systématiquement qq soit l'option pfdcombination</p> <p>Comment by Didier Vibert on 2022-02-22 08:45:48:<br/> Vincent Le Brun wrote in #note-19:<br/> &gt; Didier Vibert wrote in #note-18:<br/> &gt; &gt; * Une possibilité consiste à mettre en œuvre l'équivalent du tplfitauto dans le solver templatefitting, pas très difficile à implémenter avec la structure du code actuel, le templatefittingSolve est prévu pour fonctionner en mode sans continu, par soustraction du continu médian à la fois sur le spectre et sur le template. Est-ce que ça a un sens, avec les template d'étoile ?<br/> &gt; non le continu est fondamental pour les étoiles...</p> <p>Certes, mais la question se pose lorsque le continu est dégradé par la décontamination par exemple. Ce que je propose, c'est de faire comme pour le linemodel galaxy: on fait du template fitting pour les étoiles, s'il existe un template avec un z donnant un fit avec amplitude &gt; -5 sigma, pas de pb on ne change rien, et la classif devra classer en star si le problème de continu neg ne survient que pour le modèle galaxy. Inversement, si aucuns template d'étoile, à aucun z, ne donne une amp &gt; -5 sigma, alors on passe en mode sans continu (on filtre les template et le spectre), Il ne reste pas de raies d'absorption dans les templates qui peuvent servir ? <br/> Si tu dis que non, alors on ne sort pas solution pour les étoiles et la classif n'est plus un pb, on décrète le type galaxy systématiquement... Reste à voir pour les QSO ...</p> <p>autre possibilité: amp &lt; -k sigma peut survenir pour plusieurs raisons, une étant un continu moyen (une constante) mal soustraite, donc une autre alternative serait, au lieu de soustraire un continu médian, de ne soustraire qu'une constante (au template et au spectre). Rmq ce fonctionnement est possible à la fois pour le fullmodel et le templatefiting, et n'est pas exclusif de la soustraction du continu médian: ça rallonge juste les calculs...</p> <p>Comment by Vincent Le Brun on 2022-02-22 09:35:08:<br/> Didier Vibert wrote in #note-20:</p> <p>&gt; Certes, mais la question se pose lorsque le continu est dégradé par la décontamination par exemple. Ce que je propose, c'est de faire comme pour le linemodel galaxy: on fait du template fitting pour les étoiles, s'il existe un template avec un z donnant un fit avec amplitude &gt; -5 sigma, pas de pb on ne change rien, et la classif devra classer en star si le problème de continu neg ne survient que pour le modèle galaxy. Inversement, si aucuns template d'étoile, à aucun z, ne donne une amp &gt; -5 sigma, alors on passe en mode sans continu (on filtre les template et le spectre), Il ne reste pas de raies d'absorption dans les templates qui peuvent servir ? <br/> &gt; Si tu dis que non, alors on ne sort pas solution pour les étoiles et la classif n'est plus un pb, on décrète le type galaxy systématiquement... Reste à voir pour les QSO ...<br/> si il y en a, ce sont les memes que dans le linemodel galaxy, sauf que les solutions à z=0 ne sont pas gérées en mode galaxy...<br/> &gt; autre possibilité: amp &lt; -k sigma peut survenir pour plusieurs raisons, une étant un continu moyen (une constante) mal soustraite, donc une autre alternative serait, au lieu de soustraire un continu médian, de ne soustraire qu'une constante (au template et au spectre). Rmq ce fonctionnement est possible à la fois pour le fullmodel et le templatefiting, et n'est pas exclusif de la soustraction du continu médian: ça rallonge juste les calculs...<br/> dans le cas d'un continu de forme compliquée, est ce qu'on est sur d'avoir une bonne estimation de la constante en question? la 'vraie' moyenne du spectre peut ne pas être triviale à évaluer</p> <p>Comment by Didier Vibert on 2022-02-24 08:34:14:<br/> je confirme. en lissant les templates d'étoile à la résolution 300, on bascule avec une proba de 1. pour les étoiles </p> <ul> <li>avec la version develop<br/> &lt;pre&gt;<br/> Info: Found galaxy LogEvidence: -4.138208e+03<br/> Info: Found stellar LogEvidence: 6.228568e+03<br/> Info: Setting object type: S<br/> &lt;/pre&gt;</li> </ul> <ul> <li>avec cette branche (dans laquelle les étoiles sont un peu défavorisées car on ne somme pas encore sur les templates)<br/> &lt;pre&gt;<br/> Info: Found galaxy LogEvidence: -4.141253e+03<br/> Info: Found stellar LogEvidence: 6.228568e+03<br/> Info: Setting object type: S<br/> &lt;/pre&gt;</li> </ul> <p>où on voit que l'effet de compter tous les template de continu ne baisse pas violemment l'évidence: facteur 20 (~ln(3) sur l'évidence.</p> <p>Comment by Didier Vibert on 2022-03-08 15:03:15:<br/> MR: <a href="https://gitlab.lam.fr/CPF/cpf-redshift/-/merge_requests/289" class="external-link" rel="nofollow">https://gitlab.lam.fr/CPF/cpf-redshift/-/merge_requests/289</a></p> <p>Comment by Pierre-yves Chabaud on 2022-03-10 15:54:11:<br/> Merged into @develop@ : @726fbe9@</p> Development Rank 0|zzs78w: