[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: FAN

> Organization: CSIRO Division of Atmospheric Research
> Keywords: 199502161139.AA29996

Harvey,

> I have finally completed testing new FAN software & put file fan.tar.Z into
> ftp:://atmos.dar.csiro.au/netcdf/hld/ as before.

Great, I grabbed and unpacked it with no problems.

> I have tested it on SGI, DEC alpha and Cray systems.  I have almost totally
> rewritten ncrob to provide more facilities (more stats e.g. sd's, automatic
> creation of output var/file) and automatic splitting of input into chunks
> which will fit into fixed-size (settable using -b option) buffer.  Latter
> greatly reduces memory for large input arrays.

When Steve builds it here, we'll test it on our other platforms.  We also
ended up splitting the input into fixed-size chunks in our initial netCDF
operators to handle arbitrarily large input arrays using a fixed-size memory
buffer.

> Note that fan.tar includes a very simple stand-alone program called 'unit'
> based on your udunits system.  Program 'unit' is called from fan routines to
> do unit conversion.  Call is done by creating an internal pipe using standard
> C function popen.  I had to do it this way because yacc (at least our version)
> cannot cope with more than one language (in this case FAN and udunits).

Steve can correct me if I'm wrong, but I think he came up with a solution
for this problem that permits using udunits in another program that also
uses yacc.  Thus it might be possible for him to implement this without the
use of a separate process.

> ...  It
> would be possible to provide the required functionality in your stand-alone
> program 'udunits' or you might rename 'unit' to something a little more
> unique.  Perhaps it would be better to write a new program combining the
> functionality of both 'udunits' and 'unit' - I would be happy to do this.
> 
> Examples of use of 'unit' are:
> $ unit inch mm
> 25.4
> $ unit degC degF
> 1.8 32
> $ unit '60 km/hour' 'miles/h'
> 37.28227153
> 
> I have found 'unit' more useful than your interactive 'udunits'.  In
> particular I have used it in shell scripts using command substitution with
> backquotes.  So I suggest it is worthwhile documenting 'unit' so users can
> use it directly as well as indirectly via fan.
 ...
> fan.tar includes directory 'doc' containing 3 rather out-of-date files which
> you will probably not want.  I have just started thinking about how to merge
> the relevant information into new fan documentation suited to your needs.
> 
> There are really 3 distinct groups of high-level utilities:
> 1. ncgen, ncdump based on CDL language
> 2. nc2text, text2nc, ncrob using FAN language
> 3. udunits, 'unit' based on udunits language
> 
> I suggest a separate chapter for each of these three.  I feel the new version
> of ncrob needs to be discussed in the NetCDF User's Guide as well as a man
> entry.

That sounds fine, although we have until now kept udunits separate from
netCDF, since it is useful independently.  We may want to preserve this
separation and just refer to the udunits documentation from the netCDF
documentation.  On the other hand, since we already found it necessary to
include an appendix on udunits in the current NetCDF Users' Guide, I guess
using a separate chapter instead might make sense, since the only existing
udunits documentation is a man page reference rather than a users' guide.

> I suggest I write:
> 
> 1. chapter on FAN, nc2text, text2nc, ncrob using LaTex (assume it should be
>    pretty easy to convert it to texinfo)

Yes, that would be easy as long as you don't use graphics or equations,
which texinfo can't handle well.  There is actually a latexinfo package that
combines the best of both, but I'm not sure what it does with converting
graphics and equations into text for the resulting info file.

> 2. man entries for FAN, nc2text, text2nc, ncrob and possibly 'unit' using
>    HTML, which it is time I learnt.  It would be useful to get a copy of
>    one of your HTML man files - How do I do that?

We used to convert our man pages from troff man macros to HTML documents
using a filter called man2html from CERN, but that required that we run the
filter every time a man page changed to keep the two documents consistent.
Now we use something called man-cgi, which is invoked by our WWW server to
convert man pages into HTML on-the-fly.  This gives us WWW access to all our
man pages (and all the vendor-supplied man pages) without explicitly
converting them, and also solves the problem of keeping the HTML versions
up-to-date.

> How does this sound to you?  How urgent are these?

It sounds fine, and there's not much urgency, since I think we won't get a
new netCDF release ready for at least a couple of months.

The delay in a new release is partly because we've recently agreed to try to
implement a fairly ambitious form of support for packed binary data in the
next netCDF release (storing arrays of n-bit values in packed binary form).
There has recently been much demand for this feature, and we think we've
worked out a fairly transparent way to do it that won't incur any cost for
users who don't need it.

 ...

> Nc2text, text2nc & ncrob call mainly my higher level FAN routines rather
> than directly using the netCDF library.  Should these FAN routines go into
> the netCDF library?  Explaining their use (& associated C structures)
> would be quite difficult & would probably be beyond (& confusing &
> frustrating to) average reader.  I suggest not including them, at least in
> short term.  I hope more sophisticated programmers can work out how to use
> them from the source code.  I guess some man entries for FAN routines
> might be useful, but I think it can wait a while.

I agree with your suggestion of not documenting the FAN library in the
NetCDF Users' Guide, and I withdraw my suggestion about documenting ncrob
separately as an example of use of the netCDF library.  Documenting ncrob in
the chapter with nc2text and text2nc sounds fine.  

--Russ

______________________________________________________________________________

Russ Rew                                                UCAR Unidata Program
address@hidden                                          P.O. Box 3000
http://www.unidata.ucar.edu/                          Boulder, CO 80307-3000
______________________________________________________________________________