Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SCAN subtable #316

Open
kgolap opened this issue Nov 22, 2024 · 2 comments
Open

SCAN subtable #316

kgolap opened this issue Nov 22, 2024 · 2 comments

Comments

@kgolap
Copy link

kgolap commented Nov 22, 2024

I think a scan "subtable" (i.e scan_xds) is needed where an association of SCAN_NUMBER to more info that includes the intent, the time interval that the scan was observed and/or any other hardware settings that are specific to this scan (may be combined with intent).

Otherwise we already discussed antenna, pointing and field xds.

@Jan-Willem
Copy link
Member

A MSv4 can have more than one intent but all visibilities must have the same intents. A single visibility can have more than one intent for example ALMA commonly has:

['OBSERVE_TARGET#ON_SOURCE', 'CALIBRATE_WVR#ON_SOURCE']

This intent information is currently stored in ms_xds.partition_info['intents']. We can add additional information in the SCAN_NUMBER attributes. @kgolap what do you suggest we add?

@kgolap
Copy link
Author

kgolap commented Dec 11, 2024

I guess SCAN_NUMBER is moot for a single msV4 but its existence is really when working with multiple msV4...then just a number does not make sense unless it is tied to a processor and intent.

My bad i missed that the partition_info contains the intents. Well then things have to be associated with the SCAN_NUMBER may be as a key. I guess that ms_xds.processor_info will have to a similar reference

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants