Incorrect @DIN, if the definite integral does not cross a coordinate edge

[AndrewWittenberg]

Definite Integrals that don't cross at least one coordinate edge are incorrect in Ferret v7.63. This may be related to #1880.

First define a 2-cell axis:

   NOAA/PMEL TMAP
   FERRET v7.63 (optimized)
   Linux 3.10.0-1160.25.1.el7.x86_64 64-bit - 08/25/21
   30-May-23 16:45     

yes? def ax/x=0:4:2/edges/unit="m" xax  ! edges at {0,2,4}; coordinates at {1,3}
yes? let one = 1 + 0*x[gx=xax]
yes? sho grid/x x[gx=xax]
... 
       I     X                       XBOX          XBOXLO
       1>  1                         2          0
       2>  3                         2          2

Integrals that cross at least one cell edge are ok:

yes? list/noh one[x=1.9:2.1@din]  ! 0.2 (correct)
          0.2000
yes? list/noh one[x=0.1:2.2@din]  ! 2.1 (correct)
          2.100
yes? list/noh one[x=1.1:4.2@din]  ! 2.9 (correct; integral correctly stops at x=4.0)
          2.900

Integrals that DON'T cross at least one cell edge are incorrect. This includes integrals that include, but don't cross, an edge.

yes? list/noh one[x=1.9:1.9@din]  ! 2.0 (INCORRECT, should be 0)
          2.000
yes? list/noh one[x=2.0:2.0@din]  ! 2.0 (INCORRECT, should be 0)
          2.000
yes? list/noh one[x=2.1:2.1@din]  ! 2.0 (INCORRECT, should be 0)
          2.000
yes? list/noh one[x=1.9:2.0@din]  ! 2.0 (INCORRECT, should be 0.1)
          2.000
yes? list/noh one[x=2.0:2.1@din]  ! 2.0 (INCORRECT, should be 0.1)
          2.000
yes? list/noh one[x=0.0:1.9@din]  ! 2.0 (INCORRECT, should be 1.9)
          2.000
yes? list/noh one[x=2.1:3.9@din]  ! 2.0 (INCORRECT, should be 1.8)
          2.000
yes? list/noh one[x=2.1:4.0@din]  ! 2.0 (INCORRECT, should be 1.9)
          2.000

It also applies to integrals that extend past the valid domain, so that the outermost edge is reached but not crossed:

yes? list/noh one[x=-0.2:1.9@din] ! 2.0 (INCORRECT, should be 1.9, stopping at x=0)
          2.000
yes? list/noh one[x=2.1:4.2@din]  ! 2.0 (INCORRECT, should be 1.9, stopping at x=4)
          2.000

I'm not sure if this affects averages (@AVE) as well -- do they depend on @DIN?

[seasage]

@AndrewWittenberg Thanks for reporting this issue. It does seem that the fractional weighting, or related logic, isn't being executed, hence this 'snap to grid' kind of behavior. It's possible this impacts other transformations that rely on the same grid-handling routines, but it does seem like @AVE gives incorrect results where @DIN does and, conversely, where @DIN is correct so is @AVE.

yes? let lin = 1 + x[gx=xax]
yes? list/noh lin[x=0.1:2.1@din] ! CORRECT
          4.200
yes? list/noh lin[x=0.1:2.1@ave]
          2.100
yes? list/noh lin[x=2.0:2.0@din] ! INCORRECT
          4.000
yes? list/noh lin[x=2.0:2.0@ave]
          2.000

I'll have a look into these routines.

[seasage]

For posterity, it's worth mentioning that the fixes applied to #1981 and #1880 are still working per v7.63.

[ACManke]

This is the issue reported as PyFerret issue 91, which has been resolved. That update is now in the main PyFerret code base.