Resent-Date: Wed, 17 Mar 2004 11:00:47 -0800
Resent-From: showalter@ringside.arc.nasa.gov
Resent-To: mshowalter@mail.arc.nasa.gov
Date: Wed, 17 Mar 2004 11:00:02 -0800 (PST)
From: Dick Simpson 650-723-3525 <rsimpson@magellan.Stanford.EDU>
To: mgordon@mail.arc.nasa.gov, rsimpson@magellan.Stanford.EDU,
        showalter@ringside.arc.nasa.gov
Subject: VG_2803
X-Junkmail-Status: score=0/60, host=arc-relay1.arc.nasa.gov

Mark and Mitch:

I printed a selection of text files from VG_2803 and took those with me 
to the LPSC meeting.  I took the CD, but have not had much chance to 
look at it in detail.  In particular, the directory/file structure and 
contents more than 2-3 levels deep remains largely unexplored.  

I think my impressions may represent those of a novice, biased somewhat 
by my recollections of participating in the data collection and early 
analysis phases 20 years ago.  I had very little role in the production 
of the files on this CD, however.  That work was done almost exclusively 
by Tyler, Marouf, Zebker, Rosen, and Gresh.

I will mail you the pages I printed and marked up.  Although you may 
have problems with my handwriting, I think this is a more practical 
approach than attempting to type the comments into a separate message or 
make annotations on the electronic files.  I'll plan to keep a photocopy 
of the material I mail and you can call with questions if any arise.  
For the most part, my mark-up comments are editorial.  I'm off to 
Germany today; will take the CD and continue the review.

1. My first general comment is that an archive of reduced data usually 
includes a significant discussion about the analysis procedures used to 
take the raw data to the finished product.  With the exception of a few 
allusions to "diffraction correction" and the importance of selecting 
resolution at the beginning of processing, there is almost nothing about 
the effort invested by Tyler, Marouf, and a couple generations of 
graduate students in this work.  Virtually all of the documentation 
centers on the techniques developed at the RINGS Node to resample the 
Stanford results and adjust them to the J2000 reference frame.  This is 
important; but it should not be the central point of the archive.  I 
suggest you consider extracting the relevant parts from ATLNOTES.PDF and 
inserting them into DATASET.CAT, with an abbreviated version for 
AAREADME.TXT.  You need a text-only version of ATLNOTES.PDF anyway; this 
just provides additional motivation.

2. That the RINGS effort is the true focus is re-enforced by the 
somewhat arbitrary labeling of the Stanford data as "source" and "raw".  
I think better titles might be STANFORD, REFORMATTED, J2000_CORRECTED, 
and EASYDATA - or something along those lines.  I acknowledge that this 
may require a significant effort on your part to revise the 
documentation.  But a poor choice of names at RINGS should not be forced 
onto the user community when it is so misleading.  The Stanford data are 
simply not "raw"!  Those are the files you should be spending the most 
time describing.

3. When I'm trying to understand what is on a CD, I usually start with 
AAREADME.TXT, then go to DATASET.CAT.  In each of those I found that 
these data came from the Voyager ring radio occultation experiments; 
but, except for some references to "processing", there wasn't much more.  
Only when I got to TUTORIAL.TXT did the pieces start falling into place.  
Although TUTOTIAL.TXT is a longer document, I think you would do better 
to take its contents and move those to DATASET.CAT and then put summary 
information into AAREADME.TXT.  You need clearer statements of what you 
have; the present arrangement spreads this information over too many 
files - and the most useful is not likely to be found very early by the 
novice user.  With the exception of the recommendations at the very end, 
I didn't find much in TUTORIAL.TXT that would help "guide" me through 
the volume; so I don't think it lives up to its billing anyway.

4. The appearance of multiple CALIB, GEOMETRY, DOCUMENT, and other 
directories throughout the volume is confusing.  I can understand why 
you might prefer to keep Saturn calibration documentation with the 
Saturn data; but you should give the directories unique names.  It is 
very hard for the reader, when you mention the "geometry" files, to know 
whether you are talking about files in S_RINGS/GEOMETRY, 
U_RINGS/GEOMETRY, /DOCUMENT/GEOMETRY, or even /SPICE.  This may seem 
like a trivial "context" relationship to you; but I've not put these 
directories together and don't have the background to understand your 
context.

   I will make the same comment about careless use of "data," "data 
set," and "supported."  If you are going to refer to the contents of 
S_RINGS and U_RINGS as THE data files, you should be very clear and 
consistent in using that terminology.  For example, do the contents of 
S_RINGS/CALIB and S_RINGS/GEOMETRY also fit within that title?  All 
other files are then presumably "ancillary".  All files in the volume 
are part of THE "data set" - the ancillary files do not SUPPORT the data 
set, they are part of the data set.  There is at least one place where 
the Saturn and Uranus files are described as separate data sets (see 
markups).  Finally, what does it mean to have "supported" software and 
"supported" data or data sets?  Some of the material on the CD is 
apparently NOT supported, and I don't know what that means.

5. I assume you used VG_280{1,2} files as templates for this volume.  
You need to root out remnants from those earlier data sets - file names 
starting with "U", references to "emissivity", etc.  You also need to 
get a little clearer on the meaning of "transmissivity," which I take to 
be ratio of powers.  You use it in the sense that it has a phase, which 
is not possible with power (see markups in DATASET.CAT).  This is a term 
that could probably be used more carefully in a lot of places; but let's 
be accurate here, since we're talking about fundamental definitions.

6. Your confusion about resolution versus sampling may be reconciled by 
recalling that Rosen resampled the original inversions to obtain a 
uniform radial scale (see AATLNOTES.PDF).  If you have complex samples, 
your Nyquist spacing will be the SAME as your resolution - each complex 
sample value contains two pieces of information (one real, one 
imaginary) so you need to sample only half as often as with real 
samples.  In order to achieve uniform radial resolution, Paul may have 
chosen to OVERSAMPLE in the original inversion; then he wouldn't have to 
worry about whether his resampling pressed the information limits around 
the Nyquist rate.  I think it's very likely that this was deliberate and 
was done to provide a buffer during his resampling.  It's not surprising 
that you find very little spectral content at frequencies above 1/res; 
if there were any, Paul's buffer wasn't doing its job.  This doesn't 
explain the factor of 8 difference in RU2 and factor of 4 in RU3; but it 
covers the factors of 2.  Maybe the others were just experiments.

7. You have invested a lot of effort in providing binary files in 
several formats; binary saves something like a factor of 3 in storage 
over ASCII, depending on how cleverly you represent the ASCII.  If you 
have three binary versions, however, you've lost the advantage; in 
addition, you have lost the intrinsic simplicity of the ASCII.  You 
might want to reconsider; would a single ASCII version instead of these 
multiple binaries be a better choice in the long run?

Regards,
Dick Simpson