[gradsusr] EOF Analysis in GrADS

Arlindo da Silva dasilva at alum.mit.edu
Sun Oct 31 12:13:02 EDT 2010


On Sun, Oct 31, 2010 at 10:58 AM, Mubashar Dogar <mubashardogar at gmail.com>wrote:

> Dear GrADS Users,
>
> I am interested to do EOF analysis using GrADS udf utility? I am using
> grads 2.0.a7.oga.3. Could you please guide me that this version support EOF
> analysis or I have to swich some older version of GrADS? It will be highly
> appreciated if you could guide me with some steps for doing EOF analysis as
> well?
>
>
The old EOF udf does not work AS IS in 2.0.a7.oga.3 although with modest
effort it could be implemented as an opengrads extension. However, I
personally have not had any motivation for doing this because EOFs are
really easy with pygrads, e.g.,


http://opengrads.org/wiki/index.php?title=PyGrADS_Interactive_Shell#Computing_EOFs

You don't really need to learn python to use the pygrads command line
interface, but learning python is always a good investment.

Alternatively, the opengrads bundle that you have includes the IPC extension
which includes functions ipc_save/ipc_load that can be very useful to
interface to fortran codes such as the EOF udf. See this:

       http://opengrads.org/doc/udxt/libipc/

The command ipc_save can be used for you to save a variable/expression to a
disk file, using the same format used by the old udfs, e..g.,

ga-> ipc_save ps ps.data

the function ipc_load reads this data back in,

ga-> d ps - ipc_load('ps.data')

should produce a zero field. Now, if you sandwich a "!" system call in
between ipc_save/ipc_load you get a poor man UDF:

ga-> ipc_save ps ps.data
ga-> ! do_something_with_ps.x  ... commnand line args ...
ga-> d ipc_load('output.data')

where I am assuming that your  "do_something_with_ps.x" program knows how to
read "ps.data" and writes the output file "output.data"; you can pass
command line arguments to further inform your program about what to
do. Because each variable is saved to an individual file you will need to
make adjustments to your old-style UDF to read these from separate files,
but this shuldn't be too hard as the variables are saved in the same file
format (see man page above for more details.) The output file written by the
old-style UDF is directly readable by ipc_load.  For some syntatic sugar,
the 3 lines above (save/!/load) can be folded into a gsUDF

    http://opengrads.org/doc/udxt/gsudf/

so that your poor man UDF can appear as a regular function:

ga-> d myudf(ps)

(Recall that gsUDFs allow you to write grads expression functions as a gs
script functions.)

    If I was going to port an existing old-style UDF I'd still implement it
as an extension, but the method I just outlined may be more attractive to
some people who do not want to bother writing the C-wrapper required by
extensions. In all of this, you will need an opengrads bundle distribution.
Although you could use sdfwrite as a replacement for ipc_save, in this case
you need to revise your UDF to read netcdf files instead, so using ipc_save
requires fewer code changes.

   Good Luck,

       Arlindo



> Regards,
>
> Mubashar
>
>
> _______________________________________________
> gradsusr mailing list
> gradsusr at gradsusr.org
> http://gradsusr.org/mailman/listinfo/gradsusr
>
>


-- 
Arlindo da Silva
dasilva at alum.mit.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gradsusr.org/pipermail/gradsusr/attachments/20101031/7ca3e48c/attachment-0003.html 


More information about the gradsusr mailing list