Open karlmsmith opened 6 years ago
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?
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.
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.
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