[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
papers.
However...
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
done):
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
nice.
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