[Thread Prev][Thread Next][Index]

FERRET "beefs"...

As a long-time and ardent user of FERRET, I can't say enough good things about
it. I use it many times a day, every day, for all kinds of things, from super
fast looks at raw data to relatively polished graphics for presentations and 


There are a few things about FERRET that are either a little irksome or really
frustrating (usually depending on how much pressure I'm under to get things 

1) Auto-promotion of variables in netCDF files from float to double, for no
   reason I can determine. Makes my f90 codes much more complicated to write
   and use.

2) Auto-promotion of variable names from lower to upper case. Extremely annoy-
   ing at times, because then I have to rename them if I need to merge two
   files together in which the data is on the same axes but the dimensions
   are "different", ie, "LON" and "lon".

3) Auto-elimination of "degenerate" axes. Let's say I've got 24 files of month-
   ly data that I average into 2 files of annual averages each. Those two files
   cannot now be easily concatenated together, because the time axis in each
   file is now gone, instead of having dimension 1. Charlie Zender's NCO pack-
   age (if you don't have it, GET IT!) leaves degenerate axes in place. Very

4) The whole Gregorian/Julian time thing. I know that using "year"/"yr", "gre-
   gorian_year" and "year360"/"year366" is *a* solution, but for a lot of my
   data, it's not a very good one, because I use "days" as my basic time unit.
   I think it would be much better to be able to define an attribute for the
   time axis something like "year_len", or "calendar" or something like that.
   For a fixed-length (365 days, 360 days, whatever) year:
        float time(time) ;
                time:units = "days since 0000-01-01" ;
                time:year_len = "365 days" ;
                time:long_name = "Time" ;

   For a "real" year:
        float time(time) ;
                time:units = "days since 0000-01-01" ;
                time:year_len = "365.2425 days" ;
                time:long_name = "Time" ;

   That way, I don't have to re-do all the values for my time axis to make them
   years instead of days.

5) The inability to easily draw more than just a few lines without running into
   thicker lines or messy symbols. If I want (say) 8 PLOT lines, I'm limited to
   (in color) black, red, green, blue, magenta, and cyan for the first six, but
   the next two are black and red again, twice as thick. I don't care for that.
   It would be nice to be able to define colors for each line 1 -> N, something
   akin to using the old GKS "call gscr" and "call gsplci" stuff.

6) Similar to (5), the ability to intermix PLOT lines of dashed/dotted with
   color lines. So far as I can tell, lines 2 -> N are dashed/dotted when the
   meta file is converted to postscript using "Fprint -l ps", and lines are
   put into color with "Fprint -l cps". Personally, I think line attributes
   (color, style, thickness, etc) should be independent of whether or not the
   postscript file is "color" or "black and white".

I want to reiterate that I think FERRET is a fantastic package (I really try to
avoid using anything else if possible) but the above idiosyncracies make it
harder to use than I think necessary.

I apologize if there are solutions to the above that I'm unaware of; I'm more
than happy to be put on the right track, but please, gently. :-)

Gary Strand
strandwg@ucar.edu                          http://www.cgd.ucar.edu/ccr/strandwg

[Thread Prev][Thread Next][Index]

Dept of Commerce / NOAA / OAR / PMEL / TMAP

Contact Us | Privacy Policy | Disclaimer | Accessibility Statement