Comment by Mira Sarkis on 2021-07-06 08:21:37:
Note:

• Given that we precompute the continuum in the secondpass prior to @estimateSecondPass@, and
• Given that @estimateSecondPass@ uses the @precomputedContinuum@ results in 2 cases: refitfirstpass or retryall.
  if we decide to "correct/weigh" the halfwindowSize using the velocity (i.e., absoption or emission) computed in @estimateSecondPass@, then we need to recompute the continuum for the newly added redshifts.

As a first version, I call @::precomputecontinuum@ after @estimatesecondpass@, only on candidates with estimated velocities>300.

Concerning the windowsize correction:

• correction heurstically starts from velocity = 250 by a step of 100. Velocity ranges are:
  • [20:249] - no correction (N=0),
  • [250:349] - simple correction (N=1),
  • [350:449] - double correction(N=2),
  • [450:500] - triple correction (N=3)
• correction is set heuristically to a multiple (N) of 0.001, as follows
  • corrected_wdw = (m_halfwdwSize + N*0.001)*(1+zcand)

Comment by Vincent Le Brun on 2021-07-06 09:25:34:
Is it necessary to use the value of the velocity? we could use the width and the location of the peak : if the peak is on the edge of the window, or if its width is more than xx% of the window, we go back to the original size

Comment by Mira Sarkis on 2021-07-06 11:37:22:
Vincent Le Brun wrote in #note-4:
> Is it necessary to use the value of the velocity?
To my understanding, we have observed a link between the estimated velocity and the width of the peak thus the idea of "pre-estimating or "customizing" a window size for each candidate.
> we could use the width and the location of the peak : if the peak is on the edge of the window, or if its width is more than xx% of the window, we go back to the original size

I'm not sure what do you mean by "original size"?!
We can imagine fitting around candidates first within the [zc-halfwdwsize; zc+halfwdwsize], and if, as you say, the peak is on the border or its width is much bigger than the secondpass window (passed in param.json), then we decide to extend the fitting by including redshifts from [zc - customHalfwdwsize; zc+customHalfwdwsize].

Comment by Vincent Le Brun on 2021-07-09 14:09:23:
Mira Sarkis wrote in #note-5:
> Vincent Le Brun wrote in #note-4:
> > Is it necessary to use the value of the velocity?
> To my understanding, we have observed a link between the estimated velocity and the width of the peak thus the idea of "pre-estimating or "customizing" a window size for each candidate.
> > we could use the width and the location of the peak : if the peak is on the edge of the window, or if its width is more than xx% of the window, we go back to the original size
>
> I'm not sure what do you mean by "original size"?!
the original window size that allowed to keep all solutions (0.01?)
> We can imagine fitting around candidates first within the [zc-halfwdwsize; zc+halfwdwsize], and if, as you say, the peak is on the border or its width is much bigger than the secondpass window (passed in param.json), then we decide to extend the fitting by including redshifts from [zc - customHalfwdwsize; zc+customHalfwdwsize].
let's try this

Comment by Didier Vibert on 2021-07-12 14:28:40:
I agree with the Vincent proposition. Instead of building several window sizes: ( m_halfwdwSize + N*0.001)*(1+zcand) )

it is simpler to use only two: a fine one (using m_halfwdwSize) for the majority of cases, and then if it fails (large velocity, peak at border) go directly to a large one (as we had before 1e-2)

(note: this change will render #6052 usefull).

Comment by Mira Sarkis on 2021-07-13 10:01:28:
Didier Vibert wrote in #note-7:
> I agree with the Vincent proposition. Instead of building several window sizes: ( m_halfwdwSize + N*0.001)*(1+zcand) )
>
> it is simpler to use only two: a fine one (using m_halfwdwSize) for the majority of cases, and then if it fails (large velocity, peak at border) go directly to a large one (as we had before 1e-2)
>

So you are saying to not customize the window size based on the estimated velocity but simply enlarging the window size if no peaks appear in the PDF slots?

I am not sure this is a good idea given that we can identify border-peaks only after marginalizing the PDF in CPDFz::Compute and calling ::searchMaxPDFcandidates (especially that we dont care about Chi2 peaks) which happens at a relatively advanced stage in CMethodLinemodel.

