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-375 1D Redmine <p><em><font color="#505f79"> Created on 2023-12-07 09:34:32 by Thomas Bedrine. % Done: 100</font></em></p> <p>Dans l'issue #7752 nous avons posé les bases de l'API pour l'export d'attributs, on doit maintenant poursuivre cette avancée avec certains points encore non résolus ou améliorables du ticket de base.</p> <p>Pour rappel, l'API actuelle reprend une partie du comportement de l'ancienne API et retourne les attributs demandés sous forme de liste ordonnée (si on a la liste @attribute_list@ en entrée correspondant à @<span class="error">&#91;&quot;SpectrumID&quot;, &quot;galaxy.Redshift&quot;, &quot;mismatch.class&quot;&#93;</span>@, les attributs retournés seraient par exemple @<span class="error">&#91;&quot;spec_100001&quot;, &quot;1.0&quot;, &quot;success&quot;&#93;</span>@). Les fonctions individuelles @get_attributes@ et @get_logpdfs@ n'ont pas été implémentées car nous avons établi que séparer les deux opérations serait redondant dans la lecture des fichiers. De plus, il est possible de répliquer le comportement de ces fonctions en passant l'argument @include_pdfs@ à False (ce qui indique de ne pas récupérer les infos de la PDF) ou en fournissant une @attribute_list@ vide (ce qui indique de ne pas récupérer d'attributs).</p> <p>On souhaite maintenant améliorer l'API pour inclure les points manquants qui permettront de la rendre plus générale, en précisant le type d'objet pour la pdf (galaxy/star/qso, pour remplacer la version actuelle qui considère uniquement galaxy)</p> <p>Jusqu'à présent, la liste des attributs que l'on souhaitait exporter devait être connue à la base par l'utilisateur, l'objectif est d'y remédier et de proposer un moyen de demander les attributs disponibles via l'API (avec la fonction @get_all_attributes@). Notamment, on doit aussi considérer les différents types d'attributs possibles : </p> <ul class="alternate" type="square"> <li>scalaires de l'output Amazed (exemples : galaxy.Redshift, qso.Redshift)</li> <li>vectoriels de l'output Amazed (exemple : galaxy.PDFProbaLog)</li> <li>scalaires de la référence (exemple : ref.redshift)</li> <li>scalaires calculés par AmazedOutput (exemple : mismatch.class)</li> </ul> <p>Il faut donc établir si une distinction doit être faite entre ces attributs, à l'heure actuelle il n'y a pas de séparation entre eux et ils sont tous traités de façon équivalente. Doit-on créer des sous-listes d'attributs qui correspondent à ces catégories ?</p> REDMINE1D-375

[RM-8528] [AmazedOutputAnalyzer] Amélioration de l'API d'export d'attributs

Task Normal Done Done Redmine-Jira Migtation Redmine-Jira Migtation Mon, 18 Dec 2023 18:17:48 +0000 Mon, 8 Jan 2024 18:17:21 +0000 Thu, 4 Jan 2024 18:17:48 +0000 0 1 <p>Comment by Thomas Bedrine on 2023-12-12 16:00:07:</p> <h3><a name="Petitemise%C3%A0jourdecequej%27aietcequejecomptefaire%3A"></a>Petite mise à jour de ce que j'ai et ce que je compte faire :</h3> <p>Pour récupérer les attributs de façon générique, j'ai discuté avec Ali et on a décidé de modifier la fonction @get_attribute_short@ dans <b>AbstractOutput</b> , côté pylibamazed donc. Les premières modifications sont un succès, on est capables de récupérer des éléments de façon plus simple, y compris des attributs relatifs à la PDF, et ce quel que soit le type d'objet (galaxy, star, qso). Je vous laisse y jeter un oeil si vous voulez constater, c'est push ici : <a href="https://gitlab.lam.fr/CPF/cpf-redshift/-/blob/fix_issue_8528/pylibamazed/python/pylibamazed/AbstractOutput.py" class="external-link" rel="nofollow">https://gitlab.lam.fr/CPF/cpf-redshift/-/blob/fix_issue_8528/pylibamazed/python/pylibamazed/AbstractOutput.py</a></p> <p>La prochaine étape est de refléter ces changements côté AmazedOutputAnalyzer, dans notre API. J'ai réalisé qu'on doit maintenant faire attention au fait que la PDF soit en grille fine ou en grille irrégulière. Les progrès mentionnés juste au-dessus permettent de récupérer @PDFProbaLog@ en grille irrégulière sans problème (c'est la valeur par défaut, si j'ai bien compris), mais pour avoir une grille fine, il faut passer par le <b>PdfHandler</b> de la lib. Il faut qu'on puisse indiquer dans notre attribut si on souhaite l'une ou l'autre grille, afin de savoir si on récupère la log telle quelle (comme n'importe quel autre attribut) ou si on la régularise (donc quelques opérations supplémentaires nécessaires). J'ai eu une idée dont j'ai discuté avec Ali, séparer l'attribut @PDFProbaLog@ du "results_specifications" en deux attributs, l'un qui correspondrait à la grille fine et l'autre à la grille irrégulière (par exemple @PDFProbaLogReg@ pour la première et @PDFProbaLog@ pour la seconde, pas de changement vu que c'est déjà l'attribut par défaut). L'API pourrait faire la distinction et récupérera la même valeur dans les deux cas, mais dans le premier, il fera la conversion d'abord. Si vous avez des remarques ou des questions sur ce point, n'hésitez pas</p> <p>Comment by Didier Vibert on 2023-12-13 08:52:51:<br/> Thomas Bedrine wrote in #note-5:</p> <p>&gt; J'ai eu une idée dont j'ai discuté avec Ali, séparer l'attribut @PDFProbaLog@ du "results_specifications" en deux attributs, l'un qui correspondrait à la grille fine et l'autre à la grille irrégulière (par exemple @PDFProbaLogReg@ pour la première et @PDFProbaLog@ pour la seconde, pas de changement vu que c'est déjà l'attribut par défaut). L'API pourrait faire la distinction et récupérera la même valeur dans les deux cas, mais dans le premier, il fera la conversion d'abord. Si vous avez des remarques ou des questions sur ce point, n'hésitez pas</p> <p>L'idée de produire 2 attributs différents dans l'API me va. Mais je ne comprends pas que ces attributs soient dans le result_specification.csv ? Car c'est la lecture des hdf5 via l'API qui produit ces attributs. Mais le result_specification.csv sert à définir les dataset du format hdf5 amazed, à partir des données du resultStore. Or le hdf5 contient la PDF native, non interpolée, et les paramètres permettant de calculer la grilleZ. Et l'API via l'objet PDF Handler est capable de produire d'autres quantités. Il faut donc un autre fichier que le result_specifiation.csv pour définir ça non ?</p> <p>Attention aussi, que la notion de pdf "irrégulière" ne vaut que pour le linemodel. Pour templatefitting, les pdf sont "régulières".</p> <p>Je propose aussi de changer le nommage. En effet reg pour regular alors que la pdf est typiquement échantillonnée en log(z+1) et le pas constant est donc logarithmique (ceci dépend du paramètre redshiftsampling qui peut être "log" ou "lin"). <br/> Par ailleurs "ProbaLog" sous-entend log de la densité de proba, et proba est redondant avec PDF (Probability Density Function) et incorrect car c'est proba density le bon terme, (une proba c'est intégré sur une plage). <br/> Je propose donc:</p> <ul> <li>@PDFProbaLog@ -&gt; @LogZPdfNative@ (c'est la version native d'amazed, donc avec des pas fins sur les fenêtres secondes pass, dans le cas du linemodel)</li> <li>@PDFProbaLogReg@ -&gt; @LogZPdf@ (c'est la version "régulière" correspondant au pas demandé dans le parameters.json)</li> </ul> <p>Dans le cas template fitting, ces deux attributs renverraient la même chose.</p> <p>et il faut aussi rajouter l'attribut (qui n'y est pas) pour obternir la grille z de la PDF:</p> <ul> <li>@LogZPdfNativeZgrid@</li> <li>@LogZPdfZgrid@</li> </ul> <p>c'est une proposition, à modifier selon vos retours.</p> <p>Comment by Thomas Bedrine on 2023-12-13 13:18:48:<br/> Didier Vibert wrote in #note-6:</p> <p>&gt; L'idée de produire 2 attributs différents dans l'API me va. Mais je ne comprends pas que ces attributs soient dans le result_specification.csv ? Car c'est la lecture des hdf5 via l'API qui produit ces attributs. Mais le result_specification.csv sert à définir les dataset du format hdf5 amazed, à partir des données du resultStore. Or le hdf5 contient la PDF native, non interpolée, et les paramètres permettant de calculer la grilleZ. Et l'API via l'objet PDF Handler est capable de produire d'autres quantités. Il faut donc un autre fichier que le result_specifiation.csv pour définir ça non ?</p> <p>Bien vu, ça n'aurait pas de sens de définir des attributs qui n'existent pas directement dans les datasets de base, ils correspondent plutôt à des attributs calculés (comme @mismatch.class@ en quelque sorte, c'est comme ça que je le perçois). Donc on explicitera cette séparation des attributs dans l'API, mais le results_specifications n'a effectivement pas besoin d'être modifié dans ce sens selon moi.</p> <p>&gt; Attention aussi, que la notion de pdf "irrégulière" ne vaut que pour le linemodel. Pour templatefitting, les pdf sont "régulières".</p> <p>Merci pour la précision, je n'étais pas au courant.</p> <p>&gt; Je propose aussi de changer le nommage. En effet reg pour regular alors que la pdf est typiquement échantillonnée en log(z+1) et le pas constant est donc logarithmique (ceci dépend du paramètre redshiftsampling qui peut être "log" ou "lin"). <br/> &gt; Par ailleurs "ProbaLog" sous-entend log de la densité de proba, et proba est redondant avec PDF (Probability Density Function) et incorrect car c'est proba density le bon terme, (une proba c'est intégré sur une plage). <br/> &gt; Je propose donc:<br/> &gt; * @PDFProbaLog@ -&gt; @LogZPdfNative@ (c'est la version native d'amazed, donc avec des pas fins sur les fenêtres secondes pass, dans le cas du linemodel) <br/> &gt; * @PDFProbaLogReg@ -&gt; @LogZPdf@ (c'est la version "régulière" correspondant au pas demandé dans le parameters.json)<br/> &gt; <br/> &gt; Dans le cas template fitting, ces deux attributs renverraient la même chose.<br/> &gt; <br/> &gt; et il faut aussi rajouter l'attribut (qui n'y est pas) pour obternir la grille z de la PDF:<br/> &gt; * @LogZPdfNativeZgrid@<br/> &gt; * @LogZPdfZgrid@</p> <p>Le renommage me paraît cohérent, cependant Ali m'a fait remarquer que l'on risque de déborder du cadre de cette issue en renommant des attributs. Je suis tout à fait d'accord pour rajouter l'attribut de la ZGrid en revanche, et ce même dans cette issue - le but est d'étendre les capacités de l'API pour récupérer un maximum d'attributs de façon générique, donc inclure un attribut qui n'était pas présent jusque-là me paraît être une bonne idée.</p> <p>Comment by Thomas Bedrine on 2023-12-15 17:12:53:</p> <h3><a name="Changementsetprogr%C3%A8sr%C3%A9alis%C3%A9s"></a>Changements et progrès réalisés</h3> <p>Sur les conseils de Didier, j'ai implémenté la possibilité de différencier le fait de vouloir la grille native ou la grille régulière. On doit indiquer le mot-clé "Native" à la fin de l'attribut que l'on souhaite récupérer pour obtenir la grille native.</p> <p><em>Exemple :</em> @galaxy.PDFProbaLogNative@ (et @galaxy.PDFProbaLog@ pour la régulière)</p> <p>Je n'ai pas renommé l'attribut de la log dans le 'results_specifications', je n'avais pas compris que ce n'était pas quelque chose qu'on peut ou qu'on doit modifier à la légère. L'attribut s'appelle donc toujours @PDFProbaLog@. L'autre attribut mentionné par Didier, la ZGrid, peut être récupérée avec l'attribut @LogZPdfZGrid@, comme suggéré. Sa contrepartie native suit la même règle que la log : @LogZPdfZGridNative@.</p> <p>L'API renvoie maintenant les attributs scalaires et vectoriels sans distinction. Il conviendra donc à la personne qui l'implémente de garder en tête quels attributs sont scalaires ou non, et les extraire en conséquence. L'implémentation de la fonction qui est appelée par @amzexportml@ fait ce traitement explicitement, pour sauvegarder la logpdf à part. Son fonctionnement est donc inchangé, cependant il ne requiert plus le paramètre '--include_pdfs', à la place il faut simplement rajouter @&lt;object_type&gt;.PDFProbaLogNative@ avec le reste des attributs.</p> <p>La prochaine étape sera de réaliser la fonction @get_all_attributes@ dans une prochaine issue, afin de récupérer la liste complète des attributs pouvant être récupérés. Il est clair que nous avons besoin de cette fonction, qui devra renvoyer autant d'informations que possible sur les attributs présents dans les différents fichiers de résultats, mais aussi ceux qui peuvent être calculés.</p> <p><ins>pylibamazed :</ins> <a href="https://gitlab.lam.fr/CPF/cpf-redshift/-/merge_requests/570" class="external-link" rel="nofollow">https://gitlab.lam.fr/CPF/cpf-redshift/-/merge_requests/570</a><br/> <ins>amazed-output-analyzer :</ins> <a href="https://gitlab.lam.fr/amazed/amazed-output-analyzer/-/merge_requests/23" class="external-link" rel="nofollow">https://gitlab.lam.fr/amazed/amazed-output-analyzer/-/merge_requests/23</a></p> <p>Comment by Thomas Bedrine on 2024-01-04 14:40:42:<br/> Avant de valider cette issue, il faut valider celle de Fanny (#8219) qui est elle-même dépendante de la #8312. J'ai tout de même implémenté le changement de nom de l'attribut @PDFProbaLog@ en @LogZPdf@ dans @results_specifications.csv@</p> <p>Comment by Thomas Bedrine on 2024-01-08 14:44:54:<br/> J'ai fait quelques changements dans la doc du DataModel : <a href="https://projets.lam.fr/projects/cpf/wiki/GeneralDataModel#Scoped-attribute-naming" class="external-link" rel="nofollow">https://projets.lam.fr/projects/cpf/wiki/GeneralDataModel#Scoped-attribute-naming</a>. J'y ai indiqué des changements récents, précisé les attributs qui n'apparaissent pas dans les specs et essayé de donner plus d'exemples. S'il y a quoi que ce soit qui vous semble bizarre ou incorrect, ou si vous trouvez qu'il manque quelque chose, n'hésitez pas à modifier. Si ça convient à tout le monde pour l'instant, je n'ai plus rien à ajouter sur cette issue et on reviendra sur les points manquants (récupérer la liste complète des attributs qu'il est possible d'extraire notamment) dans une future issue, comme on en avait discuté avant les vacances</p> Development Rank 0|zzt0p3: