objdb broken after overwritting a target #782
Comments
|
here is what I get for the last target I entered (an alias of it is SVS 20 S) apero_astrometrics.py 'IRAS 18274+0112' |
|
and this is with Gl699 apero_astrometrics.py 'Gl699' |
|
Sorry with this issue I'm completely stuck with all I have to do with Apero. |
|
I remove the duplicate entry for SVS_20_S but I'm pretty sure I did this before you sent this message. This was fixed in v0.7.290 - I readded a duplicate and tested it. I can try and back date this change to v0.7.288-stable-test but this will be some work to remember what I had to do for this and what is not an update related to it and wont happen at least until Monday. Hopefully me removing the duplicates is enough for it to work for you. Note you could install v0.7.290 elsewhere and use apero_astrometrics there but we should avoid duplicates (which are allowed) until no one is using older versions (they used to work and broke somewhere between v0.7.279 and v0.7.288) |
|
I did a fresh install of the .290, but get an error with apero_astrometrics.py: ModuleNotFoundError: No module named 'gspread_pandas' see below. ''' 00:54:14.432- |VALID| *************************************************************************** apero_astrometrics.py 'Gl699' ''' |
|
Did you use the requirements_developers.txt file? Tools require the developer options |
|
Thanks, That was my guess and wanted to try that this morning; I used the current.txt |
|
There some progress but still an issue, apparently with the mysql syntax. |
|
The object IRAS 18274+0112 is in the objdb (pending list) as SVS_20_S (first column) but the error above says it is known as SVS_20 |
|
Also I see in the pending list that lines 64 65 66 67 are redundant with 83 84 85 86 respecively. |
|
Ah I see for some strange reason the original name was IRAS 18274+011 for SVS_20_S not sure why! |
|
for those four targets, should we add the alias TIC(space)(ID) ? |
|
Its actually not necessary as TIC_ID is the same thing. APERO automatically replaces:
I've added them any way, the more important one to add is with no space i.e. |
|
@njcuk9999 I'm trying this morning to reducedwith the 288 just one star for one PI from 24A. His star is already in the DB. But apero_processing.py fails right away. here is what I get in the terminal:
|
|
Is there a way to reset my mysql objdb without touching the other db ? |
|
with the 288 I can't add a new target anymore or process a target that is still already in the db |
Yes |
|
Ah I didn't remember that recipe. But with the 288 running apero_database.py --reset --dbkind='astrom' did delete the db and re-create it, but it fails with a lot of errors again, as above, with pandas stuff. I'll do a test with the 290. |
|
@njcuk9999 as I have a short PI progm from 24A for which the PI is eager to get the reduced data, I'm still trying to fix my 288 and get the data processed. before closing this issue, and switching to 290, I made the following, trying to force the gspread* as we do for the 290: For the pip install, it seems to work: unfortunatly the apero_database reset and rebuilt of the objdb fails. I get the same long error in the terminal as before with pandas complaining. |
|
could you try the following: Maybe that will work (as a hack, this is not recommended in general) |
|
@njcuk9999 here what we did with @cusher in /apero/apero-drs Chris ran and to switch back he did |
|
Okay sorry I forgot there were some changes in v0.7.289 that mean you can't do this. I think the best option would be to create a new v0.7.288 profile and then in MySQL copy the astrometric database from one to the other The process I imagine would be like this (though might be worth checking with @cusher):
This all assumes you can create a table in v0.7.288 in a new profile - if you can't it means we still have a duplicate problem in the online table and should fix this |
|
Creating a new profile w/ v0.7.288 also failed: |
|
@njcuk9999 there is another duplicate issue in the objdb, spotted by Chris in the pending list line 53 should be removed, same as 80 (LSPM_J2049...) |
|
okay that is probably the problem, maybe your original v0.7.288 will work now when you reset it. Note in future there is no problem between a duplicate entry in pending vs main - this should be the proper way to "amend" an old object that needs updating - its just a few of the v0.7.28X versions seem to not like duplicates. |
|
Okay since there seems to be no way round this I've tried to isolate the code in v0.7.290 that fixes this. Try a you'll have to reset the object database with:
Let me know if it works |
Hi Neill
Yesterday I entered a target and wanted to update it with a new alias this morning. I used the --overwrite
but now the db is broken.
apero_astrometrics.py 'Gl699' fails for example. panda errors.
The text was updated successfully, but these errors were encountered: