Differences
This shows you the differences between two versions of the page.
|
projects:meerkat:first_thoughts [2016/05/03 12:47] wucknitz |
projects:meerkat:first_thoughts [2016/11/24 10:46] (current) wucknitz |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | FIXME | + | ==== Some links ==== |
| - | http://www.ska.ac.za/meerkat/ | + | * http://www.ska.ac.za/meerkat/ |
| + | * https://en.wikipedia.org/wiki/MeerKAT | ||
| - | https://en.wikipedia.org/wiki/MeerKAT | + | ==== Some MeerKAT system details ==== |
| + | |||
| + | These details are our interpretation of the telecon on 20th May 2016: | ||
| + | * The "F-engine wide" will always be running and we can subscribe to its output. Total bandwidth (from L band) is 856 MHz (**we need 875**). Boresight delays (coarse and fine) are already corrected for. The number of channels depends on the observing mode: | ||
| + | - probably 1024 channels for pulsars, details not decided | ||
| + | - 4k channels for imaging, 8-tap filter (later maybe 16) | ||
| + | - 32k channel mode, 4-tap filter? (Time resolution with that is 37 microsec, still sufficient. (**Beware of wider PPF response in time.**) | ||
| + | * The wide-band correlator is also running all the time and we can receive its data as well. The frequency resolution is the same as the "Feng wide" output, time resolution is 0.5 sec. | ||
| + | * Phase solution will be computed whenever a calibrator is available. Time scale is unknown, probably 2-10 sec or so. The phase solutions will also be available and can be used by us. **Are they phase solutions per band or delays?** | ||
| + | * The (Feng?) voltage buffer keeps 2.5 sec of data. Upgrade to 4 sec or so may be possible, but if 10 or more are needed, it is better to buffer in our cluster. | ||
| + | * VLBI output will not be available within the next two years, probably only later than that. | ||
| + | * The standard beamformer (SKARAB boards) will produce 4 beams or maybe more. | ||
| + | * SETI will use similar approach as we are thinking of: Tap Feng output and beamform from that. | ||
| + | * We will need 64 links of 40Gbps each. Some data can be sent back to the switch (e.g. beamformed products). | ||
| + | |||
| + | Our beamformer (unsorted notes): | ||
| + | * Is expanding the hardware of the standard Beng beamformer an option? | ||
| + | * Is pretty straight-forward: Take Feng output, correct for atmospheric phase terms, then shift to residual offsets with phase factors. For >= 4k channels this should be fine, at least in S band. For L band and UHF we have to check this critically. | ||
| + | * Decimation in the beamformers, then transpose by sending back to switch (from band per node to beam per node). | ||
| + | * Need ca. 4k channels, time resolution 50 microsec. With 8 bit per sample and only Stokes I this corresponds to 80 MB/sec (640 Mb/sec). For 400 beams that is 32 GB/sec. When spread over 64 nodes or links, this is 0.5 GB/sec or 4 Gb/sec. This should be compared to the ~ 25 Gbps x 64 for the Feng data. This should still fit in the big switch so that we can use it for additional transpose operations (from beamformer to pulsar search). | ||
| + | * 4k channels have a time resolution of 4.7 microsec. We need 50, so the decimation factor is about 11. Input data are complex with two polarisations, output is real with only one Stokes I (factor of 4). In total the decimation factor is 43. We have 400 beams, which is a factor of 6.25 more than antennas. 6.25/43=0.145, the estimated ratio of data rates is 4/25=0.16, so this is consistent. | ||
| + | * **Second half of band is more difficult:** Need own Feng and maybe correlator and determination of phase solutions (dispersive and non-dispersive delay?). Expand their hardware or do own Feng in GPUs? Second half should go into same switch. | ||
| + | * **We may still want advanced beamformer options that require own correlations with full time resolution!** | ||
| Line 9: | Line 32: | ||
| === MeerKAT system === | === MeerKAT system === | ||
| + | |||
| + | * contact persons ? | ||
| - Is output from wide-band channeliser always available? | - Is output from wide-band channeliser always available? | ||
| - | - What is the channel width? Documents seem to indicate 32k or 64k channels for wide and 4k for narrow, but is this correct. | + | - What is the channel width? Documents seem to indicate 32k or 64k channels for wide and 4k for narrow, but is this correct? |
| - Are the internals of the "Feng wide" documented? Are delays really corrected for the primary beam centre? For proper beamforming we have to understand our input data in detail. | - Are the internals of the "Feng wide" documented? Are delays really corrected for the primary beam centre? For proper beamforming we have to understand our input data in detail. | ||
| - Are the delays that are applied by Feng available? Is the geometric model known? We have to apply additional delays, and these should be consistent. | - Are the delays that are applied by Feng available? Is the geometric model known? We have to apply additional delays, and these should be consistent. | ||
| - Is the "X-eng wide" correlator always running and can we use its output? We can also correlate ourselves, and that may even be preferable. | - Is the "X-eng wide" correlator always running and can we use its output? We can also correlate ourselves, and that may even be preferable. | ||
| - Sensitivity: We need some input to judge how well we can calibrate. | - Sensitivity: We need some input to judge how well we can calibrate. | ||
| - | - Calibration in general: Is any procedure planned for the B-engine beamformer (e.g. for VLBI)? Out beamformer would have to do exactly the same. | + | - Calibration in general: Is any procedure planned for the B-engine beamformer (e.g. for VLBI)? Our beamformer would have to do exactly the same. |
| - Will the B-engine beamformer deliver output for VLBI? | - Will the B-engine beamformer deliver output for VLBI? | ||
| - Can we implement something like the "Feng wide" in our "D engines" for the second half of the S band? This should be consistent with the existing "Feng wide". | - Can we implement something like the "Feng wide" in our "D engines" for the second half of the S band? This should be consistent with the existing "Feng wide". | ||
| Line 22: | Line 47: | ||
| === Our needs === | === Our needs === | ||
| - | - Resolution in time and frequency | + | - Resolution in time and frequency and bits (would 16 be sufficient?) |
| - Do we want to combine all antennas or only short(ish) baselines? | - Do we want to combine all antennas or only short(ish) baselines? | ||
| + | - Do we want to optimise the beam shape by weighting? (probably yes, but in which way?) | ||
| - Do we want additional products (beyond the 400 beams), e.g. full-primary-beam data with reduced time resolution? | - Do we want additional products (beyond the 400 beams), e.g. full-primary-beam data with reduced time resolution? | ||
| - I assume that we will also produce incoherent sums, they are also needed for the without-autocorrelation-beams approach. | - I assume that we will also produce incoherent sums, they are also needed for the without-autocorrelation-beams approach. | ||
| - How much voltage buffer (per antenna) do we need? | - How much voltage buffer (per antenna) do we need? | ||
| + | - Do we want to (or have to) feed any of our intermediate or output data back to the switch? | ||
| ==== Parameters ==== | ==== Parameters ==== | ||
| Line 45: | Line 71: | ||
| * delays: L/c, residual delays max. theta/2*L/c | * delays: L/c, residual delays max. theta/2*L/c | ||
| * for max. baseline: 27 microsec, for 1 km: 3.3 microsec | * for max. baseline: 27 microsec, for 1 km: 3.3 microsec | ||
| - | * for max. baseline at theta/2 at lowest frequency: 0.51 microsec (is sufficiently smaller than 4.7 microsec for 4k channels) | + | * for max. baseline at theta/2 at lowest frequency: 0.51 microsec (is sufficiently smaller than the 4.7 microsec that are the reciprocal bw for for 4k channels: sufficient) |
| * sensitivity ???? We need SEFDs for the planning. | * sensitivity ???? We need SEFDs for the planning. | ||
| Line 64: | Line 90: | ||
| same frequency setup, this is easier than in the general case. | same frequency setup, this is easier than in the general case. | ||
| - | Apparently the system does already compensate for delays of the phase centres | + | Apparently the system does already compensate for delays of the phase centre |
| so that we only have to deal with residuals within the field of view (primary | so that we only have to deal with residuals within the field of view (primary | ||
| - | beam). Even for the lowest frequencies this seem to be sufficient at the | + | beam). Even for the lowest frequencies this seems to be sufficient at the |
| half-power point of the primary beam. | half-power point of the primary beam. | ||
| Line 130: | Line 156: | ||
| calibrator sources > 100 mJy in our frequency range. | calibrator sources > 100 mJy in our frequency range. | ||
| - | NVSS has 62000 sources > 100 mJy (82 % of sky (34000 square deg), that is 1.8 | + | NVSS has 62000 sources > 100 mJy (over 82 % of sky, 34000 square deg), that is 1.8 |
| sources per square degree. Field of view in square degree: 3.8 at lowest | sources per square degree. Field of view in square degree: 3.8 at lowest | ||
| frequency, 0.32 at 2 GHz. This means it is unclear if there will always be a | frequency, 0.32 at 2 GHz. This means it is unclear if there will always be a | ||
