ZeroPoint.py errors, Points fixes, and sundry

[SeanPoints]

I've created matched catalogs of DeMCELS sources and Gaia stars using PhotCompare.py

PhotCompare.py -gcat /Users/sean.points/bin/kred/xdata/Gaia_MagClouds.fits SMC_c06/SMC_c06_T01.N662.fits

This results in a catalog being written to ./TabPhot/SMC_c06_T01.N662_phot_x_Gaia_MagClouds.txt

The next step of the process to get the DN to flux conversion is to run ZeroPoint.py

ZeroPoint.py TabPhot/SMC_c06_T01.N662_phot_x_Gaia_MagClouds.txt

This produces an error:

ImportError: cannot import name 'get_gaia_spec' from 'PhotCompare' (/Users/sean.points/bin/kred/py_progs/PhotCompare.py

because get_gaia_spec is no longer in PhotCompare, it is in GaiaCat.py

Change
from PhotCompare import get_gaia_spec
to
from GaiaCat import get_gaia_spec
and rerun ZeroPoint.py

ZeroPoint.py TabPhot/SMC_c06_T01.N662_phot_x_Gaia_MagClouds.txt
produces the error:

---

TabPhot/SMC_c06_T01.N662_phot_x_Gaia_MagClouds.txt
There are only 89 objects when wanted 1000
Star is in cache
Traceback (most recent call last):
File "/Users/sean.points/bin/kred/py_progs/ZeroPoint.py", line 278, in
steer(sys.argv)
File "/Users/sean.points/bin/kred/py_progs/ZeroPoint.py", line 233, in steer
final=do_one(one)
^^^^^^^^^^^
File "/Users/sean.points/bin/kred/py_progs/ZeroPoint.py", line 194, in do_one
final=get_gaia_flux(xtab=ztab,key='Ha',wave=6563)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Users/sean.points/bin/kred/py_progs/ZeroPoint.py", line 151, in get_gaia_flux
f_ha=get_flux(spec_tab,6563)
^^^^^^^^^^^^^^^^^^^^^^^
File "/Users/sean.points/bin/kred/py_progs/ZeroPoint.py", line 72, in get_flux
while xtab['WAVE'][i] < wavelength and i<len(xtab):
~~~~^^^^^^^^
TypeError: tuple indices must be integers or slices, not str

The problem is in the get_flux routine xtab is a tuple and not numpy array (or astropy table) of wavelengths and fluxes. My fix for this
is in the dev_points branch ZeroPoint.py where I've changed:

---

Original get_flux

def get_flux(xtab , wavelength=6563):
'''
Get the flux of a star at a particular wavelength

'''

i=0
while xtab['WAVE'][i] < wavelength and i<len(xtab):
    i+=1
#print(xtab['WAVE'][i])
frac=(wavelength-xtab['WAVE'][i-1])/(xtab['WAVE'][i]-xtab['WAVE'][i-1])
# print(frac)
flux=(1-frac) * xtab['FLUX'][i-1]+frac*xtab['FLUX'][i]
# print(flux)

return flux

---

Points get_flux

def get_flux(xtab, wavelength=6563):
'''
Get the flux of a star at a particular wavelength
'''
#print("In get_flux")
#print("Xtab Type:", type(xtab))

wave, flux = xtab   # <-- unpack tuple

n = len(wave)
#print("Length:", n)

i = 0
while i < n and wave[i] < wavelength:
    i += 1

# guard against edges
if i == 0 or i == n:
    raise ValueError("Wavelength out of bounds")

frac = (wavelength - wave[i-1]) / (wave[i] - wave[i-1])
f = (1 - frac) * flux[i-1] + frac * flux[i]

return f

---

My modified routine is returning DN to flux conversions, but the conversions are slightly off compared to the conversions determined in 2024. In 2024, 1DN ~ 2.4e-18 erg/cm^2/s and after running the modified code I get 1DN ~ 1.7e-18 erg/cm^2/s

I need a second pair of eyes to look through the code to see if what is going on because this represents a 30% decrease.

Some of the data from 2024 are on Box at:
MagClouds (Shared External)/Cleanup_20260119/xphot

[kslong]

So Sean. I verify that the error is seen, and I am not surprised at your solution, since I did reorganize some of the code including moving things around. My first reaction would be for you to merge the code you have created into dev.

However, when I ran your version of ZeroCalc, I got errors at the end, so I need to check why. I'm not entirely sure we got fluxes back at.

My "bet" about the calibration in the end, will be that there are differences in the PhotCompare output. It looks like the filenames have changed but the xphot directory you mention does seem to have the data one of used to make the measurements. But the exposure you mention above is not in xphot as far as I can tell. One of us needs to run PhotCompare on one of the files mentioned there to check that this is not where the problem is.

Note that in the end if we are working on the same file, we ought to be able to take kred back to the same state it was when we did those calculations and run them, assuming astropy etc. have not changed in the mean time.

[SeanPoints]

I don't think that the version of PhotCompare.py matters. If I'm reading the code properly, the matching table has to have 'Source_name', 'R', 'teff', and 'Net'. The older and newer versions of PhotCampare.py produce those in the output table. The filename of the matching table should not matter because the table name is read from the command line.

[SeanPoints]

This commit was from 10 June 2024 and contains the older versions of ZeroPoint.py that was working before.

c3165e3

[kslong]

Are you sure PhotComapre then, used the same radii for the extraction regions. My prime hypothis that we may have used different extration regions.