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-95 1D Redmine <p><em><font color="#505f79"> Created on 2023-05-26 13:42:53 by Vincent Le Brun. % Done: 100</font></em></p> <p>dans /net/CESAM/amazed/vlebrun/SelfCal/output_0.42_BR/ pour l'objet 2681065403655642953 la PDF a une forme un peu étrange<br/> <span class="image-wrap" style=""><img src="https://pfspipe.ipmu.jp/jira/secure/attachment/16311/16311_PDF_2681065403655642953.png" style="border: 0px solid black" /></span> qui fait que la solution à z=1.75 (qui a un pic assez fort) passe à la trappe au profit du mismatch avec OII.<br/> Je croyais à un problème de continu qui ne serait pas reproduit par nos modèles mais quand je force la solution avec un z_range restreint la solution existe et le continu est plus que correct, donc je me demande ce qui fait descendre la proba en dessous de z=3.5<br/> <span class="image-wrap" style=""><img src="https://pfspipe.ipmu.jp/jira/secure/attachment/16312/16312_Spec_2681065403655642953.png" style="border: 0px solid black" /></span></p> REDMINE1D-95

[RM-8100] Encore une forme de PDF étrange

Task Normal Done Done Redmine-Jira Migtation Redmine-Jira Migtation Tue, 13 Jun 2023 04:59:21 +0000 Thu, 31 Aug 2023 18:18:02 +0000 Thu, 31 Aug 2023 18:18:02 +0000 0 2 <p>Comment by Vincent Le Brun on 2023-06-02 10:01:45:<br/> Comme discuté hier matin, si on réduit le lambda range on retombe sur la bonne solution par contre la PDF a toujours le meme forme, la raie est en effet très large donc il y a peut-être en effet une question de largeur du support.<br/> le paramètre 'ignorelinesupport' était à false, en le passant à 'true' et en reprenant le lambda range de départ, et en élargissant un peu la LSF pour ne pas avoir une dispersion de vitesse bloquée à la valeur max, la bonne solution est aussi trouvée<br/> J'ai vérifié en augmentant la largeur de la LSF, ça change le continu (qui peut passer d'un template à no continuum à fromspectrum) et ça fait aussi changer la solution, mais la forme générale de la PDF ne change pas, il reste cette variation à grande échelle alors que le continu est compatible avec 0. <br/> en augmentant le 'nsigmasupport' ça modifie la PDF (qui reste quand meme un peu étrange...) donc je pense que l'explication est là. Mais ça vaut peut-être le coup de réfléchir aux paramètres en question</p> <p>Comment by Didier Vibert on 2023-06-02 14:34:17:<br/> Vincent Le Brun wrote in #note-2:<br/> &gt; Comme discuté hier matin, si on réduit le lambda range on retombe sur la bonne solution par contre la PDF a toujours le meme forme, la raie est en effet très large donc il y a peut-être en effet une question de largeur du support.<br/> &gt; le paramètre 'ignorelinesupport' était à false, en le passant à 'true' et en reprenant le lambda range de départ, et en élargissant un peu la LSF pour ne pas avoir une dispersion de vitesse bloquée à la valeur max, la bonne solution est aussi trouvée<br/> &gt; J'ai vérifié en augmentant la largeur de la LSF, ça change le continu (qui peut passer d'un template à no continuum à fromspectrum) et ça fait aussi changer la solution, mais la forme générale de la PDF ne change pas, il reste cette variation à grande échelle alors que le continu est compatible avec 0. <br/> &gt; en augmentant le 'nsigmasupport' ça modifie la PDF (qui reste quand meme un peu étrange...) donc je pense que l'explication est là. Mais ça vaut peut-être le coup de réfléchir aux paramètres en question</p> <p>effectivement, on avait déjà vu ça pour les QSO. Lorsque la/les raies dans le spectre sont trop larges par rapport à ce que le modèle peut générer, ça favorise les solutions à haut z, en élargissant les raies du modèle par la dilatation de (1+z). C'est cette pente qu'on voit. J'imagine qu'avec des raies trop étroites dans le spectre on aurait le comportement inverse avec le "fond" de la pdf qui descend des bas z vers les haut z.</p> <p>Comment by Didier Vibert on 2023-08-22 09:14:17:<br/> et alors on fait quoi ? <br/> avec ce problème de largeur fixée en first passe ? </p> <p>on code une boucle qui scanne grossièrement la plage de vitesse en first-pass ? </p> <p>Comment by Vincent Le Brun on 2023-08-24 08:40:50:<br/> Didier Vibert wrote in #note-5:<br/> &gt; et alors on fait quoi ? <br/> &gt; avec ce problème de largeur fixée en first passe ? <br/> &gt; <br/> &gt; on code une boucle qui scanne grossièrement la plage de vitesse en first-pass ?</p> <p>pourquoi pas, 3 ou 4 valeurs genre 100 - 300 - 500 - 700 ?</p> <p>Comment by Didier Vibert on 2023-08-24 09:20:50:<br/> Vincent Le Brun wrote in #note-6:<br/> &gt; Didier Vibert wrote in #note-5:<br/> &gt; &gt; et alors on fait quoi ? <br/> &gt; &gt; avec ce problème de largeur fixée en first passe ? <br/> &gt; &gt; <br/> &gt; &gt; on code une boucle qui scanne grossièrement la plage de vitesse en first-pass ?<br/> &gt; <br/> &gt; pourquoi pas, 3 ou 4 valeurs genre 100 - 300 - 500 - 700 ?<br/> . i<br/> tant que ça ? on va le paramétrer de toute façon. ça risque de prendre du temps de calcul car il faut le faire à chaque z</p> <p>Comment by Vincent Le Brun on 2023-08-24 09:22:21:<br/> juste deux valeurs pour éventuellement raccourcir l'intervalle de la seconde pass ? genre si c'est 200 on fait 100-500 et si c'est 600 on fait 400-800 ?</p> <p>Comment by Pierre-yves Chabaud on 2023-08-31 08:41:09:<br/> New feature will be developed in #8237 .</p> Development Rank 0|zzsxef: