Comment by Thomas Bedrine on 2023-12-12 16:00:07:

Petite mise à jour de ce que j'ai et ce que je compte faire :

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 AbstractOutput , 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 : https://gitlab.lam.fr/CPF/cpf-redshift/-/blob/fix_issue_8528/pylibamazed/python/pylibamazed/AbstractOutput.py

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 PdfHandler 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

Comment by Didier Vibert on 2023-12-13 08:52:51:
Thomas Bedrine wrote in #note-5:

> 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

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 ?

Attention aussi, que la notion de pdf "irrégulière" ne vaut que pour le linemodel. Pour templatefitting, les pdf sont "régulières".

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").
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).
Je propose donc:

• @PDFProbaLog@ -> @LogZPdfNative@ (c'est la version native d'amazed, donc avec des pas fins sur les fenêtres secondes pass, dans le cas du linemodel)
• @PDFProbaLogReg@ -> @LogZPdf@ (c'est la version "régulière" correspondant au pas demandé dans le parameters.json)

Dans le cas template fitting, ces deux attributs renverraient la même chose.

et il faut aussi rajouter l'attribut (qui n'y est pas) pour obternir la grille z de la PDF:

• @LogZPdfNativeZgrid@
• @LogZPdfZgrid@

c'est une proposition, à modifier selon vos retours.

Comment by Thomas Bedrine on 2023-12-13 13:18:48:
Didier Vibert wrote in #note-6:

> 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 ?

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.

> Attention aussi, que la notion de pdf "irrégulière" ne vaut que pour le linemodel. Pour templatefitting, les pdf sont "régulières".

Merci pour la précision, je n'étais pas au courant.

> 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").
> 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).
> Je propose donc:
> * @PDFProbaLog@ -> @LogZPdfNative@ (c'est la version native d'amazed, donc avec des pas fins sur les fenêtres secondes pass, dans le cas du linemodel)
> * @PDFProbaLogReg@ -> @LogZPdf@ (c'est la version "régulière" correspondant au pas demandé dans le parameters.json)
>
> Dans le cas template fitting, ces deux attributs renverraient la même chose.
>
> et il faut aussi rajouter l'attribut (qui n'y est pas) pour obternir la grille z de la PDF:
> * @LogZPdfNativeZgrid@
> * @LogZPdfZgrid@

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.

Comment by Thomas Bedrine on 2023-12-15 17:12:53:

Changements et progrès réalisés

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.

Exemple : @galaxy.PDFProbaLogNative@ (et @galaxy.PDFProbaLog@ pour la régulière)

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@.

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 @<object_type>.PDFProbaLogNative@ avec le reste des attributs.

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.

pylibamazed : https://gitlab.lam.fr/CPF/cpf-redshift/-/merge_requests/570
amazed-output-analyzer : https://gitlab.lam.fr/amazed/amazed-output-analyzer/-/merge_requests/23

Comment by Thomas Bedrine on 2024-01-04 14:40:42:
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@

Comment by Thomas Bedrine on 2024-01-08 14:44:54:
J'ai fait quelques changements dans la doc du DataModel : https://projets.lam.fr/projects/cpf/wiki/GeneralDataModel#Scoped-attribute-naming. 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