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-323 1D Redmine <p><em><font color="#505f79"> Created on 2023-09-26 15:17:41 by Vincent Le Brun. % Done: 70</font></em></p> <p>j'ai un comportement étrange du solver QSO sur un spectre DESI<br/> /net/CESAM/amazed/vlebrun/DESI/SelfCal/output_QSO_39633425266639401/<br/> qui me propose ce fit<br/> <span class="image-wrap" style=""><img src="https://pfspipe.ipmu.jp/jira/secure/attachment/16989/16989_QSO_39633425266639401.png" style="border: 0px solid black" /></span><br/> C'est peut-être normal mais il faudra me convaincre ...</p> REDMINE1D-323

[RM-8365] Comportement solver QSO

Task Normal In Progress Unresolved Redmine-Jira Migtation Redmine-Jira Migtation Tue, 26 Sep 2023 18:15:40 +0000 Thu, 21 Dec 2023 18:30:24 +0000 0 1 <p>Comment by Pierre-yves Chabaud on 2023-09-27 08:01:22:<br/> A oui, c'est normal! Maintenant les raies sont classées par ordre alphabétique inverse plutôt que par longueur d'onde. Nous avons également opté pour le "linéaire A", un alphabet antérieur a l'alphabet grec, qui semble mieux adapté aux objets lointains (c'est a dire plus jeune dans l'age de l'univers). C'est clairement le cas pour certains QSO. Si tu veux une autre explication, tu peux bien évidemment t'adresser aussi a Didier...</p> <p>Comment by Didier Vibert on 2023-09-27 08:14:22:<br/> Pierre-yves Chabaud wrote in #note-1:<br/> &gt; A oui, c'est normal! Maintenant les raies sont classées par ordre alphabétique inverse plutôt que par longueur d'onde. Nous avons également opté pour le "linéaire A", un alphabet antérieur a l'alphabet grec, qui semble mieux adapté aux objets lointains (c'est a dire plus jeune dans l'age de l'univers). C'est clairement le cas pour certains QSO. Si tu veux une autre explication, tu peux bien évidemment t'adresser aussi a Didier...</p> <p>franchement j'ai pas trouvé mieux comme explication !</p> <p>Comment by Vincent Le Brun on 2023-09-27 08:28:47:<br/> OK je vais donc mettre ça dans la publication, on verra si ça passer les referee...</p> <p>Comment by Vincent Le Brun on 2023-09-29 15:46:14:<br/> le template fitting marche très bien <br/> <span class="image-wrap" style=""><img src="https://pfspipe.ipmu.jp/jira/secure/attachment/16990/16990_39633425266639401_tplfit.png" style="border: 0px solid black" /></span><br/> et le templates ratio utilisé pour le résultat bizarre vient du spectre du QSO moyen...</p> <p>Comment by Didier Vibert on 2023-10-04 10:24:19:<br/> problème résolu via #7959 :</p> <p><span class="image-wrap" style=""><img src="https://pfspipe.ipmu.jp/jira/secure/attachment/16991/16991_clipboard-202310041221-aoquy.png" style="border: 0px solid black" /></span></p> <p>Mais linemeas qso pose problème: (c'était le cas aussi avant)</p> <p><span class="image-wrap" style=""><img src="https://pfspipe.ipmu.jp/jira/secure/attachment/16992/16992_clipboard-202310041222-zujfy.png" style="border: 0px solid black" /></span></p> <p>du coup je laisse le ticket ouvert pour régler linemeas... a priori encore un pb de confusion entre raies</p> <p>Comment by Vincent Le Brun on 2023-10-04 10:43:11:<br/> parfait pour le fit. Pour le reste on dirait Euclid avec ses problèmes de guidage... </p> <p>Comment by Didier Vibert on 2023-10-05 07:42:09:<br/> Bon j'ai la réponse pour le comportement linemeas:</p> <p>ça vient d'un comportement pathologique du code consécutif à un mauvais parameters.json. La limite sup en dispersion de vitesses pour la phase estimation de z (linemodelSolve) est emvelocitifitmax=4500, alors que pour la phase linemeas emvelocitifitmax=150 or la dispersion de vitesse estimée lors de la phase linemodelSolve est de 2950 km/s, donc supérieure à la limite max de linemeas.... Le support des raies (et donc du polynôme) pour la phase linemeas est calculé en utilisant la limite max de la dispersion de vitesse et ce support n'est pas adaptatif lors du fit. Ensuite un premier guess de l'amplitude est calculé en utilisant le solver linéaire (hybrid fitter) qui n'ajuste que l'amplitude. Le SNR trouvé ainsi étant &lt;1 le solver non-linéaire (lbfgs fitter) n'est pas activé, et la solution conserve donc la dispersion de vitesse initiale de 2950 km/s (donc sans appliquer de contrainte max à la vitesse qui n'est pas réajustée), avec un polynôme ajusté sur un support restreint construit avec la limite max de 150km/s. In fine, lors du calcul du modèle pour le résultat, les supports sont recalculés avec les vitesses de la solution (au lieu de prendre les supports utilisés lors du fit) et on a donc un polynôme ajusté sur un support de 150km/s mais calculé sur un support de 2950 km/s d'où les divergences ! ouf...</p> <p>si on modifie le parameters.json pour avoir la bonne plage de vitesse linemeas, le résultat est ok:</p> <p><span class="image-wrap" style=""><img src="https://pfspipe.ipmu.jp/jira/secure/attachment/16993/16993_clipboard-202310050942-4kfkp.png" style="border: 0px solid black" /></span></p> <p>TODO:</p> <ul> <li>calculer le modèle en sortie en utilisant le support effectivement utilisé lors du fit, ie avec les vitesses max, et non pas les vitesses solution. Une autre possibilité, serait de refaire un fit avec un support recalculé avec la vitesse obtenue lors du premier fit. Ça permettrait éventuellement d'ajuster des polynômes individualisés lorsque la dispersion de vitesses n'est pas très large et que donc les raies sont bien séparées. Sinon le support est le plus large possible et on fait un ajustement joint avec un seul polynôme sous le continu de plusieurs raies.</li> <li>ajout d'un check du parameters.json pour forcer la plages de fit de vitesse linemeas à être au moins aussi large que celle de la phase estimation de z, lors d'un enchainement des 2 phases et idem dams le cas d'un linemeas seul si la dispersion de vitesse initiale n'est pas dans la plage. On a alors 3 possibilités:</li> </ul> <ol> <li>erreur</li> <li>warning, modif de la vitesse initiale pour rentrer dans la plage</li> <li>warning, modif de la plage pour inclure la vitesse initiale.</li> </ol> <p>je vote pour le 3ème cas. mais j'attends vos avis...</p> <p>Comment by Didier Vibert on 2023-10-05 13:14:01:<br/> Didier Vibert wrote in #note-10:<br/> &gt; TODO:<br/> &gt; * ajout d'un check du parameters.json pour forcer la plages de fit de vitesse linemeas à être au moins aussi large que celle de la phase estimation de z, lors d'un enchainement des 2 phases et idem dams le cas d'un linemeas seul si la dispersion de vitesse initiale n'est pas dans la plage. On a alors 3 possibilités:<br/> &gt; # erreur <br/> &gt; # warning, modif de la vitesse initiale pour rentrer dans la plage<br/> &gt; # warning, modif de la plage pour inclure la vitesse initiale.<br/> &gt; <br/> &gt; je vote pour le 3ème cas. mais j'attends vos avis...</p> <p>=&gt; new issue #8390<br/> il faut décider parmi les 3 possibilités erreur ou warning</p> <p>Comment by Vincent Le Brun on 2023-10-19 09:21:55:<br/> pourquoi ce serait moins bien de partir de la vitesse initiale sortant du modèle ? en tout cas il faut optimiser la mesure donc avoir des supports séparés dans la mesure du possible</p> <p>Comment by Didier Vibert on 2023-10-19 12:06:16:<br/> Vincent Le Brun wrote in #note-15:<br/> &gt; pourquoi ce serait moins bien de partir de la vitesse initiale sortant du modèle ? <br/> on utilise la vitesse initiale sortant de la phase estimation-de-z comme first guess de l'algo linemeas. Mais linemeas fit avec une contrainte <span class="error">&#91;Vmin,Vmax&#93;</span>, donc c'est mieux si le first guess est dans la plage de la contrainte. Si la plage de vitesse de la phase linemeas ne couvre pas celle de la phase estimation-z alors on a un pb, d'où la question sur la conduite à tenir dans ce cas: erreur ou warning et quel comportement adopter dans le cas du warning. </p> <p>&gt; en tout cas il faut optimiser la mesure donc avoir des supports séparés dans la mesure du possible<br/> dans ce cas il faut réduire la plage de vitesse linemeas et donc aussi celle estimation-z</p> Development Rank 0|zzszq7: