SET MODE INTERPOLATE fails to update cached results

[karlmsmith]

Reported by @AndrewWittenberg on 15 Apr 2015 20:30 UTC

    NOAA/PMEL TMAP
    FERRET v6.941 (PyFerret 1.2)
    Linux 2.6.32-504.8.1.el6.x86_64 - 04/07/15
    15-Apr-15 16:25     

yes? use coads_climatology
yes? let yval = y[gy=sst]
yes? let y0 = yval[y=0]
yes? list/nohead y0
         -1.000
yes? set mode interp
yes? list/nohead y0
         -1.000

Note how the value didn't update. If we simply redefine the variable (with an identical definition), we get the update:

yes? let y0 = yval[y=0]
yes? list/nohead y0
          0.0000

And then we see a similar issue when canceling the mode:

yes? can mode interp
yes? list/nohead y0
          0.0000

Presumably this is because Ferret is re-using cached results, without checking whether the mode has changed.

Migrated-From: http://dunkel.pmel.noaa.gov/trac/ferret/ticket/2272

[karlmsmith]

Comment by steven.c.hankin on 16 Apr 2015 00:53 UTC If we do the same but omit the /nohead we get a little further insight

use coads_climatology
let yval = y[gy=sst]
let y0 = yval[y=0]
list y0
             VARIABLE : YVAL[Y=0]
             FILENAME : coads_climatology.cdf
             FILEPATH : /home/users/tmap/ferret/linux/fer_dsets/data/
             LATITUDE : 1S
         -1.000
yes? set mode interp
yes? list y0
             VARIABLE : YVAL[Y=0]
             FILENAME : coads_climatology.cdf
             FILEPATH : /home/users/tmap/ferret/linux/fer_dsets/data/
             LATITUDE : 1S
         -1.000

Note that the LIST command when mode interpolate is active indicates that the latitude is 1S, instead of the interpolated location, 0.0.

The problem seems to be that when a cache hit occurs (FIND_MEM_VAR), it causes Ferret to bypass the STRIP of @ITP. It is all laid bare by running this script:

set mode diag
use coads_climatology
let yval = y[gy=sst]
let y0 = yval[y=0]
load y0
set mode interp
! see how it finds y0 in cache
list y0

cancel memory/all
list y0