Re: [ferret_users] INT showing strange values

[Andrew Wittenberg - NOAA Federal <andrew.wittenberg@xxxxxxxx>]

Hi Sulagna,

Per Ryo's helpful reminder: when asking questions it's best to send a self-contained example, say using one of Ferret's built-in datasets (in the $FER_DSETS path) like coads_climatology or levitus_climatology.  That way users can easily reproduce the issue themselves, and experiment to find a solution.  If the problem is with one of your own datasets, and you can't reproduce it with a built-in Ferret dataset, then you can first simplify your data file (e.g. extract a single time level, depth, and latitude), and then attach that vastly smaller NetCDF file to your email, or post it somewhere where users can access it.  Then users can download your tiny test-dataset and directly run the commands in your email to reproduce the problem.

In this case, the problem may be with the implied order of operations.  It appears that you have MODE INTERPOLATE on (which you can toggle with SET MODE INTERP and CAN MODE INTERP).  This tells Ferret that if you request any values that aren't exactly aligned with gridpoints, then Ferret should multilinearly interpolate to that point from the nearest available gridpoints.  But there's an ambiguity in the order of operations when using a function on the same evaluation line: do we first interpolate the value from the field, and then apply the function to that value? or do we apply the function to the field, and then interpolate the value of that new field?  Ferret's Mathematica-like delayed-mode evaluation is extremely powerful, fast, and flexible -- but it does require care in not leaving things ambiguous, as when applying nonlinear functions like int() where the order of operations matters.

So my guess is that for

list/y=49.50n/z=200 int(NB_DEG_LIB)

Ferret could be applying int() to the NB_DEG_LIB field, and then interpolating from that integer field to y=49.5 and z=200.  (Whereas your expectation had been that it'd first interpolate, and then truncate.)

If this is the case, then you can eliminate any ambiguity by explicitly stating the order of operations by defining one or more intermediate variables.  So the two alternatives would be:

! Option 1: interpolate, then truncate

let interp_vals = nb_deg_lib[y=49.5n,z=200]

list int(interp_vals)

! Option 2: truncate, then interpolate

let int_vals = int(nb_deg_lib)

list/y=49.5n/z=200 int_vals

Please let us know if this solves your problem.

Best,

Andrew

On Thu, Apr 8, 2021 at 9:07 AM Sulagna <sulagna.ray@xxxxxxxxx> wrote:

Thank you G Satyesh for suggesting an alternate way out. Appreciate it.

Ryo, I hope it is not a bug, and could be solved easily in ferret through some proper specifications. For example, taking only one point (say the first) in my earlier example, it gives the int (NB_DEG_LIB)  correctly if it is int(` NB_DEG_LIB`). i.e. when the user-defined variable is specified in grave accent. So this shows that int () works, but only in grave accents. However, when you use the grave accent for multiple points in the user-defined variable, it gives error.

yes? list/y=49.50n/z=200 NB_DEG_LIB
             VARIABLE : GDN * ( 1 - R1 * R2 ) / (1 + R1 * R2 )
             LATITUDE : 49.5N
             Z (m)    : 200 (interpolated)
             T        : 2
          20.48
yes? list/y=49.50n/z=200 int(NB_DEG_LIB)
             VARIABLE : INT(NB_DEG_LIB)
             LATITUDE : 49.5N
             Z (m)    : 200 (interpolated)
             T        : 2
          3.000
yes? list/y=49.50n/z=200 int(`NB_DEG_LIB`)
 !-> list/y=49.50n/z=200 int(20.48211426660225)
             VARIABLE : INT(20.48211426660225)
          20.00

But doing the above in multiple points :

yes? list/y=40n:50n/z=200 int(`NB_DEG_LIB`)
 **ERROR: invalid command: grave accent doesnt evaluate to scalar
          NB_DEG_LIB

So what would be an alternative way to specify  int(`NB_DEG_LIB`) in the above example?

Thanks for your help.

Best,

Sulagna

On Thu, Apr 8, 2021 at 2:22 AM Ryo Furue <furue@xxxxxxxxxx> wrote:

Dear Sulagna,

Does INT (X) (link) not work on user-defined variables?

It would be nice if you could send a complete (self-contained) example including datafiles if necessary and if they are not too large, so that anybody can reproduce your problem.  If it is a bug (which it looks like, to me), the Ferret developers may like to look at it.

Ryo

 

For example, the variable NB_DEG_LIB has the following values, of which I want to take the integer values, which is supposed to be the part before decimal. However you would see on using int(NB_DEG_LIB) it returns varied values. Am I missing something here? Or should I use something else?

list/y=40n:50n/z=200 NB_DEG_LIB

             VARIABLE : GDN * ( 1 - R1 * R2 ) / (1 + R1 * R2 )

             SUBSET   : 10 points (LATITUDE)

             Z (m)    : 200 (interpolated)

             T        : 2

 49.5N / 140:  20.48

 48.5N / 139:  22.48

 47.5N / 138:  26.17

 46.5N / 137:  29.68

 45.5N / 136:  32.43

 44.5N / 135:  30.92

 43.5N / 134:  32.55

 42.5N / 133:  32.13

 41.5N / 132:  33.28

 40.5N / 131:  32.28

list/y=40n:50n/z=200 int(NB_DEG_LIB)

             VARIABLE : INT(NB_DEG_LIB)

             SUBSET   : 10 points (LATITUDE)

             Z (m)    : 200 (interpolated)

             T        : 2

 49.5N / 140:   3.00

 48.5N / 139:   3.00

 47.5N / 138:   4.00

 46.5N / 137:   7.00

 45.5N / 136:   7.00

 44.5N / 135:  12.00

 43.5N / 134:  19.00

 42.5N / 133:  10.00

 41.5N / 132:   9.00

 40.5N / 131:  11.50

Thanks for your responses.

Best,

Sulagna