PFS-JIRA

PFS-JIRA https://pfspipe.ipmu.jp/jira This file is an XML representation of an issue en-us

8.3.4

803005

13-09-2019

[REDMINE1D-76] [RM-5691] Pre-traitement du parameters.json https://pfspipe.ipmu.jp/jira/browse/REDMINE1D-76 1D Redmine <p><em><font color="#505f79"> Created on 2020-03-18 14:41:05 by Pierre-yves Chabaud. % Done: 100</font></em></p> <p>MR pylibamazed: <a href="https://gitlab.lam.fr/CPF/cpf-redshift/-/merge_requests/498" class="external-link" rel="nofollow">https://gitlab.lam.fr/CPF/cpf-redshift/-/merge_requests/498</a><br/> MR dataset-parameters : <a href="https://gitlab.lam.fr/amazed/dataset-parameters/-/merge_requests/56" class="external-link" rel="nofollow">https://gitlab.lam.fr/amazed/dataset-parameters/-/merge_requests/56</a><br/> MR pyamazed: <a href="https://gitlab.lam.fr/CPF/pyamazed/-/merge_requests/114" class="external-link" rel="nofollow">https://gitlab.lam.fr/CPF/pyamazed/-/merge_requests/114</a> Issue <a href="https://projets.lam.fr/issues/8268" class="external-link" rel="nofollow">https://projets.lam.fr/issues/8268</a><br/> MR amazed output analyzer <a href="https://gitlab.lam.fr/amazed/amazed-output-analyzer/-/merge_requests/15" class="external-link" rel="nofollow">https://gitlab.lam.fr/amazed/amazed-output-analyzer/-/merge_requests/15</a></p> REDMINE1D-76

[RM-5691] Pre-traitement du parameters.json