Comment by Didier Vibert on 2021-07-13 14:46:48:
Mira Sarkis wrote in #note-8:
> Didier Vibert wrote in #note-7:
> > I agree with the Vincent proposition. Instead of building several window sizes: ( m_halfwdwSize + N*0.001)*(1+zcand) )
> >
> > it is simpler to use only two: a fine one (using m_halfwdwSize) for the majority of cases, and then if it fails (large velocity, peak at border) go directly to a large one (as we had before 1e-2)
> >
>
> So you are saying to not customize the window size based on the estimated velocity but simply enlarging the window size if no peaks appear in the PDF slots?
>
not exactly: I still propose to customize the window size based on the estimated velocity , but not to "fine" tune: ie only 2 sizes: small, default one, and if velocity is larger than threshold, big size. there no big gain at increasing by a few steps the size: go directly to the larger size.

> I am not sure this is a good idea given that we can identify border-peaks only after marginalizing the PDF in CPDFz::Compute and calling ::searchMaxPDFcandidates (especially that we dont care about Chi2 peaks) which happens at a relatively advanced stage in CMethodLinemodel.

yes that's true: that's why I proposed at some point to split the work in two, knowing that handling the recompute of the second pass after pdf computation needs some more changes. Moreover, if the job enlarging with velocity is sufficient to remove all the cases where the window is to small, then no need to implement the second step which is harder.

Comment by Didier Vibert on 2021-07-23 13:48:27:
je viens de penser, peut être aussi une autre piste à creuser: calculer la largeur du pic pour chaque candidat 1st pass (on ne le fait pas actuellement) et, en fonction, adapter la taille de la fenêtre 2nd passe ?

Ceci pourrait être fait en plus de l'adaptation avec la vitesse.

ce qui m'y a fait penser, c'est que l'adaptation à partir de la vitesse ne se fait qu'avec des raies en émission, mais quid des spectres dont le pic est essentiellement produit par les raies d'absorption ou du continu tout simplement. On sait qu'on peut obtenir des bons z à bas z, sans raies d’émission, grâce au continu. Les pics sont probablement larges dans ces cas-là .

Comment by Vincent Le Brun on 2021-07-23 14:20:59:
je confirme

Comment by Didier Vibert on 2021-07-30 09:48:01:

recherche d'un proxy pour delta_z final

après quelques investigations par Mira, sur quelques spectres à raie d’émission large, il s'avère que:

• le dz 1st pass n'est pas un bon guess du dz deuxième passe (ce qui est attendu), il n'en demeure pas moins qu'il faut le conserver comme minorant en général pour prendre en compte les spectres sans raies d’émission

• l'estimation de la largeur du pic de la pdf (deltaz/(1+z) à partir de la largeur de la raie sigma_lambda, en considérant que la pdf est l'auto-correlation du profil est fausse (et ne se justifie pas théoriquement...)

estimation analytique de delta_z:

Finalement pour estimer la largeur du pic de la pdf, il vaut mieux utiliser l'expression analytique donnée par Hagen et.al., 2007 (attachment:ao-46-22-5374.pdf), dans le cas de fit d'une Gaussienne 1D, en fonction des paramètres estimés de la Gaussienne :

(eq 16)

où

• x est la position estimée (lambda pour nous, et donc x = lambda_rest *(z+1))
• var est la variance sur la position de la Gaussienne fittée (x=lambda) et donc, delta_z = sqrt( var)/lambda_rest = sqrt( var) * (1+z) / x
• sigma est l'écart-type du bruit par pixel (même unité que le spectre)
• delta_x la taille du pixel (même unité que x, donc en Angtrom)
• w est la largeur de la fitée de la gaussienne (donc la largeur de la raie en incluant LSF et dispersion de vitesse)
• A est l'amplitude fitée de la Gaussienne (même unité que le spectre)

