Comment by Vincent Le Brun on 2022-12-07 08:16:55:

Comment by Vincent Le Brun on 2022-12-07 08:50:42:
répertoire /net/CESAM/amazed/vlebrun/Euclid_FORNAX_DEEP_ELC2020/output_0.36_QSOlm

Comment by Didier Vibert on 2023-01-18 17:57:44:
Finalement ça me parait normal au vu de ce qui est codé. À voir s’il faut changer le comportement:

la règle @strongweak@ (comme toutes les autres règles) se contente de modifier les amplitudes des raies pour respecter la contrainte.
Dans le cas @strongweak@, on force les amplitudes weak à avoir une amplitude inférieure ou égale à l'amplitude strong la plus forte, si aucune raie strong n'est observée, rien ne se passe.

Donc tu es dans le cas où, pour un z donné, il n'y a pas de raie strong. Si tu veux pénaliser ces cas là, il faut utiliser le prior @stronglinesprior@

Comment by Vincent Le Brun on 2023-01-19 09:35:42:
OK je vais tester avec le prior, par contre la règle serait plus cohérente si les raies 'weak' étaient toute plus faibles que la raie 'strong' la plus faible.

Comment by Didier Vibert on 2023-01-19 09:45:37:
Vincent Le Brun wrote in #note-6:
> OK je vais tester avec le prior, par contre la règle serait plus cohérente si les raies 'weak' étaient toute plus faibles que la raie 'strong' la plus faible.

ok on peut effectivement changer la règle.

Comment by Fanny Dufresne on 2023-06-01 14:55:33:
Au delà du changement raies weak toutes plus faibles que la raie strong la plus faible vs strong, j'ai tenté de comprendre un peu ce qu'il se passe dans le code pour cette "rule strong higher than weak":

Ce qui est actuellement fait:
<pre>
1. on cherche la raie strong avec l'amplitude la plus forte dans l'ensemble des raies de l'ensemble des éléments (un élement c'est un ensemble de raies comme défini dans le catalog)
2. on boucle sur les éléments
a. On vérifie qu'on est bien dans le cas du type de raies qu'on souhaite (émission/absorption)
b. On boucle sur les raies
i. On vérifie qu'on est bien dans lambda range souhaité
ii. Dans le cas d'une line weak:

• Si son amplitude > amplitude raie strong + erreur :
• Je diminue son amplitude à la limite souhaitée (amplitude raie strong + erreur)
• Je diminue l'amplitude de TOUTES les raies de l'élément, d'un ratio similaire à celle de la ligne précédente
  </pre>

Est-ce que c'est bien ça qu'on souhaite faire ?
De ce que je comprends, ce qui me paraît étonnant:

• Vu qu'on diminue l'amplitude de toutes les raies, on diminue l'amplitude des raies strong également, et du coup ça ne nous fait pas beaucoup avancer ?
• Est-ce qu'on veut bien considérer l'erreur (de la raie strong uniquement) dans la comparaison des amplitudes ? amplitude raie < amplitude raie strong + erreur ça ne me paraît pas très "équitable" comme comparaison

Comment by Vincent Le Brun on 2023-06-01 15:41:59:
je crois que je comprends, on est dans le cas du linemodel 'free' c'est à dire que les amplitudes individuelles des raies sont totalement libre... et dans le cas que je présente il n'y a aucune raie forte dans le lambda range pour cette solution. Donc je ne sais pas quelle comparaison est faite là
<pre>

• Si son amplitude > amplitude raie strong + erreur :
  </pre>

Comment by Didier Vibert on 2023-06-01 17:59:01:
Vincent Le Brun wrote in #note-10:
> je crois que je comprends, on est dans le cas du linemodel 'free' c'est à dire que les amplitudes individuelles des raies sont totalement libre... et dans le cas que je présente il n'y a aucune raie forte dans le lambda range pour cette solution. Donc je ne sais pas quelle comparaison est faite là
> [...]

<pre>
amplitude > amplitude raie strong + erreur
</pre>

la comparaison est explicite non ?

• amplitude: amplitude mesurée de la raie considérée (le profil est a*exp-0.5(lbda - lbda_ref)^2/width^2 où a est l'amplitude )
• amplitude raie strong -> amplitude de la plus forte rais strong observée
• erreur: racine-carrée de la variance (1 sigma uncertainty) estimée de l'amplitude de la raie considérée

Comment by Didier Vibert on 2023-06-01 18:24:48:
Fanny Dufresne wrote in #note-9:
> Au delà du changement raies weak toutes plus faibles que la raie strong la plus faible vs strong, j'ai tenté de comprendre un peu ce qu'il se passe dans le code pour cette "rule strong higher than weak":
>
> Ce qui est actuellement fait:
> [...]

ok c'est bien ça. Juste pour info, un "element" est un ensemble de raies pour lesquelles une amplitude unique est fittée (ie toutes les raies d'un élément ont des rapports de raies fixés, et on fitte une amplitude unique pour un "multi" profil contenant l'ensemble des raies avec leur ratio respectifs). Dans le cas d'un "template ratio" ll y a un seul élément pour toutes les raies en emission (et un autre pour les raies en absorption). Mais l'application des règles ne concerne pas le cas "template ratio". Dans le cas linemodel "free" (ce qui veut dire pas de template-ratio), avec ou sans application de règles, la plupart des éléments n'ont qu'une seule raie, sauf quelques doublets fixés.

> Est-ce que c'est bien ça qu'on souhaite faire ?
oui c'est ce qu'on souhaite faire, avec la modif proposée par cette issue de prendre la raie strong la plus faible observée plutôt que la plus forte.

> De ce que je comprends, ce qui me paraît étonnant:
> - Vu qu'on diminue l'amplitude de toutes les raies, on diminue l'amplitude des raies strong également, et du coup ça ne nous fait pas beaucoup avancer ?
lorsqu'on "corrige" un élément, donc lorsque qu'on décide de diminuer son amplitude, nécessairement on conserve les ratio dans l'élément et on modifie donc proportionnellement toutes les amplitudes de l'élément.
Ce qui t'étonne peut-être c'est la possibilité d'avoir un élément qui contiennent une raie strong et une raie weak ?
Ce cas n’existe pas, mais c'est vrai que c'est implicite et que le code ne se protège pas contre ça. Si tu veux, on peut rajouter une condition pour ne corriger que les elt qui ne contiennent aucune raie strong.

> - Est-ce qu'on veut bien considérer l'erreur (de la raie strong uniquement) dans la comparaison des amplitudes ? amplitude raie < amplitude raie strong + erreur ça ne me paraît pas très "équitable" comme comparaison

Alain avait testé plusieurs façons de faire, on peut en reparler et inclure l'incertitude sur la raie à corriger éventuellement cf code commenté dans la fonction: https://gitlab.lam.fr/CPF/cpf-redshift/-/blob/release-0.42/RedshiftLibrary/src/lib/line/ruleStrongHigherThanWeak.cpp#L94

Comment by Fanny Dufresne on 2023-06-02 12:50:30:
Ok génial merci pour toutes ces explications !

Comment by Didier Vibert on 2023-06-19 09:56:03:
MR: https://gitlab.lam.fr/CPF/cpf-redshift/-/merge_requests/504

Comment by Pierre-yves Chabaud on 2023-06-30 12:25:03:
Merged into @develop@ (@9ca3c356@)