Mapping between keys in README and keys in the interface doc #1
Comments
|
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 <[email protected]>:
… 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
<#1 (comment)>,
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. |
|
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 <[email protected]>:
… 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
<#1 (comment)>,
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 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 <[email protected]>:
… 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
<#1 (comment)>,
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.
The text was updated successfully, but these errors were encountered: