[Pafgbt] PAF beamformer size and cost

[Rick Fisher]

A rough beams per element number may be useful for general parameter 
studies, but the details depend on specific science applications.  We 
should prepare a fairly detailed analysis of beam efficiency and beam 
shape as a function of position in the FOV so that the astronomers can 
weigh in on what's most useful.  A finding survey may want a different 
beam configuration from a mapping application, and the number of useful 
beams may be different when the allocation of signal processing resources 
is taken into account.

Rick

On Thu, 4 Feb 2010, Karl Warnick wrote:

> One tidbit of information that may be useful on the number of independent
> (3 dB spaced) beams per element. CSIRO's analysis predicts this to be 2.4
> elements per beam. I checked their analysis, and found that it is
> accurate for large N, but breaks down for small arrays, since small
> arrays have a larger field of view in relation to the number of elements
> than large arrays. For a 19 element array, the number of independent
> beams is about 11.
> 
> Recently Bruce Veidt sent out a communication which suggested 6 elements
> per beam, but I'm not sure where this came from, and that value doesn't
> jibe with my analysis.
> 
> In case "independent beams" is confusing to anyone, think of it this way.
> With an N element array, if one forms M beams, and uses those beams to
> image the array field of view, then as M is reduced from N to zero the
> average sensitivity over the field of view to an arbitrarily located
> point source drops off slowly, but when M is smaller than the number of 3
> dB spaced half-power beams that tile the field of view, the average
> sensitivity begins to drop off rapidly. So, it's very convenient to think
> of the area of the field of view measured in half power beam (HP) areas
> as the number of independent beams, since only a modest improvement in
> sensitivity can be had by forming more beams, whereas average sensitivity
> rapidly becomes small if fewer beams are formed.
> 
> It is true that the ripple in sensitivity over FoV caused by forming
> fewer than N beams is not desirable. When I was in Sydney, CSIRO was
> struggling to determine the optimal "oversampling" factor (i.e., how many
> more beams to form than the HPB area of the FoV), balancing signal
> processing hardware with sensitivity flatness, but the right answer is
> still somewhere between the HPB area and a small multiple of the HPB
> area.
> 
> It hasn't been shown yet, but I conjecture that same conclusion holds
> whether eigenbeams or point beams are formed.
> 
> Karl
> 
> Brian Jeffs wrote:
>
>  Rick and all,
> 
> 
> On Feb 4, 2010, at 11:47 AM, Rick Fisher wrote:
>
> 
>
>  Brian,
> 
> Thanks very much for the beamformer outline.  How does Jason handle 
> the
> frequency dependence of the beamformer weights?  Is there an FIR is 
> each
> signal path or maybe an FFT - iFFT operation?
>
> 
>
>  The beamformer weights are applied per frequency channel, each of 
> which is less than 1 MHz wide.  Thus broadband beamforming is 
> effectively implemented by using potentially different weights for 
> each narrow band.  This is actually overkill since the fractional 
> bandwidth per freq. channel is very small.  We could probably get away 
> with using the same weights over 20 MHz of adjacent channels.
> 
>
> 
>
>  What to do with the high bandwidth beam outputs at high time 
> resolution is
> a standard pulsar problem.  Since the beam outputs are essentially the
> same as you'd have with a conventional horn feed, all of the current
> tricks of the trade will apply.  As far as I know, all pulsar 
> surveys are
> done by generating spectra with a frequency resolution consistent 
> with the
> highest expected pulse dispersion, squaring the signals, integrating 
> for
> the selected resolution time, and streaming this to disk.  Pulse 
> searches
> are then done off-line in computer clusters or supercomputers.  (Our
> pulsar experts can chime in here.)  We'll need to match our output 
> data
> rates with available storage and post-processing capabilities - a
> time-dependent target.  Maybe someone could give us some currently
> feasible numbers and time derivatives
> Before completely buying into the voltage sum real-time beamformer we
> should keep in mind that a lot of single dish applications don't need
> voltage outputs as long as the time and frequency resolution 
> parameters
> are satisfied.  If there are big computational savings in a
> post-correlation beamformer, and we satisfy ourselves that there's 
> not a
> hidden gotcha in this approach, we should keep it on the table.
> 
>
>  The real driver here seems to me to be the required time resolution. 
> This will control the integration time, and thus the data rate.  The 
> numbers I quoted for data rate assumed no integration, i.e. output 
> every sample to the next downstream system.  This is clearly beyond 
> our near term capabilities, so we must have some integration going on 
> in the CASPER beamformer.
> 
> There are no computational advantages to post correlation beamforming 
> unless either a) you need to do the correlation anyway; then 
> beamforming is almost free, or b) the number of computed beams is 
> significantly larger than the number of array elements.   In either 
> case, the time resolution imposed by the correlator STI time must 
> match the observation goals.
>
> 
>
>  My guess
> is that any computational advantages evaporate or even reverse when 
> the
> required time resolution approaches the inverse required frequency
> resolution.
> 
>
>  I agree with this statement.
> 
> Brian
> 
> 
>
> 
>
>  Rick
> 
> On Thu, 4 Feb 2010, Brian Jeffs wrote:
>
> 
>
>  Rick,
> 
> See below:
>
> 
>
>  Is your assumed beamformer architecture voltage sums or post- 
> correlation?
> In other words, are the beams formed by summing complex weighted 
> voltages
> from the array elements or by combining cross products of all of the
> elements?  John's reference at http://arxiv.org/abs/0912.0380v1 
> shows a
> voltage-sum beamformer.  The post-correlaion bamformer may use fewer
> processing resources, but it precludes further coherent signal 
> processing
> of each beam.
> 
>
>  Our plans are based on a correlator/beamformer developed by Jason 
> Manley for
> the ATA and some other users (the pocket packetized correlator). 
> He recently
> added simultaneous beamforming to the existing correlator gateware, 
> so they
> run concurrently.  In our application the only time this is 
> required is
> during interference mitigation.  Normally we correlate during 
> calibration and
> beamform otherwise.
> 
> His design is a voltage sum real-time beamformer.  At this point he 
> does not
> compute as many simultaneous beams as we need to, so I think we 
> will have to
> exploit the computational trade-off to do either beamforming or 
> correlation
> but not both, or it will not fit in the FPGA.  Post-correlation 
> beamforming
> is really quite trivial, and has a low computational burden, so 
> that could be
> added to the correlator and run simultaneously.  I believe that 
> when we need
> simultaneous voltage sum beamforming and correlations (as when doing
> interference mitigation) we will have to reduce the effective 
> bandwidth.  We
> really cannot take Jasons' existing code and plug it right in for our
> application, but it will serve as a very good template.  That is 
> why we have
> Jonathan out at UC Berkeley for 6 months, so he can learn the ropes 
> and then
> work on our correlator/beamformer.
> 
>
> 
>
>  Very roughly, the science requirements for a beamformer fall into 
> two
> camps, which may be operational definitions of first science and
> cadallac/dream machine: 1. spectral line surveys with bandwidths 
> in the
> 3-100 MHz range and very modest time resolution and 2. pulsar and 
> fast
> transient source surveys with bandwidths on the order of 500+ MHz 
> and <=50
> microsecond time resolution.  The 2001 science case says pulsar work
> requires bandwidths of 200+ MHz, but the bar has gone higher in the
> meantime.  One can always think of something to do with a wide 
> bandwidth,
> low time resolution beamformer, but it would be a stretch.  The GBT
> sensitivity isn't high enough to see HI at redshifts below, say, 
> 1350 MHz
> in a very wide-area survey.  Hence, building a beamformer with wide
> bandwith but low time resolution may not be the optimum use of 
> resources.
> Also, the 2001 science cases assumes 7 formed beams, but the 
> minimum now
> would be, maybe, 19 and growing as the competition heats up.
>
> 
>
>  We are operating under the assumption of at least 19, and probably 
> more than
> 40 formed beams.  If we only use the correlator for calibration, 
> then we
> should be able to achieve both relatively wide bandwidth (250 MHz) 
> and high
> time resolution (we will get a beamformer output per time sample, 
> not just
> per STI interval).  Dan and Jason feed that based on their 
> experience with
> existing codes this is achievable on the 40 ROACH system we 
> sketched out, but
> we will have to wait and see.  If we run into bottlenecks we will 
> have to
> reduce either bandwidth or the number of formed beams.
> 
> One issue I am not clear on yet is what we do with the data streams 
> for 40+
> voltage sum beams over 500+ frequency channels.  How do we get it 
> off the
> CASPER array, and what will be done with it?  For 8 bit complex 
> samples at
> the beamformer outputs you would need the equivalent of fourty 10 
> Gbit
> ethernet links to some other big processor, such as a transient 
> detector. If
> this is unreasonable then either the number of bits per sample, 
> bandwidth, or
> number of beams will need to be reduced.  Alternatively, it is not 
> hard to
> add a spectrometer to the beamformer outputs inside the
> correlator/beamformer, and this provides a huge data rate 
> reduction.  But how
> do we handle data for transient observations where fine time 
> resolution is
> critical?
> 
> Brian
> 
> 
> 
>
> 
>
>  Counter-thoughts?
> 
> Rick
> 
> On Wed, 3 Feb 2010, Brian Jeffs wrote:
>
> 
>
>  Rick,
> 
> We have a rough architecture and cost estimate for a 40 channel
> correlator/beamformer capable of 40 channels (19 dual pol 
> antennas plus
> reference or RFI auxiliary) over 250 MHz BW.  We worked this out 
> with
> CASOER
> head Dan Werthimer and his crack correlator/beamformer developer 
> Jason
> Manley.  It will require 20 ROACH boards, 20 iADC boards, 1 20- 
> port 10
> Gbit
> ethernet switch, and some lesser associated parts.
> 
> Our recent ROACH order was $2750 each, iADC: $1300 each, 
> enclosures: $750
> each, XiLinx chip: free or $3000,  ethernet switch: $12000.
> 
> You can use your existing data acquisition array of PCs as the
> stream-to-disk
> farm, but will need to buy 10 Gbit cards and hardware RAID 
> controllers.
> 
> The total (which will be a bit low) assuming no free XiLinx parts 
> and not
> including  is:  $168,000.
> 
> Of course this does not include development manpower costs.
> 
> Brian
> 
> 
> On Feb 3, 2010, at 3:05 PM, Rick Fisher wrote:
>
> 
>
>  This is an incomplete question, but maybe we can beat it into 
> something
> answerable:  Do we know enough about existing applications on 
> CASPER
> hardware to make a conservative estimate of what it would cost 
> to build
> a
> PAF beamformer with a given set of specs?  I'm looking for at 
> least two
> estimates.  What is a realistic set of specs for the first 
> science PAF
> beamformer, and what would the dream machine that would make a big
> scientific impact cost?  You're welcome to define the specs that 
> go
> with
> either of these two questions or I'll start defining them by 
> thinking
> "out
> loud".  The first science beamformer will guide the initial system
> design,
> and the dream machine will help get a handle on longer range
> expectations.
> 
> Cheers,
> Rick
> 
> _______________________________________________
> Pafgbt mailing list
> Pafgbt at listmgr.cv.nrao.edu
> http://listmgr.cv.nrao.edu/mailman/listinfo/pafgbt
> 
>
>  _______________________________________________
> Pafgbt mailing list
> Pafgbt at listmgr.cv.nrao.edu
> http://listmgr.cv.nrao.edu/mailman/listinfo/pafgbt
> 
>
>  _______________________________________________
> Pafgbt mailing list
> Pafgbt at listmgr.cv.nrao.edu
> http://listmgr.cv.nrao.edu/mailman/listinfo/pafgbt
>
> 
> 
>
>  -- 
> Karl F. Warnick                                  email:  warnick at byu.edu
> Associate Professor                              Tel:    (801) 422-1732
> Department of Electrical & Computer Engineering  FAX:    (801) 422-0201
> Brigham Young University
> 459 Clyde Building
> Provo, UT 84602
> 
> 
> 
> 
> 
> 
>