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-207 1D Redmine <p><em><font color="#505f79"> Created on 2023-03-09 15:13:04 by Ali Allaoui. % Done: 100</font></em></p> <p>parameter @LineModelSolve.linemodel.useloglambdasampling@ should be set to true only if @ LineModelSolve.linemodel.continuumfit.fftprocessing@ is set to true.</p> <p>currently the check is not performed since #7924 and thus the code segfaults <br/> see: </p> <ul> <li><a href="https://gitlab.lam.fr/CPF/cpf-redshift/-/blob/53afacb44e64c31ada50ae31159cf3852e5e5baf/RedshiftLibrary/src/lib/method/linemodelsolve.cpp#L101" class="external-link" rel="nofollow">https://gitlab.lam.fr/CPF/cpf-redshift/-/blob/53afacb44e64c31ada50ae31159cf3852e5e5baf/RedshiftLibrary/src/lib/method/linemodelsolve.cpp#L101</a></li> <li><a href="https://gitlab.lam.fr/CPF/cpf-redshift/-/blob/53afacb44e64c31ada50ae31159cf3852e5e5baf/RedshiftLibrary/src/lib/linemodel/linemodelfitting.cpp#L143" class="external-link" rel="nofollow">https://gitlab.lam.fr/CPF/cpf-redshift/-/blob/53afacb44e64c31ada50ae31159cf3852e5e5baf/RedshiftLibrary/src/lib/linemodel/linemodelfitting.cpp#L143</a></li> </ul> <p>TODO:<br/> prevent the segfault by forbidding the incompatible combination. Either throw when using the option in C++ code, and/or validate the parameters.json at the python API level</p> REDMINE1D-207

[RM-7949] useloglambdasampling parameter incompatible with fft continuumfit disabled