Pour utiliser cette expression il faut disposer de tous les paramètres fittés et principalement la largeur. La boucle de fit de la vitesse se fait avant le calcul de la pdf sur la fenêtre seconde passe (sur une petite plage z autour de la solution 1stpass et en utilisant les résultats du fit 1stpass), on peut donc récupérer la valeur de l'amplitude fitée de la raie la plus intense correspondant, au meilleur fit de la vitesse, ainsi que le niveau de bruit à la longueur d'onde de la raie (il faudrait récupérer ces valeurs à cet endroit dans le code: https://gitlab.lam.fr/CPF/cpf-redshift/-/blob/release-0.22/RedshiftLibrary/src/lib/operator/linemodel.cpp#L1806) pour estimer delta_z et modifier le paramètre HalfwindowSize.

Une autre solution à essayer, pour ne tenir compte que de la largeur est d'éliminer l'amplitude dans l'expression de var et de le remplacer par un SNR minimal (eg 3.5) de la raie afin d'obtenir un majorant de delta_z.

Pour celà, en utilisant l'equation (17) du flux U:

et l'expression de la variance ,var(U), du FLUX estimé (equation 19):

et en posant SNR=U/sqrt(var(U)),

on obtient (calcul à vérifier...):

delta_z = (1+z)*sqrt(var)/x =(1+z)/x*sqrt(4/3*pi) sqrt(w)/SNR

après correction: delta_z = (1+z)*sqrt(var)/x =(1+z)/x*sqrt(4/3) w/SNR (eq. 1)

TODO

• vérifier le calcul de l'expression de delta_z en fonction de (w, SNR) DONE
• faire un run sur un dataset statistiquement représentatif, eg Euclid_GC_E2E_200k, en prenant une taille de fenêtre 2nd pass conservative (eg la valeur qu'on utilisait avant: 1e-2 par exemple).
  Avec les sorties de ce run, récupérer pour chaque spectre, l'amplitude, la largeur et le niveau de bruit sous la raie la plus intense et comparer avec l'expression (delta_x~13 Angstrom pour Euclid), comparer aussi avec l'expression en fonction du SNR en vérifiant qu'avec SNR=3.5 on a bien une borne sup et que celle-ci est là la limite des plus grands delta_z (ie qu'elle ne soit pas trop grande).

Comment by Mira Sarkis on 2021-10-04 13:03:59:
Quelques résultats:
En se basant sur les résultats de 5000 spectres Euclid_GC_E2E_200k (cosmos) dont les valeurs de redshift couvre la globalité du range [0:5].
Pour chaque spectre et pour chacun de ces 5 candidats:
1) je calcule les valeurs de analyticalDeltaz selon les deux formules analytiques: eq. 16 (Meth1) et eq. 1 (Meth2) de la note [https://projets.lam.fr/issues/6508#note-14]
2) je compare ces valeurs entre elles memes et puis à estimatedDeltaz (ou RedshiftUncertainty) obtenu par amazed.

• Le ratio entre analyticalDeltaz_Meth2/analyticalDeltaz_Meth1 varie entre 2.13 et 4.2, avec une moyenne de ratio = 2.5 (70% des donnéesprésente un ratio < 2.5).

• estimatedDeltaz varie principalement entre [10-3; 0.003] comme le montre la distribution des valeurs dans le plot suivant :
  Les plots suivants montrent la distribution des differences entre estimatedDeltaz et les analyticalDeltaz:
  Le premier plot correspond à la distribution cumulée et dont l'axe X est en log10. 50% de la population présente une différence aux alentours de 10^-3, ie., de meme ordre que estimatedDeltaz .
  

Comment by Vincent Le Brun on 2021-10-04 16:40:55:
du coup la il manque la comparaison entre les méthodes analytiques et l'estimation par Amazed ?

Comment by Mira Sarkis on 2021-10-08 08:19:25:

Vincent Le Brun wrote in #note-17:
> du coup la il manque la comparaison entre les méthodes analytiques et l'estimation par Amazed ?

Dans la #note-16, j'essayais de dire que la différence entre l'estimation et les méthodes analytiques * est de l'ordre de la valeur de deltaz estimé*. Mais il nous semble possible d'utiliser le calcul analytique comme un majorant pour deltaz estimé: on a une première conclusion encore à vérifier que deltazEstimé = R * computedDeltaz avec R = 10 pour eq et R = 4 pour eq.

Les plots suivants correspondent à des histogramme 2D de la variation des valeurs de deltaz estimé (yAxis) par amazed en fonction des valeurs calculées (xAxis) par les deux méthodes.

TODO:
Didier propose de refaire ce meme travail en utilisant les valeurs provenant de la firstpass (https://projets.lam.fr/issues/6683) plutot que ceux de la secondpass, sur les validations-tests pfs7 et Euclid noiseless, avec secondwdwsize large de = 5E-2

Comment by Vincent Le Brun on 2023-04-26 12:13:21:
following the discussion on Mattermost, and given that for Euclid the LSF can be as high as 150A, which gives a relative redshift interval of 1e-2, we should maybe include the LSF in the calculation of the width. The method is to be determined

Comment by Didier Vibert on 2023-05-25 15:16:46:
Finalement, il s'avère difficile de trouver un bon proxy du delta_z (et donc de la largeur minimale de la fenêtre 2nd passe) à partir des données first-pass ou dispersion de vitesse.

Du coup, après le merge de l'issue #7529, l'idée est d'aller plus loin que le warning et de reprendre le calcul de la pdf avec une fenêtre élargie. Je rebaisse le %réalisé pour correspondre à l'ajout de cette implémentation.

Comment by Didier Vibert on 2024-01-12 16:47:57:
should wait multiobs #6028