rationalize the considered redshift when computing physical parameters or fit IR

[olivierilbert]

Here is a description of the various parts in which we set the considered redshift.
A possible problem arise when we use the median of the PDF to compute physical parameters. Need to check if it is not a bug.
At the end, I put few ideas to rationalize this part.

---

In run_photoz in photoz_lib.cpp

// set the z in the grid closest to the true/spectro z in the catalogue
// this only makes sense for ZFIX=YES and if this true/spectro z is provided
// in the catalogue
oneObj->closest_red = gridz[indexz(oneObj->zs, gridz)];

Not sure why doing that all the time, specially when ZFIX=NO. I have the impression that it could be done only when zfix true.

---

In PhotoZ::run_photoz

When we fit the IR part, the consiz is already set to the value we want (spec-z, zp min chi2, or zp med PDF).
Then we set oneObj->closest_red to the redshift of the grid corresponding to consiz which is correct.

  // FIR FIT
  // Define the filters used for the FIR fit based on the FIR context
  oneObj->fltUsedIR(fir_cont, fir_scale, imagm, allFilters, fir_lmin);
  // Substract the stellar component to the FIR observed flux
  oneObj->substellar(substar, allFilters);
  oneObj->closest_red = gridz[indexz(oneObj->consiz, gridz)];
  // Fit the SED on FIR data, with the redshift fixed at zmin or zmed
  oneObj->fitIR(fullLibIR, fluxIR, imagm, fir_frsc, lcdm);

---

In onesource::fitIR, need the closest_red to select the item in the IR library at the same redshift than the general grid.
// Loop over all SEDs from the library
for (size_t i = 0; i < fulllibIR.size(); i++) {
if (fulllibIR[i]->red == closest_red) {

We could use something more robust with
abs(fulllibIR[i]->red - closest_red) < 1.e-10

---

In PhotoZ::run_photoz

// Fixed the redshift considered for abs mag, etc depending on the option
oneObj->considered_red(zfix, methz);
// If use the median of the PDF for the abs mag, etc, need to redo the fit
// Need to redo the fit to get the right scaling. It would change ZMIN, etc
if ((methz[0] == 'M' || methz[0] == 'm') && (!zfix)) {
  oneObj->chimin[0] = 1.e9;
  oneObj->closest_red = gridz[indexz(oneObj->zgmed[0], gridz)];
  oneObj->fit(fullLib, flux, valid, funz0, bp);
}

I think we are missing something here !!!!
We need to call valLib to set the valid vector. It was correct before the existence of validLib, but not anymore.
We are probably missing a line like:

if ((methz[0] == 'M' || methz[0] == 'm') && (!zfix)) {
  oneObj->chimin[0] = 1.e9;
  oneObj->closest_red = gridz[indexz(oneObj->zgmed[0], gridz)];
  valid = oneObj->validLib(zLib, true);
  oneObj->fit(fullLib, flux, valid, funz0, bp);
}

In order to do the fit only when the grid goes through closest_red.

---

---

GENERAL In order to rationalize:

---

1. oneObj->closest_red = gridz[indexz( XXXX , gridz)]; could probably be done inside validLib
2. we need to call validLib when we set the redshift to the median of the PDF (probably a bug, to be checked in detail)
3. implement the use of the vector valid in fitIR since we didn't propagate this improvement of fit() into fitIR()

[olivierilbert]

Bug has been resolved in the main. Still, it could be nice to rationalize this part as proposed.

[johannct]

Can closest_red remain the closest to us, and consiz be used for closest to anything you want.... I would like closest,_red to not change meaning in the middle of the code Le mer. 18 déc. 2024, 15:52, Olivier Ilbert ***@***.***> a écrit :

…

Bug has been resolved in the main. Still, it could be nice to rationalize this part as proposed. — Reply to this email directly, view it on GitHub <#258 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEPCYMYB3QIYMTVYOKEWNT2GGD2HAVCNFSM6AAAAABTYFFVI6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNJRGUYTSNRSGI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[johannct]

Now methz is a book, nit a string Le mer. 18 déc. 2024, 20:16, Johann cohen-tanugi < ***@***.***> a écrit :

…

Can closest_red remain the closest to us, and consiz be used for closest to anything you want.... I would like closest,_red to not change meaning in the middle of the code Le mer. 18 déc. 2024, 15:52, Olivier Ilbert ***@***.***> a écrit : > Bug has been resolved in the main. Still, it could be nice to rationalize > this part as proposed. > > — > Reply to this email directly, view it on GitHub > <#258 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAEPCYMYB3QIYMTVYOKEWNT2GGD2HAVCNFSM6AAAAABTYFFVI6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNJRGUYTSNRSGI> > . > You are receiving this because you are subscribed to this thread.Message > ID: ***@***.***> >

[olivierilbert]

The variable closest_red is the redshift in the zgrid which is the closest to one you're interested in (that you provide in input of the function).
consiz is the one you consider as the best redshift estimate (it could be spec-z in case of ZFIX YES, or the median of the PDF in case of methz=true).
I don't think it's changing meaning within the code.

[olivierilbert]

When trying to simplify this part, I ended up adding more complexity than what is currently in the code (It would need to pass the zgrid to the valiLib function, and create a zLibIR for the fulllibIR library). I think it's not worth it. So, I am in favor of closing directly this issue.