Task Normal Done Done Redmine-Jira Migtation Redmine-Jira Migtation Wed, 5 Jul 2023 02:42:58 +0000 Fri, 7 Jul 2023 17:04:05 +0000 Fri, 7 Jul 2023 17:04:05 +0000 0 1 <p>Comment by Didier Vibert on 2023-05-22 10:26:39:<br/> @msarkis tu peux créer la MR et rajouter le lien stp</p> <p>la décision de le mettre dans l'API dès maintenant me semble un peu prématuré... ça rejoint la discussion sur l'organisation du paramerterStore c++ vs python et le ticket plus général de vérif de syntaxe/cohérence des paramètres. </p> <p>Comment by Mira Sarkis on 2023-05-22 11:53:52:<br/> mr: <a href="https://gitlab.lam.fr/CPF/cpf-redshift/-/merge_requests/497" class="external-link" rel="nofollow">https://gitlab.lam.fr/CPF/cpf-redshift/-/merge_requests/497</a></p> <p>Comment by Didier Vibert on 2023-06-06 09:08:25:<br/> code python de l'API valid en ce qui me concerne.</p> <p>il faut à mon sens modifier aussi le code C++ aux 2 endroits mentionnés dans la description:</p> <ul> <li>soit on considère au niveau C++ que le check du parameter est fait au niveau python, et plus besoin de s'assurer à nouveau de la cohérence (ie on supprime la L144 dans linemodelfitting.cpp)</li> <li>soit on considère que le C++ doit aussi s'assurer de la cohérence et on modifie la L101 de linemodelSolve (rajout d'un &amp; logique avec fftprocessing)</li> </ul> <p>Tout cela nous ramène sur la discussion du check du parameters.json et de l'implémentation python. Je rappelle, dans cette discussion, 2 points qui me paraissent essentiels:<br/> 1. on ne veut/doit pas dupliquer le code python et C++ <br/> 2. actuellement on sait utiliser le code C++ depuis python mais la réciproque est fausse. </p> <p>Donc </p> <ul> <li>soit on reste comme ça et l'essentiel de la classe parameters doit être faite en C++ (à minima tout ce dont le C++ a besoin) et le code python doit wrapper ça sans duplication, mais on peut décider que le C++ ne fait aucune vérif de cohérence. Cependant le C++ a malgré tout besoin de méthodes qui combinent certains param entre eux, qu'il faut donc éviter de dupliquer en python.</li> <li>soit on regarde avec swig si c'est possible et comment utiliser le code python depuis C++</li> </ul> <p>Il me parait plus simple de rester comme aujourd'hui (ie pas d'utilisation du code python en C++)</p> <p>Comment by Mira Sarkis on 2023-06-06 14:07:42:<br/> Didier Vibert wrote in #note-5:<br/> &gt; code python de l'API valid en ce qui me concerne.<br/> &gt; <br/> &gt; il faut à mon sens modifier aussi le code C++ aux 2 endroits mentionnés dans la description:<br/> &gt; * soit on considère au niveau C++ que le check du parameter est fait au niveau python, et plus besoin de s'assurer à nouveau de la cohérence (ie on supprime la L144 dans linemodelfitting.cpp)<br/> &gt; * soit on considère que le C++ doit aussi s'assurer de la cohérence et on modifie la L101 de linemodelSolve (rajout d'un &amp; logique avec fftprocessing)</p> <p>Comme tu dis toujours: "ceinture-bretelles" c'est mieux! </p> <p>Il faut aussi prendre en compte le cas ou on désactive fftprocessing dans linemodel (@::precomputeContinuumfit) alors que useloglambdasampling et fftprocessing sont à True dans param.json ?<br/> Ce cas est bien équivalent à avoir useloglambdasampling=True et fftprocessing=False, sauf qu'on peut pas vraiment le prévoir au tout début!</p> <p>&gt; Tout cela nous ramène sur la discussion du check du parameters.json et de l'implémentation python. Je rappelle, dans cette discussion, 2 points qui me paraissent essentiels:<br/> &gt; 1. on ne veut/doit pas dupliquer le code python et C++ <br/> &gt; 2. actuellement on sait utiliser le code C++ depuis python mais la réciproque est fausse. <br/> &gt; <br/> &gt; Donc <br/> &gt; <br/> &gt; * soit on reste comme ça et l'essentiel de la classe parameters doit être faite en C++ (à minima tout ce dont le C++ a besoin) et le code python doit wrapper ça sans duplication, mais on peut décider que le C++ ne fait aucune vérif de cohérence. Cependant le C++ a malgré tout besoin de méthodes qui combinent certains param entre eux, qu'il faut donc éviter de dupliquer en python.<br/> &gt; * soit on regarde avec swig si c'est possible et comment utiliser le code python depuis C++ <br/> je regarde pour voir si c'est faisable!<br/> &gt; <br/> &gt; Il me parait plus simple de rester comme aujourd'hui (ie pas d'utilisation du code python en C++)</p> <p>Comment by Didier Vibert on 2023-06-13 09:46:59:<br/> Mira Sarkis wrote in #note-6:<br/> &gt; <br/> &gt; Il faut aussi prendre en compte le cas ou on désactive fftprocessing dans linemodel (@::precomputeContinuumfit) alors que useloglambdasampling et fftprocessing sont à True dans param.json ?<br/> &gt; Ce cas est bien équivalent à avoir useloglambdasampling=True et fftprocessing=False, sauf qu'on peut pas vraiment le prévoir au tout début!<br/> &gt; <br/> on en a parlé lors de la dernière réunion amazed: pas de cas spécifique pour ça: si on a fait du fftprocessing en 1st pass et uselolambdasampling est true on reste avec ça pour la 2nd pass même si le fftprocessing est désactivé par le nombre min de sample (100. qu'il faudrait d'ailleurs ajuster)</p> <p>Comment by Didier Vibert on 2023-06-13 09:49:34:<br/> basée sur #8048 (à merger après)</p> <p>Comment by Gaelle Daste on 2023-06-27 12:35:42:<br/> Les tests unitaires associés à la classe Parameters ne passent pas. Déjà dans le init de la classe il faut appeler la méthode check_params <b>après</b> l'instanciation de l'objet parameters</p> <p>Comment by Didier Vibert on 2023-06-28 13:28:13:<br/> Gaelle Daste wrote in #note-11:<br/> &gt; Les tests unitaires associés à la classe Parameters ne passent pas. Déjà dans le init de la classe il faut appeler la méthode check_params <b>après</b> l'instanciation de l'objet parameters</p> <p>je ne comprend pas ça... attention en python le @_<em>init</em>_@ n'est pas vraiment un constructeur, l'objet est déjà instancié. Mais c'est une méthode appelée immédiatement après la construction.</p> <p>Comment by Gaelle Daste on 2023-06-28 14:13:41:<br/> Didier Vibert wrote in #note-12:<br/> &gt; Gaelle Daste wrote in #note-11:<br/> &gt; &gt; Les tests unitaires associés à la classe Parameters ne passent pas. Déjà dans le init de la classe il faut appeler la méthode check_params <b>après</b> l'instanciation de l'objet parameters<br/> &gt; <br/> &gt; je ne comprend pas ça... attention en python le @_<em>init</em>_@ n'est pas vraiment un constructeur, l'objet est déjà instancié. Mais c'est une méthode appelée immédiatement après la construction.</p> <p>Je corrige pour tout le monde (c'était clair dans ma tête mais c'est pas bien ressorti !) : <br/> Les tests unitaires associés à la classe Parameters ne passent pas. Déjà dans le init de la classe il faut appeler la méthode check_params <b>après</b> l'affectation du dictionnaire à l'attribut parameters</p> <p>Comment by Gaelle Daste on 2023-06-28 15:18:37:<br/> j'ai fait un fix des tests python qui ne passaient pas dans cette issue avec le check_params, en l'état si elle était feedback avant le départ de Mira, aucune raison de pas la repasser en feedback si les dernières modifs conviennent à tout le monde</p> <p>Comment by Pierre-yves Chabaud on 2023-06-30 14:29:45:<br/> Merged into @develop@ (@7c27c7ff@)</p> Development Rank 0|zzsy8f: