"unexpected modulo jump" on modulo regridding

[karlmsmith]

Reported by @AndrewWittenberg on 12 Aug 2011 17:40 UTC
We get an "internal error" due to an "unexpected modulo jump" if we try to modulo regrid a variable that uses a time average with unspecified limits.

        NOAA/PMEL TMAP
        FERRET v6.71  
        Linux 2.6.18-274.el5PAE 32-bit - 08/05/11
        12-Aug-11 13:26     

yes? use climatological_axes.cdf
yes? use monthly_navy_winds
yes? let anom = uwnd[t=@sbx:12] - uwnd[t=`@ave`]
yes? let anom_var = anom[gt=month_gregorian`@modvar`]

! this gives a strange note
yes? shade/y=0 anom_var[l=1:24]
 *** NOTE: Internal: unexpected modulo jump!

! but this doesn't
yes? let anom = uwnd[t=@sbx:12] - uwnd[l=1:132`@ave`]
yes? shade/y=0 anom_var[l=1:24]

The question is: should we get such a note in the first case? (The operation should be well defined.) And if so, can this note be made more informative?

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

[karlmsmith]

Comment by @AnsleyManke on 22 Aug 2011 22:07 UTC
(Note that this is not new behavior.)

There are internal differences in order of reconciling the context of the expressions that trigger this "note". I think it is probably not necessary to issue it. It occurs when the destination axis is modulo and the request is to compute data on a region that's more than the modulo length of the axis, and there is a pseudo-variable or unresolved length of a region - in this case the T=@ave.

Running Ferret with mode diagnostic turned on, in the first case that does give the note, it's on a call to get the context of anom_var, and we see that the limit are L=1:24

...
 strip limits reconciliation : EX#1
 eval    EX#1     C:  5 I:    1  144  J:   37   37  K: -999 -999  L: -999 -999
 eval    ANOM_VAR C:  7 I:    1  144  J:   37   37  K: -999 -999  L:    1   24
 allocate dynamic grid (G002)          FNOCX     FNOCY     NORMAL    MONTH_GREG
 *** NOTE: Internal: unexpected modulo jump!

In the second example where anom was defined with the explicit limits L=1:32@ave, the same piece of processing asks for anom_var over L=1:12.

...
 strip limits reconciliation : EX#1
 eval    EX#1     C:  5 I:    1  144  J:   37   37  K: -999 -999  L: -999 -999
 strip moduloing ANOM_VAR on T axis:     1    24
 eval    ANOM_VAR C:  9 I:    1  144  J:   37   37  K: -999 -999  L:    1   12
 allocate dynamic grid (G002)          FNOCX     FNOCY     NORMAL    MONTH_GREG

Here are the comments in the code: fer/stk/is_strip.F

* possible "kludge" jump point to switch from regridding to modulo
* Note that this kludge is not actually used because adequate testing is
* now (1/9/96) done in INTERP_STACK -- still retain this documentation here
* to explain the subtleties:
* This is needed to cover a subtlety that arises when pseudo-variables are
* combined with modulo operations. For the expression "A=TEMP-TEMP+I" we would
* like "I" to run from 1 to infinity -- not to modulo wrap at Nx
* (see uvar_mod_pseudo in INTERP_STACK). For this reason modulo operations are
* deferred on LET variables that contain pseudo-variables -- the modulo op
* is performed separately on each of the components in the LET variable
* definition allowing "I" to be evaluated on the full requested range.
* The present "kludge" is to cope with LIST/I=1:BIG A[GI=@MOD]. What the user
* presumably wants is to apply the I=1:BIG to the result of the GI=@MOD. So
* in this case we will NOT defer the modulo -- we will set up the stack to do
* the modulo right now.
* the modulo right now.
 6000   aclass = isact_class_modulo
	CALL WARN('Internal: unexpected modulo jump!')
	modulo_dest_regrid = .TRUE.

It seems to me that there is no real potential source of error here -- Steve, your opinion?

[karlmsmith]

Comment by @AndrewWittenberg on 14 Mar 2014 21:03 UTC
This appears to be fixed as of v6.86 (dated 2/25/14). Before resolving this ticket, it'd be good to document where/when the fix occurred.