Date: Wed, 5 Jun 2013 17:18:28 +0000
From: "Marrone, Daniel P - (dmarrone)" 
To: Jun-Hui Zhao , Glen Petitpas , Ken Young ,
     "cqi@cfa.harvard.edu" 
Subject: track with crate loss

Hello all,

In my latest track, 130524_03:24:11, a fuse blew in crate 10 and so crates 4/10 were removed from the project. Unfortunately, the
data continued to be written to the same file. I can't load this file in miriad because the data structure changes during the
track. MIR also has some trouble and has to revert to "OLD READDATA" to read it, it's crunching away on that now and probably will
be for hours.

I can see a few ways forward, all of which would be useful in many applications (at least for me, since I seem to have trouble
loading about 1 out of every 5 tracks that I get). I email to solicit as much help as I can get. 

Jun-hui, it's possible that smalod could read this if the nscans input worked for 4GHz data. I can find the boundary scan in MIR
and could read only before or after it with this keyword. Do you think this would work, and if so, is there any chance you could
implement nscans for 4GHz data? If this wouldn't work, could you not add a little error checking to the data reading so that it
would report a change in the data structure and exit gracefully with the data it can access? 

Taco, one time a long time ago you rewrote a raw data file for me when it was corrupted. I've asked you before about making it
possible for me to hack at the code that could do this but not gotten a response. I could take that as a hint that it's impossible,
but I am not good at subtlety. In this case (and probably most cases, since I could always leave the bad data out of the file),
just code that could divide a data file into parts at a certain scan number would be adequate. Can anything be done on this front?

Charlie, I could load this through mir and write out to miriad. However, the idl2miriad writer does not fill the miriad header with
enough variables to do everything I need. I could come up with specific examples if you are willing to update that code to make it
more closely resemble native miriad files.

glen, I don't know that errors like this happen often, but starting a new file might be worth suggesting to the operators if there
is some catastrophic change during a track. 

Thanks,
Dan


Dan Marrone
Assistant Professor
University of Arizona
Department of Astronomy/Steward Observatory
933 North Cherry Avenue
Room N314
Tucson, AZ 85721

Office: (520) 621-5175
Fax: (520) 621-1532