Re: customizing LAS: init script

[Jonathan Callahan <Jonathan.S.Callahan@xxxxxxxx>]

Jean-Marie,

Going through the email lists I see that we never answered this very 
important question.  I'll do my best to answer it in line.

-- Jon


J-M Epitalon wrote:

> Dear LASers,
>
> An initialization script is usefull to forge a virtual variable, for
> example, the sum of two actual variables....
> In that case, there is one initialization script associated to one
> particular variable.
>
> Now, I want to process several input variables all in the same way: say,
> for example, regridding them to a specific grid.
> They will share the same initialisation script.
>
> Usually, LAS expects from the initilization script to forge a specific
> variable, as it is declared in XML file, let's say 'myvar'.
>
> Suppose that 'myvar' is the result of an actual variable: 'original_var'
> or more simply named 'myvar_'
> Usually, this variable is created by means of a Ferret variable, using:
>    let myvar = expression (myvar_)
>
> I believe that it is possible to have the original and forge variable
> share the same name, as in:
>    let myvar = expression (myvar[d=mydataset])
> I am not sure of this: could you confirm ?
Ferret can do this but you must be very careful that the [d=mydataset] 
syntax is always included.  Ferret will not allow you to have two 
variables with the same name in the same dataset.

> Now, let's assume that I don't want my variables to share the same
> name...
>
> In the case the orginal variable is 'myvar_' the solution is
> straightforward:
>   let $1 = expression ($1_)
> since expected variable is given as a parameter to the script (here $1)
>
> But in the case the name of the original variable is 'original_var', how
> can I determine the original name from the expected name using Ferret
> language in the initialization script, if it is possible at all ?
>
> If I have been clear enough and you understand my problem, please, could
> you suggest to me some way to solve it ?
>
> Some ideas:
>  - if instead of an initialization script, we had an initialization
> template, things would be easier, wouldn't they ?
The perl templates allow you to do all kinds of things that are 
difficult to do in Ferret jnl scripts.  This would be a very good way to 
use perl pattern matching on an incoming variable name.

>  - I designed also the following scheme: I programmed a preExecuteHook
> function that executes a Ferret script for each requested variable
>      that script replaces the initialisation script
This will no doubt work but it seems a bit extreme for what you want to 
do.  Let me propose another solution:

If you have a whole bunch of variables that all need to be regridded you 
can do all of that work in a single initialization script where every 
variable hard coded rather than passed in as an argument.  This will 
require you to modify the names in your dataset configuration file 
(.xml) to match the variables being defined in your initialization 
script.  This is useful if your suite of variables is unlikely to change 
very often.  An example can be seen here:

http://ferret.pmel.noaa.gov/LAS_jnlFiles/jpl_atlas_ssmi.jnl


> 2)  Second problem:
>
> Let's suppose that two variables have the same name in two different
> datasets and I want to compare them.
> My initialization script will be called twice with the same variable
> name as an input parameter...
> And there will be a name conflict when it will be called the second
> time:
>    let $1 = expression ($1_)
>    will supersede previous definition of $1
>
> Please, tell me if  there is a way to work around this ?
>
> Some ideas:
> - I am obliged to stick with the variable name expected by LAS since
> the Perl code refers to it directly when comparing two variables.
>  line 1242 of Ferret.pl:        $self->command("let var1_ =
> $full_expr1");
> It would be easier to deal with variable names if LAS only called
> Ferret scripts or templates instead of directly sending instructions to
> Ferret process.
>
> - the key is: it would be OK if Ferret.pl referred to a Ferret symbol
> initialized with variable name instead of referring to the variable name
> itself.
I agree that this is a problem the way the code is currently 
implemented.  There is no easy workaround at the moment though I can 
reassure you that the issues you bring up are high on the priority 
list.  We have begun a major overhaul of the Ferret.pl 'driver' and the 
scripts it runs so as to better accommodate multiple variables.  The 
version of LAS we hope to get out this summer should also have a 
completely different and much more robust method for data comparison.

So I cannot solve this problem for you right now but I can honestly say 
that we are working on it.

All the best for a productive and enjoyable 2005.


-- Jon