[OpenMadrigal-developers] Re: [MidasW-developers] New information in IFAM, CMST and Madrigal

[John Holt]

Putting record type information in header records seems reasonable. It
does thrust the header record into a much more prominent role than
previously, but that may be a good thing. Are you thinking of using
just one header record, as we do now, or multiple header records, as
some other radars have done? For example there could be a header record
before each experiment if the file contains more than one experiment,
or before each cycle. However one does it, there will be many CCYCLE
lines - on the order of 200-300 in a 24-hour experiment.

The flexiblity will be important when we begin to deal with the sorts
of things the AMISR will be able to do. I think it would be a good idea
for us to have a small meeting of Madrigal people in Santa Fe to
discuss some of these issues. For example, each radar now has an
assigned set of operation codes which it can define as it wishes.
Presumably a set will also have to be assigned to AMISR. Millstone has
defined many such codes, but very few have been defined for the other
radars. It would be good if we could expand the list of standard
parameter codes to cover some of the Millstone codes as well as the
needs of the AMISR.

John

> From: William Rideout <brideout at haystack.mit.edu>
> To: midasw-developers at haystack.mit.edu
> Subject: [MidasW-developers] New information in IFAM, CMST and Madrigal
> Date: Wed, 14 Apr 2004 14:03:16 -0400
>
> 
> As mentioned in a previous email, we are planning to add two fields to the 
IFAM 
> and CMST structures, 1) record_type, and 2) exp_cycle number.  This email 
> discusses the meaning of these fields, and suggests ways to persist this 
> information in Madrigal files.
> 
> record_type - an integer describing what type of of cycle this integration 
> period belongs to.  One use of this information is to aid in plotting the 
data. 
>   For now, we propose to define the following values:
> 
>      0  OTHER
>      1  FIXED_POS
>      2  AZ_SCAN
>      3  EL_SCAN
> 
> exp_cycle - an integer describing what overall experiment cycle this 
integration 
> period belongs to. An overall experiment cycle always begins with the first 
> cycle defined in the experiment file, and increments each time that first 
cycle 
> reoccurs, even if the last cycle did not precede it (that is, a reset 
occured).
> 
> I think this information needs to persist in the created Madrigal file, so 
that, 
> for example, plotting can be easily done with Madrigal files alone.  John and 
I 
> have already discussed saving the exp_cycle as Cedar parameter 95.  However, I 
> think we need a Millstone standard for storing information about groups of 
> records.  For example, in the case where a Madrigal file contains multiple 
> experiments (calibration / extra_wide_coverage / calibration), we might want 
to 
> include experiment names and record ranges for each.
> 
> I propose we add lines to the header record.  The header line would be of the 
> following form, where startRec starts at 0:
> 
> CCYCLE <startRec>  <endRec>  <description>
> 
> So, a Madrigal header record might have the following lines:
> 
> CCYCLE 0 100 OTHER
> CCYCLE 101 200 EL_SCAN
> CCYCLE 201 203 FIXED_POS
> CCYCLE 204 500 EL_SCAN
> CCYCLE 501 703 FIXED_POS
> CCYCLE 704 1000 AZ_SCAN
> 
> The only alternative is define new parameters that must take integer values 
> every time we want to persist alternative grouping schemes, so all values must 
> be mapped into a set list.  I think the header approach is more flexible and 
> easier for parsing, but please let me know what you think.
> 
> Bill
> 
> -- 
> Bill Rideout
> MIT Haystack Observatory
> Email: brideout at haystack.mit.edu
> Phone: 781 981-5624
> _______________________________________________
> MidasW-developers mailing list
> MidasW-developers at haystack.mit.edu
> http://www.haystack.mit.edu/midas_w/mailman/listinfo/midasw-developers
> 
> 
> !DSPAM:407d7d26149371938221855!
> 
>