<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
Comments below.
<div><br>
</div>
<div>Brian</div>
<div><br>
<div><br>
<div>
<div>On May 20, 2013, at 10:28 AM, Karl Warnick wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div text="#000000" bgcolor="#FFFFFF">I agree that correlations are important. Correlated outputs will probably be the default mode for most PAF observations, and real time beams would only be used when phase information is important, such as for pulsar surveys
(can pulsar searches be done with fine grained, narrowband correlations?) </div>
</blockquote>
<blockquote type="cite">
<div text="#000000" bgcolor="#FFFFFF"><br>
I'm not sure whether the bandwidth issue is the real driver. Real time beams also have to be formed in subbands and then either processed for pulsar surveys or integrated for power spectra.
</div>
</blockquote>
<blockquote type="cite">
<div text="#000000" bgcolor="#FFFFFF">I don't think bandwidth is really what drives the difference between a B engine and an X engine. It's true that if one only forms a few PAF beams, then with a given disk storage data rate one could store the beam outputs
over finer frequency subbands than correlations, but if fully sampled beams are formed, the data rate wouldn't be very different between beam outputs and correlations with the same integration time and frequency resolution. Am I missing something?<br>
</div>
</blockquote>
<div><br>
</div>
<div>For the same integration time and frequency resolution, roughly the same number of beams as PAF elements (fully sampled beams and Nyquist array sampling), ignoring the N log N complexity growth of an FFT, ignoring processor architecture constraints, and
if you don't need time series data for downstream processing, then there is no relative advantage between an integrating B engine and an X engine as to data rate. There are however some very real practical limitations.</div>
<div><br>
</div>
<div>If you have an ASKAP PAF you have many more elements than beams, so a B engine is more efficient. With our PAF, which has about the same number of beams as elements, the calculus changes.</div>
<div><br>
</div>
<div><u>All frequency channelization must be performed before the correlations (X engine) stage</u>, so if you need fine-grained frequency resolution you need a huge FFT to handle the 800 Msamp/s target sample rate of our back end. We don't have a processor
architecture that can do that FFT size (due to N log N growth). You must do coarse FFTs first, then either real-time beamform or correlate. If you correlate (e.g. and then beamform) you can never get to the fine frequency resolution. If you real-time beamform,
you can follow with another FFT stage to get fine frequency channels. You could then correlate, or integrate squared spectra, or send to pulsar processing as suites the application.</div>
<div><br>
</div>
<div>For pulsar work I don't know what the frequency resolution requirements are, so I can't judge whether you can beamform after correlation. I don't think "fine grained, narrowband correlations" are possible since to be narrowband means correlations would
necessarily be coarse grained in time. </div>
<br>
<blockquote type="cite">
<div text="#000000" bgcolor="#FFFFFF"><br>
There is another motivation for beamformers in the broader PAF community, and that is for synthesis arrays. The correlator for the dish array is expensive, so one would only want to correlate as small a number of beams from each PAF as possible. This raises
a question - could correlations from each PAF be used to get correlations of the dish array somehow? Is there an efficient two-level correlator architecture, with a PAF correlator for each dish, followed by the synthesis array correlator? I suspect not, but
I can't quite convince myself. In any case, it seems that for single dish telescopes, there's less motivation to use a beamformer back end instead of a correlator.<br>
</div>
</blockquote>
<div><br>
</div>
I agree with this. That is why ASKAP uses a real-time beamformer ahead of the correlator. Correlation across the dishes requires frequency channelized times series, not integrated data. I have not seen proposals for a two-level correlator. The first stage
(PAF level) correlation removes all absolute time or phase reference information for one dish relative to another, which is the key signal component needed to form the 2nd level (dish to dish) correlation. The other reason for doing real-time beamforming
at the PAF level is to reduce data transport requirements (many more elements than beams). Eigenbeams further reduce the data transport load. Integrated correlations would of course be even lower data rate, but I don't see how to get the cross dish visibilities
from PAF correlations.</div>
<div><br>
</div>
<div>For a single dish PAF the arguments are weaker for real-time beamforming unless actual time samples or superfine spectral resolution are needed.</div>
<div><br>
<blockquote type="cite">
<div text="#000000" bgcolor="#FFFFFF"><br>
Finally, there is probably a bit of analysis one could to to show how closely beams must be spaced in order for the information in the beams to be equivalent to the correlations. It's essentially the problem of recovering the matrix R from a set of inner products
w'*R*w for many vectors w. I suspect that if one forms HPBW/2 spaced beams over the PAF FoV, the information in the beams is less than but on the order of the information in R in some quantiable sense. Information in the deep sidelobes is lost, but most of
the large eigenvalues of R represent sources in the field of view. With finer beams, even just over the PAF field of view, all information even out in deep sidelobes could well be contained in the beam outputs, but that's a moot point, as one would not form
that many beams in practice. There's also the idea of eigenbeams proposed by Cornwell et al., so that one can form very few PAF beams yet still have information over the full field of view.<br>
</div>
</blockquote>
<div><br>
</div>
I agree with this.</div>
<div><br>
</div>
<div><br>
<blockquote type="cite">
<div text="#000000" bgcolor="#FFFFFF"><br>
Karl<br>
<br>
<br>
<div class="moz-cite-prefix">On 5/20/2013 9:25 AM, Brian Jeffs wrote:<br>
</div>
<blockquote cite="mid:1D10B2E0-FBCD-45C4-A239-62085605DD78@byu.edu" type="cite">Rick,
<div><br>
</div>
<div>I agree that you have much more flexibility to try different beamformer designs, detection algorithms, interference mitigation techniques, superresolution, calibration correction, etc. if you store and operate on the accumulated cross products (correlation
matrices). However, you give up the ability to do fine resolution spectral processing. You are stuck with the coarseness of the correlator's frequency channelization. I don't know how problematic this is for some applications, such as pulsar searches, where
fine spectral resolution may be needed.</div>
<div><br>
</div>
<div>Brian</div>
<div><br>
<div>
<div>On May 20, 2013, at 6:38 AM, Anish Roshi wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div dir="ltr">
<div>
<div><br>
</div>
Yes indeed. We can form images with beams with different optimization if the correlations are recorded.<br>
</div>
Anish<br>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Sun, May 19, 2013 at 9:57 AM, Rick Fisher <span dir="ltr">
<<a moz-do-not-send="true" href="mailto:rfisher@nrao.edu" target="_blank">rfisher@nrao.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Brian, Karl,<br>
<br>
In trying to understand the ASKAP data processing architecture, I'm<br>
beginning to understand the fundamental importance of saving the<br>
cross-products between array element outputs in our own PAF data<br>
processing. In forming beams you throw away a lot of information in the<br>
array's field of view that can be recovered only by forming many beams<br>
with very close spacing (much closer than HPBW/2). This has important<br>
consequences for the sensitivity to point sources, as in the search for<br>
pulsars. Hence, I would suggest that the most important archived outputs<br>
from your signal processor are the cross-products rather than formed<br>
beams. For a given data storage volume, there's more information in the<br>
cross-products than in the formed beam outputs. In some respects, the<br>
"beam" concept is a holdover from a waveguide feed where there's only one<br>
output, and most of the information in the focal plane is reflected back<br>
into the sky.<br>
<br>
Rick<br>
_______________________________________________<br>
Pafgbt mailing list<br>
<a moz-do-not-send="true" href="mailto:Pafgbt@listmgr.cv.nrao.edu">Pafgbt@listmgr.cv.nrao.edu</a><br>
<a moz-do-not-send="true" href="http://listmgr.cv.nrao.edu/mailman/listinfo/pafgbt" target="_blank">http://listmgr.cv.nrao.edu/mailman/listinfo/pafgbt</a><br>
</blockquote>
</div>
<br>
</div>
_______________________________________________<br>
Pafgbt mailing list<br>
<a moz-do-not-send="true" href="mailto:Pafgbt@listmgr.cv.nrao.edu">Pafgbt@listmgr.cv.nrao.edu</a><br>
<a class="moz-txt-link-freetext" href="http://listmgr.cv.nrao.edu/mailman/listinfo/pafgbt">http://listmgr.cv.nrao.edu/mailman/listinfo/pafgbt</a><br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset> <br>
<pre wrap="">_______________________________________________
Pafgbt mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Pafgbt@listmgr.cv.nrao.edu">Pafgbt@listmgr.cv.nrao.edu</a>
<a class="moz-txt-link-freetext" href="http://listmgr.cv.nrao.edu/mailman/listinfo/pafgbt">http://listmgr.cv.nrao.edu/mailman/listinfo/pafgbt</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Karl F. Warnick
Department of Electrical and Computer Engineering
Brigham Young University
459 Clyde Building
Provo, UT 84602
(801) 422-1732
</pre>
</div>
_______________________________________________<br>
Pafgbt mailing list<br>
<a href="mailto:Pafgbt@listmgr.cv.nrao.edu">Pafgbt@listmgr.cv.nrao.edu</a><br>
http://listmgr.cv.nrao.edu/mailman/listinfo/pafgbt<br>
</blockquote>
</div>
<br>
</div>
</div>
</body>
</html>