Mismatch between the number of valid orders found by PypeIt and the number expected for magellan_fire spectrograph

[dsanmartim]

Dear developers/community,

I'm trying to reduce data taken with FIRE (Echelle mode) at Magellan Telescope and the following issue is arising:

[ERROR] :: extract.py 1899 ech_objfind() - There is a mismatch between the number of valid orders found by PypeIt and the number expected for this spectrograph. Unable to continue. Please submit an issue on Github: https://github.com/pypeit/PypeIt/issues .

I've tried for two different datasets and the same issue appears. Here are the pypeit config files for both data sets:

==> DATASET 1

==> DATASET 2

Any guess on how to fix it? I would also appreciate it if you can take a look in the config files, in case I'm doing anything wrong that may be related to the issue reported here.

With best wishes, David Sanmartim.

[jhennawi]

Hi David,

My guess is that problem here is insufficient counts in your flats, which is causing the automated order identification and tracing algorithm to fail. As you can see from the development suite we example at:

https://github.com/pypeit/PypeIt-development-suite/blob/master/pypeit_files/magellan_fire_fire_echelle.pypeit

We are combining 40s flats to get build the MasterTrace image which is then used to trace the edges. I see that you are combining sky flats and lamp flats in your PypeIt file, but I don't know your slit width or whether these images have sufficient counts.

In your other pypeit file example the exposure times are a lot shorter than the 40s in our example.

A few pieces of advice:

The script pypeit_chk_edges can be used to check the orders that pypeit identified. You can also view the master trace image it created and see if there are sufficient counts as well as the Sobel filtered image.

You may need to modify the edge_thresh parameter away from the default to get better results. You can see what the defaults are on the pypeit readthedocs for FIRE.

[calibrations] [[slitedges]] edge_thresh = XX

If you want to execute only edge tracing there is a useful script.

pypeit_trace_edges -f pypeit_file

This will only trace the edges. You can turn on --debug and --show to get a better feeling for what is going on.

In the worst case scenario, if you are flats are not doing the trick you can use archival trace flats provided that the orders didn't move much, which you can easily check by blinking the flats with your science.

Good luck! Joe

[dsanmartim]

Hi Joe,

Hi Joe,

Thanks a lot for your suggestions. I’ve checked the counts and although they should be enough (if summing sky flats + quartz), your suggestion is very helpful for future reference and also to collect some extra calibrations from archive to improve the outputs. I was discussing with other people there were observing with FIRE and some of the commented they used to take the science with exposure times way longer than mine. In order to avoid sky variation, I’m used to keep exposure times lower than 2min and the other people were taking 600s (as in the dev example). Inspecting my science frames, I see there is almost no sky lines in the bluest orders, while science frames with 600s are full of them. I think this might be the problem.

Actually, by inspecting the Trace Image and the Sobel Filtered images, it seems that all but the very bluest order were identified:

I’ve tried the following and it seems that this is the main reason for the failing is because the first orders have no sky line whatsoever.

(pypeit) $ pypeit_chk_wavecalib MasterWaveCalib_A_1_01.fits

[INFO] :: Loading WaveCalib from MasterWaveCalib_A_1_01.fits N. SpatID minWave Wave_cen maxWave dWave Nlin RMS

---

0 168 0.0 0.0 0.0 0.000 0 0.000 1 288 0.0 0.0 0.0 0.000 0 0.000 2 401 0.0 0.0 0.0 0.000 0 0.000 3 507 0.0 0.0 0.0 0.000 0 0.000 4 607 8938.0 9732.1 9921.0 0.520 7 2.119 5 702 9600.1 10107.1 11104.0 0.500 6 0.625 6 791 9952.8 10517.9 11244.3 0.532 7 0.122 ... ... ... ... ... ... ... ... 13 1332 13878.9 14653.5 15344.0 0.722 19 0.102 14 1403 14703.8 15522.5 16253.7 0.765 18 0.058 15 1476 15631.2 16500.5 17277.4 0.812 25 0.065 16 1552 16682.5 17609.4 18438.9 0.866 26 0.080 17 1632 17879.5 18877.0 19763.7 0.926 19 0.554 18 1719 19273.5 20342.2 21299.2 0.998 21 0.057 19 1816 20894.5 22052.6 22895.3 1.081 14 0.061 20 1930 22805.1 24077.0 25200.1 1.179 22 0.175

And here is the MasterArc image:

I'll take some sky images from archive and put them inside my RED folder, to see if the new MasterArc files will have the sky lines in the bluest orders. I'll let it you know how does this is going. The good thing is that as I work at LCO, it is easy to get calibrations from archive (or even to get new ones, if necessary).

What do you thing about this? May it be the problem? And what about my strategy to overcome this issue?

Out of topic question: Is there a plan to implement some solution based on ThAr lamps?

Thanks again. David.

[jhennawi]

Hi @dsanmartim,

I'm not sure I understand your problem. Are all of the order being identified by the order tracing, and then is there a failure in wavelength calibration because of a lack of lines, or is rather the problem that you don't get all the orders identified by the order tracing. The order tracing works on the trace flats. My suggestion is that you consult the data in the PypeIt development suite and verify that your can reduce it. This should give you intuition about what orders you should be recovering and what flats to use for the tracing. You can also join the PypeIt Users Slack and post your questions in the FIRE channel there.

[kbwestfall]

Assuming this issue is now resolved. Please re-open if not.