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-166 1D Redmine <p><em><font color="#505f79"> Created on 2021-11-26 15:28:39 by Vincent Le Brun. % Done: 0</font></em></p> <p>pour voir si on peut éviter les pixels individuels comme dans Euclid une solution serait de pénaliser les résultats avec vitesse nulle (paramètre VelocityEmission), il faudrait créer le prior correspondant.</p> REDMINE1D-166

[RM-6843] Créer un prior sur la vitesse

Task Normal Open Unresolved Redmine-Jira Migtation Redmine-Jira Migtation Tue, 13 Jun 2023 06:03:45 +0000 Wed, 14 Jun 2023 17:28:36 +0000 0 2 <p>Comment by Mira Sarkis on 2022-11-04 09:58:03:<br/> Le plot suivant, fourni par Vincent, représente le problème des pixels chauds (ou bruit) identifiés en tant que raie d'émission à flux très élevé et pris pour une raie Halpha surtout pour des vitesses &gt;0.<br/> <span class="image-wrap" style=""><img src="https://pfspipe.ipmu.jp/jira/secure/attachment/15840/15840_Spike.png" style="border: 0px solid black" /></span></p> <p>L'idée (en gros) est de fitter avec des vitesses d'émission nulles et pénaliser les raies dont la vitesse d'emission estimée est à 0.</p> <p>Spécifications pour l'implémentation, à discuter:</p> <ul> <li>dans dataset-parameters, ajouter un paramètre `linemodel.emvelocityforceprior` mis à true pour pénaliser les vitesses nulles.<br/> Note qu'il faut avoir : `linemodel.emvelocityfitmin = 0` pour que `linemodel.emvelocityforceprior` s'applique vraiment.</li> <li>coté lib: à spécifier avec Didier</li> </ul> <p>Comment by Didier Vibert on 2022-11-07 08:21:09:<br/> Mira Sarkis wrote in #note-9:<br/> &gt; Le plot suivant, fourni par Vincent, représente le problème des pixels chauds (ou bruit) identifiés en tant que raie d'émission à flux très élevé et pris pour une raie Halpha surtout pour des vitesses &gt;0.</p> <p>il serait intéressant de regarder sur cet exemple, si les vitesses des autres candidats sont nulles ? <br/> &gt; <br/> &gt; L'idée (en gros) est de fitter avec des vitesses d'émission nulles et pénaliser les raies dont la vitesse d'emission estimée est à 0.<br/> &gt; <br/> &gt; Spécifications pour l'implémentation, à discuter:<br/> &gt; * dans dataset-parameters, ajouter un paramètre `linemodel.emvelocityforceprior` mis à true pour pénaliser les vitesses nulles.<br/> &gt; Note qu'il faut avoir : `linemodel.emvelocityfitmin = 0` pour que `linemodel.emvelocityforceprior` s'applique vraiment.<br/> &gt; * coté lib: à spécifier avec Didier</p> <p>je ne rajouterai pas de param emvelocityforceprior. Mais comme pour le fonctionnement des autres priors (stronglines et Ha, juste un param avec le coeff de pénalité cf #7635-2</p> <p>on pu</p> <p>Comment by Vincent Le Brun on 2022-11-08 15:13:21:<br/> Didier Vibert wrote in #note-10:</p> <p>&gt; il serait intéressant de regarder sur cet exemple, si les vitesses des autres candidats sont nulles ? <br/> sur un autre exemple que j''ai regardé, tous les autres candidats utilisent le spike comme raie d'emission principale, et la vitesse est la meme (10 km/s pour ce run là) pour tous les candidats. Ca peut être un critère en effet</p> <p>Comment by Didier Vibert on 2022-11-08 15:17:32:<br/> Vincent Le Brun wrote in #note-11:<br/> &gt; Didier Vibert wrote in #note-10:<br/> &gt; <br/> &gt; &gt; il serait intéressant de regarder sur cet exemple, si les vitesses des autres candidats sont nulles ? <br/> &gt; sur un autre exemple que j''ai regardé, tous les autres candidats utilisent le spike comme raie d'emission principale, et la vitesse est la meme (10 km/s pour ce run là) pour tous les candidats. Ca peut être un critère en effet</p> <p>je pensais plutôt que si c'est le cas ça va être dur de rattrapper les bons candidats, il va falloir mettre une pénalité forte... on va quand même tenter !</p> <p>Comment by Didier Vibert on 2022-11-08 15:21:19:<br/> Vincent Le Brun wrote in #note-11:<br/> &gt; Didier Vibert wrote in #note-10:<br/> &gt; <br/> &gt; &gt; il serait intéressant de regarder sur cet exemple, si les vitesses des autres candidats sont nulles ? <br/> &gt; sur un autre exemple que j''ai regardé, tous les autres candidats utilisent le spike comme raie d'emission principale, et la vitesse est la meme (10 km/s pour ce run là) pour tous les candidats. Ca peut être un critère en effet</p> <p>10 km/s ? donc il faut aussi rajouter un param qui donne le seuil de vitesse en dessous duquel on applique la pénalité. <br/> Donc 2 param </p> <ol> <li>le seuil de vitesse</li> <li>la pénalité en proba (ie un terme p : 0 &lt;= p &lt;= 1)</li> </ol> <p>Comment by Vincent Le Brun on 2022-11-08 15:22:33:<br/> non c'est pare que pour ce run j'avais mis 10 en limite basse, l'idée serait de mettre 0 et de tester les solutions avec vitesse 0 (si la limite basse n'est pas 0 on n'active pas le prior)</p> <p>Comment by Didier Vibert on 2022-11-08 15:53:09:<br/> Vincent Le Brun wrote in #note-14:<br/> &gt; non c'est pare que pour ce run j'avais mis 10 en limite basse, l'idée serait de mettre 0 et de tester les solutions avec vitesse 0 (si la limite basse n'est pas 0 on n'active pas le prior)</p> <p>ok, on oublie le param seuil pour l'instant donc.</p> <p>on peut quand même activer le prior avec la vitesse limite basse, même quand elle n'est pas nulle. Ie l'activation du prior est gouvernée uniquement par la valeur de la pénalité (comme pour les autres priors), si -1 le prior n'est pas actif, sinon il est actif et pénalise les z avec une vitesse basse.</p> <p>Comment by Didier Vibert on 2022-11-08 15:55:03:<br/> je viens de penser à un truc... le fit de la vitesse ne se fait que sur les fenêtres 2nd passe....<br/> =&gt; on ne rattrapera jamais les candidats qui ne sont pas examinés en 2nd passe ie si les 5 sont dus au spike c'est foutu...</p> <p>Comment by Vincent Le Brun on 2022-11-08 16:43:50:<br/> pas bon ça... on peut peut-être imaginer bosser sur la forme de la PDF 1ere passe ?<br/> <span class="image-wrap" style=""><img src="https://pfspipe.ipmu.jp/jira/secure/attachment/15841/15841_PDF_Spike.png" style="border: 0px solid black" /></span></p> <p>Comment by Didier Vibert on 2022-11-10 15:50:43:<br/> petit récap sur les diverses possibilités de mitigation des spikes:</p> <ul> <li>prior vitesse =&gt; implémenter le fit de la vitesse en première passe (ie à chaque z)</li> <li>detection des spikes:</li> </ul> <ul> <li>code standalone hors amazed eg deglitcher à ondelette continue et coeff de Holder (deglitcher Hershell SPIRE) ou sparsité (L1 minimisation)</li> <li>dans amazed: vitesse nulle pour 1 ou tous les candidats, rechercher la position de la raie dominante, flagger les pixels correspondant et relancer l'estimation de z</li> <li>modélisation des spikes: rajouter un spike paramétré dans les modèles fitté, sans doute un peu lourd, car mini 2 param en plus par modèle (position et amplitude du spike), mieux vaut les détecter avant ?</li> <li>réjection au niveau de la reliability, la pdf ayant sans doute la signature: apprendre sur des simu incluant des spikes (El-cosmos ?) et rajouter une classe spike</li> <li>... vous avez mieux ?</li> </ul> Development Rank 0|zzsxu7: