Periodic object ingestion and phase calculation

[amdugas]

• Find lost script that adds them to the DB 🤦‍♀️
• Generate best by airmass needed object-phase for a given jd
  I'm not sure how the function will be used?

[amdugas]

the part I was confused about was how to actually implement the formula into the scheduler, and I finally took another look at it and it turns out astroplan does not just that but everything else it needed '\_0_/'

[nblago]

The script will need to provide a list of all the objects in the JD where the phase of the lightcurve is the phase the object is supposed to be observed plus / minus the error allowed by the user.

[nblago]

1. Modify the add_new_request function, so that if the object is periodic, it will create N different requests, with N being the number of samples in the phase space of this object.
2. The phase will be stored in the word "phase" in the request table. The "sampletolerance" shall store the sample tolerance. Now that I think about it, the value of "phasesamples" shall still be in the request, as that is not part of the periodic object.
3. The astroplanner will consider as a request all the objects where the phase is between [phase - sampletolerance, phase + sampletolerance].

And as Alison mentioned, we could drop the phi or the mjd0. One of the two. They are related. However, it is important to test that when converting from one to another, we are consistent. The JD has an offset of 24,000,000.5 days regarding the MJD, when in Sesar 2017 it says 24,000,000.0

[amdugas]

I'm not really sure what "modify the add_new_request function" means - the closest thing to this I've been able to find, even after considerable effort, is "add_request_to_db" in growth/growth_watcher.py. In the growth stuff seems like a pretty strange place to be doing this. Is there a different function somewhere else you were thinking of?

I also took a look at why I hadn't seen 'phase' in the database before - it turns out both 'phase' and 'mjd0' are columns of 'request' in sedmdb but not sedmdbtest. This would be fine, except mjd0 is already in the 'periodic' table for both databases, and it doesn't really seem appropriate to have this object-related information tied to individual requests. Do we know when this was added, and why? If it'd be okay with everyone, I'd like to delete it.

[nblago]

The change will need to be done at the DB level.
The function:
def add_request(self, pardic):

needs to be modified, so that if it is a periodic request, you can redirect the code into another new function, for example called:
def add_periodic_request(self, pardic):

which will split the phase into as many samples as necessary (N), and call N times the function above, giving a specific phase for each request.

mjd0 can be deleted to give place to the phase variable. As long as both agree and there is a way to reconstruct one from the other and the other way round.