Open ygrange opened 6 years ago
I did add @jiskattema to this issue, as I don't think he reads slack.
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?
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 .
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?
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 .
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).
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)
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.*
NBIT* - bits per sample; task.nrChannelsPerSubband is the number of channels per subband (yeah; pretty descriptive key). Maybe configuring number of bits per channel via external cfg, or do we want it from MAC?
External config should be fine. It's a fixed value anyway. Now 8 bit, when 6 bit mode is available we will always be using 6 bit.
FILE_SIZE - Probably calculable from some of the already used parameters. What is common practise?
This would we calculable from the length of a trigger (i.e. the size of 5 seconds of data)
RESOLUTION - (frequency resolution I assume; if not, ignore the rest of this sentence) I guess this may be calculable from a few of the originally defined parameters (arts.survey.nrSamplesPerChunk, arts.survey.zappedChannels and maybe arts.survey.nrChunks). Correct?
This is some psrdada resolution thing, it should be the size of a ringbuffer page (i.e. number of channels number of samples per 1.024 seconds (=25000 or 12500 for SC4/SC3) sample size in bytes)
BYTES_PER_SECOND - Comparable to FILE_SIZE; should be calculable based on telescope properties and a few observation settings.
*Effectively just RESOLUTION divided by 1.024*
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 .
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.