You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'd like to provide a 'fo'-based service for asteroid hunters that allows them to run their own observations against many observations of existing objects simultaneously, to see if the residuals are close enough that they could match up and be the same object.
For this I expect many runs of 'fo' simultaneously, which could be problematic because the JSON output files could be overwritten if the requests are not spaced far enough apart in time. Right now I'd have the options to
(1) Create a request queue that ensures that requests run sequentially, modifying environ.def before each fo execution - this would probably be too slow with the number of objects considered
(2) When a new request comes in, indicate (for example with a new, empty file or an extra information line in environ.def or some kind of lock) that environ.def has been modified and is waiting to be read, then programmatically change the following lines
to point to a unique output directory for this request, then start fo and wait the minimum time until it has read that configuration file and delete the indicator file. All processes wanting to make a request would check for the existence of the file/hint/lock and have to wait until it is removed.
These workarounds could be avoided if fo included a command line flag that allowed one to specify the output directory (and/or paths including filename) for these JSON files, overriding the settings in environ.dat(/.def)
Edit: I suppose another option/possible feature would be to add a flag that allowed one to specify an environ.def path, then a custom environ.def could be created for every request
Edit3: It seems that using this approach, I can specify the JSON file output paths, but not the elements.txt one (there doesn't seem to be a flag for its path either)? I need the elements.txt because it includes the state vector data, which I need to generate a custom orbitsimulator.com link (and therefore I don't have the option to read from elements.json, because that file doesn't include them)
The text was updated successfully, but these errors were encountered:
Y'know, I thought I'd added the ability to specify where the elements.txt file should go. But I didn't. I could see this being a Generally Useful Thing.
I can't actually implement it right now, as I'm away from my development machine. Should be able to work on it come Sunday or Monday next week. It should be relatively simple.
Most likely, what I'd do would be to provide, in `environ.dat', an option such as
OUTPUT_DIRECTORY=~/find_orb_output
Specify such a directory, and files such as elements.txt, covar.txt, 'observe.xml', etc. -- basically, anything Find_Orb generates for this particular run -- would be placed in that directory, instead of in ~/.find_orb.
It also may make sense to have the state vector data in elements.json. If I did so, the above would be irrelevant for you... still would be useful for others, though.
I'd like to provide a 'fo'-based service for asteroid hunters that allows them to run their own observations against many observations of existing objects simultaneously, to see if the residuals are close enough that they could match up and be the same object.
For this I expect many runs of 'fo' simultaneously, which could be problematic because the JSON output files could be overwritten if the requests are not spaced far enough apart in time. Right now I'd have the options to
(1) Create a request queue that ensures that requests run sequentially, modifying environ.def before each
fo
execution - this would probably be too slow with the number of objects considered(2) When a new request comes in, indicate (for example with a new, empty file or an extra information line in environ.def or some kind of lock) that environ.def has been modified and is waiting to be read, then programmatically change the following lines
to point to a unique output directory for this request, then start fo and wait the minimum time until it has read that configuration file and delete the indicator file. All processes wanting to make a request would check for the existence of the file/hint/lock and have to wait until it is removed.
These workarounds could be avoided if
fo
included a command line flag that allowed one to specify the output directory (and/or paths including filename) for these JSON files, overriding the settings in environ.dat(/.def)Edit: I suppose another option/possible feature would be to add a flag that allowed one to specify an environ.def path, then a custom environ.def could be created for every request
Edit2: Oooh, I see that is possible with https://www.projectpluto.com/fo_usage.htm#option_D - great!
Edit3: It seems that using this approach, I can specify the JSON file output paths, but not the elements.txt one (there doesn't seem to be a flag for its path either)? I need the elements.txt because it includes the state vector data, which I need to generate a custom orbitsimulator.com link (and therefore I don't have the option to read from elements.json, because that file doesn't include them)
The text was updated successfully, but these errors were encountered: