LBL 0.64.0 slow on offset Fps

[clairem789]

I noticed LBL was running extremely slowly on the drift file: this is because it does 20 iterations per file while 4 were enough before. I checked that the file quality is the same (since also APERO version has changed) and found no difference. And actually the new lblrv file seems cleaner than it used to be (see below). So the only explanation I could think of at this time is that there may be a new limit put somewhere on how far from the reference the FP RV could be, while this may not have been checked in the previous version. For Spirou we had early times with changes in the FP temperature set point, so the 2018 data are far from the reference. If that's the reason this makes LBL much slower.
Any clue this could be the case?
thanks

FILE VERSION LBL_VERS ITE_RV RMSRATIO SYSTVELO WFPLINE
2329749o_pp_e2dsff_C_FP_FP_lbl_LAM.fits 0.7.288 0.63.007 4 1.1424532979930495 -889.7869184040007 19719.0
2329749o_pp_e2dsff_C_FP_FP_lbl_NW.fits 0.7.290 0.64.0 20 0.7460647948902017 -813.4597185158915 19798.0

RV and flux in LBL peaks for the same file with the 2 reductions:

[clairem789]

Actually, I also noticed that some of these early files were not at LAM while they were not rejected by my implementation of APERO. That makes me wonder whether the reject list was properly applied to the processing (sorry this is more APERO-related). There could be implications to LBL (and other time dependent correction like telluric) if some bad files were included. how can I be sure that the reject_list is applied?

[njcuk9999]

I'm really not sure we haven't run it on a large set of data here in Montreal - I can't think of any recent changes in LBL that could cause this but I'd have to ask @eartigau.

As for the reject list there is no easy way, you can check the list of odometers here against what is preprocessed (tmp) directory, no of these files should be there!

https://docs.google.com/spreadsheets/d/1gvMp1nHmEcKCUpxsTxkx-5m115mLuQIGHhxJCyVoZCM/edit?gid=1398289367#gid=1398289367

[clairem789]

OK thanks. Reject_list is fine: I mean, I can confirm the file I have at NW which isn't at LAM is not in the reject-list.

So I'm back with the first issue which is that a good file takes 20 iterations to be calculated, a 5x slow down at least. Let me know if Etienne has a clue. Thanks

[njcuk9999]

Okay if there are files you think should be in the reject list you can use: apero_reject.py (use the --help for options) to add them to the list!

I'll ask @eartigau Monday though it may be a while before he can look at this.

[clairem789]

In addition, all lines in my drift.rdb files have nan values as RVs.
Maybe I'll have to re-extract everything

[njcuk9999]

re the 5xslow down: Today we found a possible bug in LBL related to ESPRESSO, it actually managed to speed up convergence a bit - it is probably unrelated but might be worth running 0.65.001 when I push it (in the next day).

As for all lines having nan values that normally means something went wrong in matching the FP files for fibers (they match on wave file) - could it be that one set of files has the XXXXXa_pp_etc and some set have YYYYY_pp_etc (change from v0.7.288 and v0.7.290). I know we use a header key to get the wave solution so might be worth checking and checking those wave solutions in the calib directory - its a long shot but it does some like something isn't talking to something else