from:	Young, Ken 
to:	Mark Gurwell 
cc:	Qizhou Zhang ,
Glen Petitpas ,
Chunhua Qi ,
David Wilner ,
Jun-Hui Zhao ,
Nimesh Patel ,
Eric Keto ,
Jonathan Weintroub 
date:	Mon, Aug 3, 2015 at 9:45 AM
subject:	Re: Next Quadrant of SWARM

On Mon, Aug 3, 2015 at 9:30 AM, Mark Gurwell  wrote:
[...]

    Now, I can't claim to even a smidgen of understanding on how SWARM interacts with the current dual receiver action...as far as I'm aware, we cannot do that right now (is this correct?) but at some point that can't always be the case.  So the question could be couched as 'how often will including ASIC help?' and it may be more significant than we realize (or it may be a lot less). I just don't understand the hardware *and* software limitations involved right now.  For example, you say this quadrant does '4-6'.  But do you mean 4-8? And in a dual pol mode then 4-6 (or perhaps 6-8? I hear John's new bdc is much more flexible then our current system).  Would it be possible to run ASIC 4-6 GHz dual pol, and SWARM quad 2 6-8 dual pol (and SWARM quad 1 does...what 8-10? )


Yes, I meant 4->8 for the next SWARM quadrant with 1 receiver, and 4->6 GHz with two.   I don't know if, in dual receiver mode, we will immediately be able to have ASIC cover 4->6, SWARM 2 cover 6->8 and SWARM 1 cover 8->10.   I guess we should ask about that in this week's wideband meeting.   If we're going to keep the ASIC running with two SWARM quadrants, we should at least make sure that we get as much as we can out of the system in two receiver operation.
 

    2) My preference would be to make the lowest IF frequency chunks the lowest numbered chunks (so, s49 and s50)...this would suggest SWARM quad 2 covers s49 and s50, then SWARM quad 1 (current SWARM) become s51 and s52.  Clearly, MIR should have no issues with this, since all the information should be passed in the headers on which chunk has which frequency range.


OK, that makes sense.   I can easily do that, of course.
 


    3) I can say that from use, MIR can handle the increased number of chunks - Charlie wrote the readdata routine to rebin SWARM bands into further new chunks, and as far as i'm aware (Charlie, please let us know) there are no restrictions on that. However, the raw data size may be an issue, since an 80 GB raw file would require upwards of 200 to 250 GB of RAM, which I don't think any machine has.  Or are you assuming the 'expanded' data file is 80 GB? If so, that might be ok. Charlie?

    However, if your rechunker program (which seems to be a misnomer, btw...you aren't creating new chunks, you are resampling/binning the old chunks...) will work on mulitple SWARM quadrants, then perhaps that isn't such a drawback...


Actually, my SMARechunker program can very easily produce simulated two, three or four (or fifty!) SWARM quadrant data, because it *can* create new chunks.    I'm reading a two-quadrant SWARM CMZ track into MIR right now (only 36 GByte on the sch_read file, because it's a 6 antenna track).   It's  pretty slow (I estimate 45 minutes for readdata with no rebinning) but it seems to be working.

Taco