progress discussion

[rubyvanrooyen]

• In configuration file, do we have the LST range as hour integers only?
• Currently we have gaincal and bpcal -- what to do with the other calibrators, fluxcal and polcal
• Do we keep the delaycal tag?
• Should you visit the bandpass calibrator first if cadence is specified?

[mserylak]

• Float value seems better.
• Not sure (will need to think about it).
• Do not know.
• Yes, bpcal first, target after (or alternatively bpcal immediately after target).

[spassmoor]

I think there is some confusion over the use of tags in the target. First the observation configuration file should define how the targets are observed. But the tags are part of the target string that is passed through CAM and to the Datafile and the SDP backend. And are interpreted as the INTENT of the target, like if it is a calibrator and solutions need to be calculated with it.

[rubyvanrooyen]

Thanks for the feedback, I think I got most things added now: You can give it a run and see what it does Currently limit to the simulation side, will go to work on devcomm next week to get the dry-run system and sensor values in

You need a system that has katpoint and ephem installed If you clone the repository cd astrokat/scripts

Some example python observe.py --profile ../config/targets.yaml
python observe.py --profile ../config/image_sim.yaml
python observe.py --profile ../config/image.yaml
python observe.py --profile ../config/OH_periodic_masers.yaml

[rubyvanrooyen]

Additions after progress discussion

• Better description of usage and implementation

Added a custom sidebar to the wiki https://github.com/rubyvanrooyen/astrokat/wiki Will figure out what to do on the home page later, but for now hopefully the pages as listed in the selection sidebar forms some from of description and explanation.

• Adding type key for drift scans during catalogue conversion
• Updated the instrument subkeys -- they are now similar to the CAM sensors, which makes addition of more keys easier, also since PTUSE is a special case, it will make the addition of this USE system easier NOTE: this is the only USE system that will be added because currently this is the only beamformer pipeline that exist. Other USE software will be ignored, better design and implementation is required.

Please look at the catalogue2config.py input parameters and lemme know any suggestions python catalogue2config.py -h Still need to chat about the fact that fluxcal and polcal is not represented yet

More discussion needed

• target_list and calibration_standard unify? I really do not want to do this. If you use only the cadence tag to separate them then you require processing upfront to generate 2 lists behind the scenes. I do not always want to process all targets in the list, since this is wasteful if you have a long list of targets, but only a few calibrators with cadences. Explicit representation in the configuration file makes implementation clear and simplify scripts.

[mserylak]

On the last item. I say you move the responsibility to the user (i.e. implementation in the configuration file). Two benefits:

• you give user more control at a price of (small, but non-negligible) risk of things going awry,
• less work for you,

[mserylak]

About the pol-/flux-cal, especially in the beamformer (bf) case: currently we have only adopted single dish approach to pol/flux calibration. For fluxcal:

• slew the telescope to on-source (flux calibrator) and record it with noise diode firing,
• slew the telescope to an offset position of +/-X deg. in declination (that is to be decided) of flux calibrator and record it with noise diode firing (so 2 obs in total),

The flux calibration observations should happen at least once per observing session, in general the observations of flux cal targets are done at least once per week if not more often. For polcal:

• slew the telescope to an offset position of X deg. in declination (that is to be decided) of target of interest (pulsar) and record it with noise diode firing,
• this is done before or immediately after target of interest of observation,

This strategy has been working fine: my rev. 1 report on SD calibration will demonstrate it, hopefully will be released before the "BRP-odyssey" ;-). Given improved calibration pipeline (removing cross-hand leakages, as per BenH/Ludwig latest feedback) we will AFAIK apply the same approach for large subarray for now.

So the catalogue2config.py should have (for bf case):

• offset in deg from target for both flux and pol cal,
• a strategy of pointing,

OK, the above is not very descriptive (and there are other issues lurking around the bushes which I think, we should winkle out). Shall we make a brief meeting about that? Tomorrow, before lunch looks fine for me...

[rubyvanrooyen]

Update to observation script:

• drift scans are now included, but katpoint does wierd things, need to look at the success of this in more detail python observe.py --profile test_targets.yaml
• User logger now displays type of observation as well as first tag name, e.g. target, bpcal, etc python observe.py --profile ../config/two_calib.yaml

Should have most of what we need to start off with for correlator observations See the following wiki pages for examples https://github.com/rubyvanrooyen/astrokat/wiki/Observation-configuration-examples https://github.com/rubyvanrooyen/astrokat/wiki/From-proposal-to-observation-schedule-block

[tony2heads]

stick the

!/usr/bin/env python

at the start of mkat_lst.py and catalogue2config.py and we can make them executable.

[rubyvanrooyen]

Closing this repository, follow development https://github.com/ska-sa/astrokat