pndaly / artn-orp Goto Github PK

We noticed several times that the scheduler put an observation into the queue more than once, or sometimes will not put it into the queue at all. This seems random and relatively rare.

I know @swyatt7 and I noticed this with the focus sequence as well.

Here is a time stamp from Mike Jones: 2022-04-05T07:28:02.402 and 2022-04-05T07:29:59.776

There have been several instances where a queued observation gets done twice by RTS2, or does not get received by RTS2. Mike Jones notes a specific instance at: 2022-04-05T07:28:02.402 and 2022-04-05T07:29:59.776.

I am not totally sure if the issue is on the RTS2 or ORP/queue end of things. Creating issue here.

from @swyatt7:

I have also started the work for adding a web-api for ORP which will have full functionality of

• GET/POST observation requests
• GET/POST observation exposures (for updating requested exposure, like changing filter/exp_time… etc)
• UPDATE observation_requests status
• I am designing this for the sole purpose of RTS2 (or reduction routine like Banzai) to seamlessly update the exposure_status of an observation request (like inProgress/Completed) which can be queryable in the obsreq GET above.
• also once this is submitted, there is the potential for ORP to immediate grab the data from bigartn, and have it be accessible to the users as well.
• GET obsreq_data
• if the data is on ORP, the user can request their data from here

Right now, it appears that you can queue observations in a filter that is not currently in the filter wheel. In that case, RTS2 appears to take an image in the filter currently in the beam, so one gets data they did not request.

I think there should be some validation step that does not allow queuing of observations of a filter not in the wheel.

In the current nightly log it looks like there are two entries for every image. One of them is ‘not stitched’ and the other is ‘stitched’, though. so they are different.
I’m wondering if we should only display the ‘stitched’ images in the log. Or have an option to only display the stitched images (even better).

A good start would be to add in airmass constraints. Currently the default is hard-coded to be an airmass of 2.5.

Mike Jones was unable to create a new account on AORP. @pndaly should work with Mike Jones on this if possible unless he already understands what the issue is.

Many users will want to perform small dithers in between exposures to help with bad pixel rejection. Lets implement this functionality in AORP, and then also in our commands to RTS2. I am not sure at all how to do the RTS2 part.

This issue will track progress both for implementing dither requests in AORP, and for executing them in the queue.

When we requested a 'Clear' observation on AORP, RTS2 did not go to the 'Open' filter for the exposure. Can we check the filter mapping on AORP?

The search feature also does not seem to find objects when the name string contains '+', as in “BD+33d2642-d4”.

Not sure whether @pndaly or @swyatt7 knows this piece of the code best.

Scheduler airmass plot reads 'EDT'....which is Eastern time? Is that what we want?

@swyatt7 could look at this.

we use to have this capability, I think, but apparently it does not work anymore.
We should be able to upload a file list of targets, with filters, exposure times, etc to AORP.