search

ska-sa / astrokat

General observation framework for the MeerKAT telescope
BSD 2-Clause "Simplified" License
2 stars 4 forks source link

Slew instead of 0-second track for first target to help FBFUSE #92

Closed rubyvanrooyen closed 4 years ago

rubyvanrooyen commented 4 years ago

FBFUSE / MeerTIME observations had some issues with the astrokat observation script when FBFUSE ran commensally in the array with a MeerTIME pulsar observation.

Errors and ideas were discussed during a site integration session and it was noticed that astrokat on the "slew to first target" -- lacks the fbf.check_provisioning_beams_complete as implemented in sessions.capture_start. This allows the FBF setup of the beams

For astrokat the optimal implementation of this missing requirement was to add an explicit slew function to replace the current 0 sec duration track that mimicked the slew. During this slew to first target (which is expected to be the longest slew in general) the FBF beam check is initiated once the antennas are instructed to POINT to target, this should utilise the slew dead time for FBF config

ajoubertza commented 4 years ago

@lanceWilliams You know a lot about the FBF implementation in session, so can you have a look at this, please?

rubyvanrooyen commented 4 years ago

Maciej and I verified functionality on site using a little TRAPUM integration time http://10.97.1.13:8081/tailtask/20200611-0015/progress

Observations ran successfully

rubyvanrooyen commented 4 years ago

@mmphego I see this branch of mine has similar unit test issues than you mentioned in the Jira. The master branch tests succeeds, but this branch does not. I cannot see a difference since I cannot see a difference in the tests with master branch.

Can you please help me to figure out what I should do to correct the unit tests :(

mserylak commented 4 years ago

Just a gentle poke here to the CAM people :) Is there anything I could do to speed up the merge?

ajoubertza commented 4 years ago

Hi @mserylak.

Do you want to fix the noise diode tests that are now failing due to changes in this PR?

ajoubertza commented 4 years ago

The noise diode tests are brittle, checking for exact absolute time values in the tasklog output. It looks like some of those values are now different due to a slight variation in timing cause by the initial slew.

ajoubertza commented 4 years ago

This update should get deployed on site next week with the v27 CAM release.