search

TRASAL / dadatrigger

psrdada ringbuffer setup for triggering events and dumping to disc
Apache License 2.0
0 stars 0 forks source link

Mapping between keys in README and keys in the interface doc #1

Open ygrange opened 6 years ago

ygrange commented 6 years ago

I took the table from the README from this repo and tried mapping the keys for the start_observation command from table 1 in the Interface Specification from MAC to SC3+4. Looks like there is some difference between the two. Since Markdown pasting in Slack doesn't work, I just put it in an issue over here. I don't really mind where we discuss it further, as long as we are consistent in doing so :).

Interface fields in bold are implemented by APERTIF but do not appear in the interface document.

DADA header key Interface Field Type Qpid cfg
NCHAN arts.survey.nrChannels int
MIN_FREQUENCY arts.survey.frequencyChannel0 float
CHANNEL_BANDWIDTH arts.survey.channelBandwidth float
BW
TSAMP
RA task.beamSet.0.compoundBeam.X.phaseCenter [0] float
DEC task.beamSet.0.compoundBeam.X.phaseCenter [1] float
SOURCE task.source.name str X
AZ_START
ZA_START
MJD_START
NBIT
FILE_SIZE
SAMPLES_PER_BATCH
UTC_START task.startTime
RESOLUTION
BYTES_PER_SECOND
task.taskID str X
(N/A) arts.survey.mode str X
arts.survey.zappedChannels int []
arts.survey.nrChunks int
arts.survey.nrSamplesPerChunk int
arts.survey.DMs float []
arts.survey.integrationSteps int []
arts.survey.threshold float
isazi commented 6 years ago

I did add @jiskattema to this issue, as I don't think he reads slack.

ygrange commented 6 years ago

Also good that you're involved in the convo as aythor of the interface doc :).

RA and DEC are input parameters for the script. Those are defined per beam and dish in the parset. What should I assume we can take?

loostrum commented 6 years ago

An observation would be started via a parset on each node separetely, right? Each node corresponds to one compound beam (CB), so they would need to have the RA and DEC of the CB corresponding to that node. ARTS022 proceses CB21, because 1-based vs 0-based indexing ;) for ARTS each dish should point in the same direction.

2018-03-16 11:11 GMT+01:00 Yan Grange notifications@github.com:

Also good that you're involved in the convo as aythor of the interface doc :).

RA and DEC are input parameters for the script. Those are defined per beam and dish in the parset. What should I assume we can take?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/AA-ALERT/dadatrigger/issues/1#issuecomment-373666315, or mute the thread https://github.com/notifications/unsubscribe-auth/AGE140lITUZPpJTjM23_k0zqSrUS7ldeks5te4_GgaJpZM4SsPuD .

ygrange commented 6 years ago

So I guess the question is what we want to do. We could configure the CB covered by a node in an external config file. The advantage is that you can simply change the beam to be covered by a node at the cfg file level. This also means that each node in essence gets the same parset file. Is there anything in the processing strategy that would make this a bad idea?

loostrum commented 6 years ago

Yes, that could work. Which beam goes to which node is fixed, though. (well, it's specified in the config of the FPGA correlator) But it can't hurt to have it configurable in this way, plus it seems like a good idea to have basically the same parset for all nodes

2018-03-16 11:20 GMT+01:00 Yan Grange notifications@github.com:

So I guess the question is what we want to do. We could configure the CB covered by a node in an external config file. The advantage is that you can simply change the beam to be covered by a node at the cfg file level. This also means that each node in essence gets the same parset file. Is there anything in the processing strategy that would make this a bad idea?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/AA-ALERT/dadatrigger/issues/1#issuecomment-373668997, or mute the thread https://github.com/notifications/unsubscribe-auth/AGE147KD6Ny_qd5iTkLofWE1NXao9qhkks5te5HugaJpZM4SsPuD .

ygrange commented 6 years ago

Can anybody explain to me what the following parameters are supposed to mean?

BW - bandwidth of what? Full bandwidth of the observation? Does this mean channel width number of channels? Do we expect the case where we have a few missing channels; what would that mean for the BW, etc. AZ_START - This is in eseence calculable from RA/DEC, telescope positions and UTC: correct? ZA_START - This is in eseence calculable from RA/DEC, telescope positions and UTC: correct? MJD_START* - This is in essence another way of writing UTC_START; correct?

AZ_START and ZA_START is defined per telescope. Or is it precision-wise ok to assume the average location?

Maybe some of these parameters are fixed and should be configured in a .cfg file (see also the README on this page). I would propose to pull anything out of the parset that's already in there and discuss for the other paramters whether we still want the MAC to provide those (for example if we expect telescope properties to change when a system upgrade happens; I'd rather get those data from MAC than from a local cfg file that we have to remember updating).

ygrange commented 6 years ago

And the next question is: what about the parameters that have been defined in the interface doc and not used. Are those only relevant for the other use case (sorry; I keep mixing up 3 and 4 so I forgot which one this script applies to)

loostrum commented 6 years ago

BW - bandwidth of what? Full bandwidth of the observation? Does this mean channel width * number of channels? Do we expect the case where we have a few missing channels; what would that mean for the BW, etc.

*Full bandwidth of the system, i.e. it should always be 300 MHz (is

indeed channel width nr of channels). Missing channels do not matter, these show up as zeroes in the data, which is fine.

AZ_START - This is in eseence calculable from RA/DEC, telescope positions and UTC: correct?

*Correct. I'm doing this with astropy.coordinates now*

ZA_START - This is in eseence calculable from RA/DEC, telescope positions and UTC: correct?

*Correct.*

MJD_START - This is in essence another way of writing UTC_START; correct?

*Correct.*

AZ_START and ZA_START is defined per telescope. Or is it precision-wise ok to assume the average location?

*Delay tracking should change the signals such that there effectively

is a common position for all telescopes, i.e. there is only one value for the position of the WSRT as a whole. This location would be the best to use, although the differences between the telescopes are very very small so it's fine to just use the average.*

Maybe some of these parameters are fixed and should be configured in a .cfg file (see also the README on this page). I would propose to pull anything out of the parset that's already in there and discuss for the other paramters whether we still want the MAC to provide those (for example if we expect telescope properties to change when a system upgrade happens; I'd rather get those data from MAC than from a local cfg file that we have to remember updating).

*Agreed. So it may acutally be better to get NBIT from the MAC,

although the code would just crash if it receives NBIT=6 I think...*

— You are receiving this because you commented.

2018-03-16 11:42 GMT+01:00 Yan Grange notifications@github.com:

And the next question is: what about the parameters that have been defined in the interface doc and not used. Are those only relevant for the other use case (sorry; I keep mixing up 3 and 4 so I forgot which one this script applies to)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/AA-ALERT/dadatrigger/issues/1#issuecomment-373675188, or mute the thread https://github.com/notifications/unsubscribe-auth/AGE147CxaJRJdjOlE1De2K1yUN_PZRlNks5te5ctgaJpZM4SsPuD .