Task Normal Done Done Redmine-Jira Migtation Redmine-Jira Migtation Fri, 4 Jun 2021 01:22:02 +0000 Mon, 18 Sep 2023 19:03:10 +0000 Mon, 18 Sep 2023 19:03:10 +0000 0 1 <p>Comment by Ali Allaoui on 2020-08-13 14:48:53:<br/> Avec cette feature, dans le client LAM le fichier parameters.py, qui contient des paramètres par défaut, devient inutile</p> <p>Comment by Didier Vibert on 2020-11-07 13:58:32:<br/> ce prétraitement pourrait être une méthode du @CprocessFlowContext@ (ou plutôt du @CParameterStore@)</p> <p>ce qui permettra, de rendre le membre @CprocessFlowContext:m_ParameterStore@ const (std::shared_ptr<const CParameterStore>) ainsi que le getter CProcessFlowContext::GetParameterStore, à condition de pré-traiter le ParameterStore dans @Init@, avant d'initialiser par copie @m_ParameterStore@.</p> <p>Note, pour l'instant les seules modifs en écritures effectuées dans le cours du run, consiste en quelques appels à @CDataStore::SetScopedParam@ depuis</p> <ul> <li>@CLineModelSolve::PopulateParameters@ (forçage de @linemodel.fittingmethod@ et @linemodel.firstpass.fittingmethod@)</li> <li>@CMethodDTreeCSolve::Solve@ (forçage de @linemodel.fittingmethod@)</li> <li>@CZweiModelSolve::PopulateParameters@ (forçage de @zweimodel.fittingmethod@)</li> </ul> <p>Comment by Ali Allaoui on 2020-11-09 17:54:46:</p> <p>ce pourrait être aussi des méthodes <pre><code class="cpp">COperator::checkParameters(CParameterStore parameters,std::string scope) </code></pre> que CProcessFlow ou CMethod appellerait sur tous les opérateurs utilisés</p> <p>Comment by Didier Vibert on 2020-11-10 09:34:02:<br/> Ali ALLAOUI wrote in #note-3:<br/> > ce pourrait être aussi des méthodes <span class="error">[...]</span> que CProcessFlow ou CMethod appellerait sur tous les opérateurs utilisés</p> <p>yep ! en fait il faut toute la hirerachie , ie des @CMethod::checkParameterss(...)@ qui appellent les @COperator::checkparameters()@ du ou des operateurs utilisés dans la méthode, et CProcessFlow qui appelle les @CMethod::checkParameterss(...)@ des méhthode qu'il utilise.</p> <p>ce qui conduit à repenser les opérateurs/ méthode en les dérivant chacun d'une classe de base CMethode ou COperator (abstraite éventuellement) contenant les methodes virtuelles </p> <p>et du coup le contextflow devrait sans doute être un membre (pointeur) des classe CMethod, (et potentiellement des classe COperator aussi ? à voir...)</p> <p>=> ticket "refactor CMethod/Coperator" ?</p> <p>je pense aussi qu'il faudrait attaquer la suppression des méthodes obsolètes (actuellement, on perds du temps à les mettre à jour) ainsi que renommage de certaines:<br/> eg<br/> chisquare2solve -> templateSolve<br/> chisquareSolve -> trash<br/> chisquareLogSolve -> templateLogSolve</p> <p>Comment by Mira Sarkis on 2021-07-15 13:24:19:<br/> Hello, en m'inspirant de <a href="https://json-schema.org/" class="external-link" rel="nofollow">https://json-schema.org/</a>, et dans le but de spécifier les paramètres de param.json afin de :<br/> 1) valider les noms des params, <br/> 2) valider les valeurs données , <br/> 3) valider la complitude des params ainsi que le respect de la hiérarchie <br/> 4) et meme générer une documentation complète de tous les params</p> <p>J'ai écrit un premier schema draft (en pièce-jointe) qui sera une base pour discuter de ma proposition.<br/> En gros les bases du schema sont listées comme suit:</p> <ul> <li>chaque paramètre d'amazed est une propriété.</li> <li>une propriété est consiste en: 1) description, 2) type , 3) constraint, 4) hierarchies <ul> <li><b>description</b> : sert principalement à la documentation des propriétés</li> <li><b>type</b> : donne le type qui peut etre un type standard, e.g., float, int, bool, etc ou meme un objet. <ul> <li>je définis un objet comme une entité englobant plusieurs propriétés. Par exemple, le paramètre @ebmv @est un objet à 3 propriétés.</li> <li>il est possible de définir des objets (e.g., @defModuletype@: @priorObject@) qui sera utilisé comme un nouveau type. Le but içi est d'éviter de dupliquer du texte.</li> </ul> </li> <li><b>constraint</b> : contient une liste de règles qui s'appliquent à la valeur passée à chaque param. <ul> <li>j'ai défini des règles "standard" comme par e.g., nonNull, positive, PATH, etc.</li> <li>et aussi des règles correspondant aux valeurs acceptées par chaque paramètre. Ces règles sont ajoutés à la fin du fichier de specification.</li> </ul> </li> <li><b>hierarchies</b> : détermine à quel endroit on pourra placer chacune des propriétés. Dans l'exemple suivant, on voit que le paramètre priors peut appartenir à "tplratio" ou "continuumfit"<br/> <pre><br/> Exemple: <br/> {<br/> "priors":{<br/> "desciption": "priors",<br/> "type": "object",<br/> "defModuletype": "priorObject", //definition d'un nouveau type d'objet réutilisable par chacun des elements de @hierarchies@<br/> "properties": <div class="error"><span class="error">Unknown macro: { "betaA"}</span> </div> <p>,<br/> "hierarchies":<span class="error">["tplratio", "continuumfit"]</span><br/> },<br/> "inValuelistContinuumRemovalMethods":<span class="error">["zero", "Median", "IrregularSamplingMedian","raw"]</span> //définition de contrainte<br/> }<br/> </pre></p></li> </ul> </li> </ul> <p>Comment by Didier Vibert on 2023-06-09 10:04:32:</p> <h2><a name="R%C3%A9sum%C3%A9deladiscussiondu8%2F06%2F2023"></a>Résumé de la discussion du 8/06/2023</h2> <ul> <li>implémentation du check parameter 100% python dans l'API</li> <li>conséquence: le code C++ fait l’hypothèse que la cohérence est pré-testée, et ne fait plus de check: on supprime donc les checks spécifiques fait en C++ (à identifier dans la classe CParameterStore et ailleurs dans le code). Ne subsiste donc en C++ que le check qu'un param existe lorsqu'on y accède (les getter C++ lèvent une exception)</li> <li>on supprime aussi du code C++ les "combinaisons de paramètres" qui ne sont pas des check mais peuvent être assimilés à des paramètres intermédiaires déduits des paramètres initiaux. Le code python devra donc rajouter ces paramètres intermédiaires avec donc les méthodes pour les produire</li> <li>Le format reste json</li> <li>la classe parameter python devra appeler le checker lors de son instanciation (dans le @_<em>init</em>_@)</li> <li>on a parlé de check à base d'un tableau csv. Mais il existe un "json schema":<a href="https://json-schema.org/" class="external-link" rel="nofollow">https://json-schema.org/</a> qui permet de définir une grammaire (en json) pour un document json. @msarkis avait déjà regardé cet aspect (cf #note-8). Il me semble que ça permet de traiter tous les check dont nous avons besoin (range et type des param, paramètre requis conditionnellement à la présence et/ou valeur d'autres, hiérarchie de param...)<br/> Le fichier schema est sans doute un peu fastidieu à écrire (il peut être scindé en plusieurs sous-ensembles), mais ensuite le checker python existe (il y en a plusieurs <a href="https://json-schema.org/implementations.html#validator-python" class="external-link" rel="nofollow">https://json-schema.org/implementations.html#validator-python</a>), ainsi que des générateurs de documentation.</li> <li>on a décidé de ne pas faire de check des sections "inutiles" (j'ai l'impression que si on utilise json-schema, ce n'est pas possible: le checker vérifiera l'intégralité du contenu, mais ce n'est pas avec un prix supplémentaire car les règles pour les "sections inutiles" doivent être écrites lorsque les sections sont utilisées...)</li> <li>encapsulation: aucune méthode C++ de la classe CParameterStore ne devrait être utilisée en dehors de la classe @Parameters@ python, ie le code python api (hormis Parameters.py) et client<br/> ne doivent pas accéder au CParameterStore.</li> </ul> <p>n'hésitez pas à compléter/corriger (j'ai desassigné cette issue pour l'instant).</p> <p>Comment by Didier Vibert on 2023-08-23 10:13:27:<br/> @fdufresne voici la réponse à tes questions:</p> <p>Recap questions restantes sur les paramètres:</p> <h3><a name="1Actuellement%2Cebmvestrequisdanslescaso%C3%B9ismfitestenabledquelquepart.Ajoutd%27unwarnings%27ilestpr%C3%A9sentalorsqueismfitenablednulpart%3F"></a>1 - Actuellement, ebmv est requis dans les cas où ismfit est enabled quelque part. Ajout d'un warning s'il est présent alors que ismfit enabled nul part ?</h3> <p>c'est la question des param inutiles... que fait-t-on dans les autres cas ??? je ne me souviens plus de ce qu'on avait dit.<br/> Peut-etre coder le check avec un mode plus permissif: en mode strict on raise dès qu'un param inutile est présent, en mode permissif on laisse passer (ou warning ? )</p> <h3><a name="2V%C3%A9rifierqu%27onpeutsupprimer%3A"></a>2 - Vérifier qu'on peut supprimer:</h3> <ul> <li>2.1 - templateCatalog.continuumRemoval.decompScales</li> <li>2.2 - templateCatalog.continuumRemoval.binpath</li> </ul> <p>oui tu peux</p> <h3><a name="3Dansquelscaslinemeasdzhalfestilobligatoire%3F"></a>3 - Dans quels cas linemeas_dzhalf est-il obligatoire ?</h3> <p>tout le temps (idem pour linemeas_redshiftstep)</p> <h3><a name="4Dansquelscaslinemeasredshiftstepestilobligatoire%3F"></a>4 - Dans quels cas linemeas_redshiftstep est-il obligatoire ?</h3> <p>idem</p> <h3><a name="5PeutonsupprimerLineModelSolve.linemodel.extremacutprobathreshold%3F"></a>5 - Peut-on supprimer LineModelSolve.linemodel.extremacutprobathreshold ?</h3> <p>non on garde. Il est actif dans le code. Mais on desactive son utilisation en le mettant à -1. On reste comme ça</p> <h3><a name="6PeutonsupprimerLineModelSolve.linemodel.modelpriorzStrength%3F"></a>6 - Peut-on supprimer LineModelSolve.linemodel.modelpriorzStrength ?</h3> <p>oui, plus de trace dans le code c++</p> <h3><a name="7Peutonsupprimerlinemodel.pdf.bestzoption%3FSinon%2Cdansquelscasestil%C3%A0sp%C3%A9cifier%3F"></a>7 - Peut-on supprimer linemodel.pdf.bestzoption ? Si non, dans quels cas est il à spécifier ?</h3> <p>oui, plus de trace dans le code c++</p> <h3><a name="8PeutonsupprimertemplateCatalog.continuumRemoval.binpathetcontinuumRemoval.binpath%3F"></a>8 - Peut on supprimer templateCatalog.continuumRemoval.binpath et continuumRemoval.binpath ?</h3> <p>oui (idem 2. ?)</p> <h3><a name="9PeutonsupprimertemplateCatalog.continuumRemoval.decompScalesetcontinuumRemoval.decompScales%3F"></a>9 - Peut-on supprimer templateCatalog.continuumRemoval.decompScales et continuumRemoval.decompScales ?</h3> <p>oui (idem 2. ?)</p> <h3><a name="10Dansquelscasobject.linemodelsolve.linemodel.continuumfitestil%C3%A0pr%C3%A9ciser%3F"></a>10 - Dans quels cas object.linemodelsolve.linemodel.continuumfit est-il à préciser ?</h3> <p>lorsque que object.linemodelsolve.linemodel.continuumcomponent = tplfit*<br/> (mais si on applique ça il y a qq petit bug dans le code c++ où les param peuvent être lus alors qu'ils ne sont pas pertinents...<br/> => ouvir un ticket pour ça: je m'en charge #8231 <del>et je le marque comme bloquant du ticker parameters</del> )</p> <h3><a name="11Peutonsupprimerobject.LineMeasSolve.linemodel.polynomialdegree%3FSinon%2Cdansquelscasestil%C3%A0sp%C3%A9cifier%3F"></a>11 - Peut-on supprimer object.LineMeasSolve.linemodel.polynomialdegree ? Si non, dans quels cas est-il à spécifier ?</h3> <p>non, il faut le conserver. Le code le lit, mais par erreur ne s'en sert pas. Il y a un ticket pour réparer ça.</p> <h3><a name="12Ilsemblaitqu%27ilyavaitdesparam%C3%A8tresmanquantsdansobject.LineMeasSolve.Quelssontcesparam%C3%A8tresmanquants%3F"></a>12 - Il semblait qu'il y avait des paramètres manquants dans object.LineMeasSolve. Quels sont ces paramètres manquants ?</h3> <p>?</p> <p>la liste qui est présente dans le parameters_base.json est incomplète si velocityfit=true cf la variation linemeas_lbfgsb qui introduit les 4 param supplémentaires:<br/> emvelocityfitmin, emvelocityfitmax, absvelocityfitmin, absvelocityfitmax</p> <p>Comment by Fanny Dufresne on 2023-08-23 14:49:26:<br/> 1- Concernant comment gérer les paramètres des paramètres inutiles, je propose:</p> <ul class="alternate" type="square"> <li>Si c'est un paramètre "inconnu" qui dans tous les cas n'est jamais utililsé (ex il y a eu une typo), raise une erreur</li> <li>Si c'est un paramètres parfois utile mais dans ce cas précis inutilisé, mettre un warning</li> </ul> <p>12. Ça me paraît étonnantdans le cas de linemodelen plus des emvelocityfitmin max etc on précise également obligatoirement les step, ce qu'on ne fait pas là. Est-ce bien voulu ?</p> <p>Comment by Didier Vibert on 2023-08-23 15:41:30:<br/> Fanny Dufresne wrote in #note-15:<br/> > 1- Concernant comment gérer les paramètres des paramètres inutiles, je propose:<br/> > - Si c'est un paramètre "inconnu" qui dans tous les cas n'est jamais utilisé (ex il y a eu une typo), raise une erreur<br/> > - Si c'est un paramètre parfois utile mais dans ce cas précis inutilisé, mettre un warning</p> <p>parfait</p> <p>> 12. Ça me paraît étonnant dans le cas de linemodelen plus des emvelocityfitmin max etc on précise également obligatoirement les steps, ce qu'on ne fait pas là. Est-ce bien voulu ?</p> <p>comme discuté oralement, pas de <span class="error">[em|abs]</span>velocityfitstep pour linemeas.<br/> en fait le fitter lbfgsb (le fitter est défini par le param fittingmethod) utilise le param velocityfit (true/false) et les min/max pour fitter la vitesse avec un algo de descente de gradient (c'est cet algo qui détermine le step à chaque pas. En revanche les autres fitter (individual/hybrid/svd...) n'utilisent directement pas ces paramètres. C'est l'opérateur linemodel qui les utilise en faisant une boucle avec un step lors de la seconde passe (dans COperatorLineModel::EstimateSecondPassParameters) donc uniquement dans la méthode linemodelsolve.</p> <p>pour résumer: </p> <ul> <li>linemodelSolve: velocityfit(true/false) nécessaire, si true (les step,min,max de <span class="error">[em|abs]</span>velocityfit sont nécessaires sinon inutiles (mais le code les lit sans doute ? ) qq soit la fittingmethod</li> <li>linemeasSolve: fittingmethod != lbfgs tout les param velocityfit sont inutiles (le true/false aussi), sinon ils sont nécessaires (mais sans le step)</li> </ul> <p>Comment by Fanny Dufresne on 2023-08-23 16:41:27:<br/> Et une nouelle question !<br/> a. Le champ priors est-il obligatoire dans line_model_continuum_fit ?<br/> b. Dans priors, tous les champs sont-ils obligatoires ?<br/> c. J'avais noté de mettre linemeas_dzhalf en "required", mais il n'est pas présent partout, dans quels cas est-il attendu ?<br/> d. Idem pour linemeas_redshiftstep ?<br/> e. Idem pour enable_reliability</p> <p>Comment by Didier Vibert on 2023-08-24 12:40:07:<br/> Fanny Dufresne wrote in #note-17:<br/> > Et une nouelle question !<br/> > Le champ priors est-il obligatoire dans line_model_continuum_fit ?<br/> > Dans priors, tous les champs sont-ils obligatoires ?</p> <p>oui pour l'instant. En fait ils ne sont utiles que lorsque @priors.catalog_dirpath@ correspond à un répertoire existant. Si le repertoire n'est pas trouvé, l'objet @CPriorHelper@ est instancié avec un @mInitFaild@ avec un warning. Typiquement, aujourd'hui pour désactiver l'usage de ces priors, on met @priors.catalog_dirpath: ""@.<br/> il Faudrait rajouter un param bool @enable_priors@. Et en fonction rendre la suite nécessaire ou inutile. avec une exception si l'initialisation se passe mal lorsque enable est True => un peu de dev c++ à faire (mais pas très compliqué: je rajoute un ticket => #8229)</p> <p>rmq: idem pour les params @tplratio.priors@</p> <p>Comment by Didier Vibert on 2023-08-24 13:19:41:<br/> Fanny Dufresne wrote in #note-17:</p> <p>> c. J'avais noté de mettre linemeas_dzhalf en "required", mais il n'est pas présent partout, dans quels cas est-il attendu ?<br/> il devrait ! il est nécessaire dans la section linemeasSolve</p> <p>> d. Idem pour linemeas_redshiftstep ?<br/> idem </p> <p>> e. Idem pour enable_reliability<br/> obligatoire pour l'instant. Pour le refactor ultérieur, si on opte pour des bool partout pour activer/désactiver certaines sections ou si la présence d'une section suffit à l'activer.</p> <p>Comment by Didier Vibert on 2023-09-07 14:06:57:<br/> juste une petite description à modifier (cf dernier commentaire non resolved sur gitlab) , je passe en feedback ensuite</p> <p>Comment by Fanny Dufresne on 2023-09-07 14:16:41:<br/> C'est corrigé, j'ai ajouté la modif de la description au commit déjà existant "code review corrections"</p> <p>Comment by Pierre-yves Chabaud on 2023-09-12 09:53:55:<br/> Merged into @develop@ (@f807415a@)</p> Development Rank 0|zzs7ns: