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-113 1D Redmine <p><em><font color="#505f79"> Created on 2023-03-14 08:20:44 by Didier Vibert. % Done: 100</font></em></p> <p>in c++ the line identification is sometime done through the linename </p> <p>cf </p> <ul> <li>CLineCatalog::Add</li> <li>CLineCatalogsTplRatio::InitLineCorrespondingAmplitudes</li> <li>...</li> </ul> <p>may be change @TLineVector CLineCatalog::m_List@ to be a map with line strID as key</p> REDMINE1D-113

[RM-7959] [linemodel] use line strID everywhere in C++ code instead of line name and type

Task Normal Done Done Redmine-Jira Migtation Redmine-Jira Migtation Tue, 13 Jun 2023 05:14:34 +0000 Thu, 5 Oct 2023 18:33:05 +0000 Thu, 5 Oct 2023 18:33:05 +0000 0 2 <p>Comment by Didier Vibert on 2023-07-07 09:23:12:<br/> after discussions this morning:<br/> instead of having two keys (an integer ID and the composed string str_Id), we keep inside the C++ class a unique integer key.<br/> When we add a new line in the catalog (in C++ called by python api) we check the unicity of the str_Id, and then forget about it (we keep the list only for checking unicity in add). Then all direct access to a specific line are done via the integer id and the linecatalog will be a map instead of a vector of lines</p> <p>Comment by Didier Vibert on 2023-09-14 14:03:38:<br/> MR: <a href="https://gitlab.lam.fr/CPF/cpf-redshift/-/merge_requests/540" class="external-link" rel="nofollow">https://gitlab.lam.fr/CPF/cpf-redshift/-/merge_requests/540</a></p> <p>Comment by Didier Vibert on 2023-09-19 13:39:17:<br/> gros problème d'augmentation du temps de calcul du à l'accès indirect des raies dans des std::map au lieu de std::vector</p> <p>a priori revenir à un accès direct au moins dans les CElement.</p> <p>Comment by Didier Vibert on 2023-09-29 13:33:47:<br/> le fix de l'utilisation des id des raies semble corriger un pb linemeas (cf #8248) dû à un mélange des raies dans le hybridfitter concernant la détermination des raies qui se chevauchent et donc du polynôme commun pour fitter le continu...</p> <p>sur le test d'intégration sp8_linemeas_lbfgsb<br/> avant:<br/> <img src="https://pfspipe.ipmu.jp/jira/images/icons/attach/noimage.png" imagetext="Capture%20d%E2%80%99%C3%A9cran%20du%202023-09-29%2015-10-24.png" align="absmiddle" border="0" /></p> <p>après:<br/> <img src="https://pfspipe.ipmu.jp/jira/images/icons/attach/noimage.png" imagetext="Capture%20d%E2%80%99%C3%A9cran%20du%202023-09-29%2015-25-17.png" align="absmiddle" border="0" /></p> <p>Comment by Vincent Le Brun on 2023-09-29 14:25:15:<br/> parfait... une fin de vendredi comme on les aime...</p> <p>Comment by Didier Vibert on 2023-09-29 14:43:45:<br/> Vincent Le Brun wrote in #note-17:<br/> &gt; parfait... une fin de vendredi comme on les aime...</p> <p>peut être que ça corrige aussi le fit foireux du QSO que tu as vu. C'était en linemodel "free" ou "ratio" ? </p> <p>Comment by Vincent Le Brun on 2023-09-29 14:44:55:<br/> ratio. Dès que c'est en merged dans un vent je ferai un test. Mais ça n'aurait pas du arriver plus souvent ?</p> <p>Comment by Didier Vibert on 2023-09-29 14:51:50:<br/> Vincent Le Brun wrote in #note-19:<br/> &gt; ratio. Dès que c'est en merged dans un vent je ferai un test. Mais ça n'aurait pas du arriver plus souvent ?</p> <p>si il y avait un pb avec linemeas autour de OII depuis longtemps...</p> <p>Comment by Vincent Le Brun on 2023-09-29 15:25:26:<br/> mais mon probleme avec le solver QSO n'a rien à voir avec OII, à moins qu'il y ait eu un mélange d'autres raies dans les linecatalog QSO. Tu as moyen de vérifier ça sur le spectre DESI?</p> <p>Comment by Didier Vibert on 2023-10-02 14:16:50:<br/> IT full</p> <p>Comment by Pierre-yves Chabaud on 2023-10-03 08:56:05:<br/> Merged into @develop@ (ef67328c)</p> Development Rank 0|zzsxif: