MCAO PSF files lack either WAVE0 or WAVELENG header
Opened this issue · 13 comments
The two provided MCAO psf files (via https://www.univie.ac.at/simcado/) do not work.
When using ao_mode='filename' in simcado.run(), where filename points to the MAORY PSF file, the following error occurs:
File "<somelocalpath>\simcado\psf.py", line 1176, in __init__
to add WAVELENG to the FITS header""")
ValueError: Could not determine wavelength of PSF in
extension 0. FITS file
needs either WAVE0 or WAVELENG header
keywords.
Use simcado.utils.add_keyword()
to add WAVELENG to the FITS header
Or is this something the user has to do with the proposed command?
Hi Luc,
The MAORY PSFs were just uploaded (AFAIK) so we haven't tested them yet. You can try to add the missing keyword using the following command
simcado.utils.add_keyword(FILENAME, "WAVELENG", wavelength , comment="", ext=0)
wavelength is of course the wavelength of interest in um, e.g. 2.2
please also check the extension you are reading.
Also, the MCAO PSF that you got using get_extras() had also some header issues. A new corrected version can be retrieved too.
Hope it helps
Hi miguel,
I see. So what I did was add the keyword, and the error was resolved. However another error appeared.
The same happened for PSF_MCAO.fits, which I updated using get_extras() (it said I already had the latest version). Also there I had to add the keyword WAVELENG, both for ext=0 and 1, after which the following error came up:
KeyError: 'Could not get pixel scale from <path>\\simcado\\data\\PSF_MCAO.fits'
I'm not sure what you mean with the extension that I'm reading; do you mean the .fits?
Hi again
1.- It may be you get that error because the pixel scale is not in the headers, again you can use
simcado.utils.add_keyword(FILENAME, "PIXELSCL", 0.004 , comment="", ext=0)
If the error persists you can try to add CDELT1 and CDELT2 also with the proper value
2.- Could you please delete PSF_MCAO.fits and download it again with get_extras()? It might be that the versioning wasn't done properly (something to think about actually)
3.- Yes, I mean the fits extensions (if there are more than one) where you are adding the keywords. Some PSF files have more than one, but SimCADO should be able to read them. We should check that too.
Thanks,
-
After PIXELSCL and CDELT1, the code is looking for NAXIS1. It seems, however, that using
sim.utils.add_keyword('MAORY_MCAO_CONSTPSF_4mas_20181203.fits', "NAXIS1", 512, comment="", ext=0)does not add that keyword to extension 0. This keyword is already present in the other extensions (1-4), might that have anything to do with it? I cannot get this one to work. -
Deleting PSF_MCAO.fits proved to be helpful indeed, it did the trick! That one works a charm now.
-
speculating from point one here: maybe simcado cannot find keywords in higher fits extensions?
OK. I downloaded the MAORY PSF you mention above and compared with PSF_SCAO.fits, because the later also has four extensions.
I think the problem is the extension 0 in the MAORY PSF. SimCADO is expecting data in each extension and there is none. So, the solution would be to delete extension 0 and leave the other four. I'll try to do it later.
The standard for multi-extension FITS files is to have a primary unit without data, only header information (NAXIS1 does not make sense in that case). This is the format of MAORY_MCAO_CONSTPSF_4mas_20181203.fits and it should stay that way. I'm somewhat surprised that simcado looks for data in a MEF primary, it shouldn't do that.
Hi everyone,
Two things - the new PSF files e.g. MAORY_MCAO_CONSTPSF_4mas_20181203.fits are not formatted to work with SimCADO v0.5. These were made for the new v1.0 and should not be accessible by get_extras(). Indeed the bug occurs because SimCADO v0.5 expects to find a PSF in Ext-0. This is because I didn't bother to look up ESO standards when I was originally programming it.
Also, the new MAORY PSFs should not be publically available, because MAORY has not officially released them to the public. They should only be available to the MICADO consortium, and MAORY has a very strict publication policy that I don't want to mess with. Hence we should remove these from being available via get extras before anyone else downloads them. (They should only have been on the _PSF folder.)
On that note, I think it's fine for Luc to use them, given that his supervisor is on the MICADO science team, and Luc will be participating in the science team meeting in Leiden.
Hi Kieran,
Just to clarify. The MAORY PSFs are only available through the webpage, not from get_extras()
Ok good =) The new F_MAORY_PSFs.html page shouldn't be public though, no? I deliberately didn't include it in the index.rst file because I though this would keep it out of the table of contents. If this isn't the case, I'll remove it from the repository after the consortium meeting. (At the end of the day, it's there at the moment mainly so that Ric is happy ;) I promised a page about PSFs back in November)
No, it isn't public. But the PSFs are available through the simcado webpage, see here https://www.univie.ac.at/simcado/
These are the PSFs we are talking about
Oh :/ I completely forgot about those. My bad. I'll take them done. Oops. Thanks.
Ok, so just for my understanding: if PSF_SCAO.fits and the MAORY PSF files are something different, then what exactly is the PSF_SCAO.fits one that I got from get_extras()?
PSF_SCAO.fits is the old (Oct 2017) simulated PSFs from the french team at LESIA
I honestly can't remember where PSF_MCAO.fits comes from.
PSF_LTAO.fits is super old and comes from the ESO design reference mission (2012)
PSF_POPPY was generated by me using the diffraction limited core from the poppy python package (from JWST) with a gaussian seeing halo slapped on top.