-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
issue with apero_reject in 0.7.291 #797
Comments
This is the same error as you've had before, its with
You should note down this error as you seem to get it a lot! Can you please:
They are both defined in the requirements file now so they should be exactly the same as that:
If they are not it means you:
Otherwise I've no idea whats going on. As far as I can tell now that we have both these requirements this isn't an apero issue. The reject script (for SPIROU) uses the i.e.
This actually means that most of the bad list is incorrect for SPIRou and I never realised... |
I had seen it was again with gspread but thought it has been corrected with the 291 upgrade of the tools. a 'pip freeze' on my installation says so I need to downgrade gspread. I have another installation I'm using for tests running gspread==5.12.4 |
regarding the issue with FILENAME in the reject list, at least all odometers with 'OBJECT' string in the comment G column are o.fits files. |
worth noting that the amount of bad calibration is not so large I believe. |
ok @njcuk9999 |
Do we have any idea why Re: the reject list - I'll have a think about what I can do maybe there is a way to use it as a prefix instead of an exact match but it will be a lot slower! |
gspread was the wrong version on my quicklook and offline version, because they were both installed from the .290 stable test in sep or oct. I had the gspread corrected on a third setup which I'm using for tests and other things (like astrometrics and reject); I thought when upgrading quicklook and offline to new .291 source last week with updated tools it would had solved the issue with gspread (it did at least when I verified Gl699 was correctly identified as an existng obj with apero_astrometrics) but actually Chris and I only realised yesterday that the py packages had to be updated too. Chris just downgraded gspread. |
For the reject list, I guess you would have to query the db for each odometer to get the DPRTYPE and thus build the corresponding filename ? |
apero_reject.py --identifier=3094104,3094105 --test=True --autofill="1,1,1,24BQ13-Nov14_bad_pm_calib"
gives an error
By the way, @neil, the example you gave me earlier this year was using identifier like
identifier=3094104d , so with a letter after the odometer, and this is the way I entered the last bad odomters for SPIRou.
Is this correct ?
Please let me know
I hope the apero_reject tool will work again soon.
apero_astrometrics.py seems to work.
Thanks
Luc
The text was updated successfully, but these errors were encountered: