Opened 16 years ago

Closed 16 years ago

#183 closed bug (Fixed)

Corrections to read_FloatsPar in inp_par.F

Reported by: m.hadfield Owned by: arango
Priority: major Milestone: Release ROMS/TOMS 3.2
Component: Nonlinear Version: 3.2
Keywords: Cc:

Description (last modified by arango)

The following addresses bounds-checking failures for the LAKE_SIGNELL case.

Subroutine read_FloatsPar in ROMS/Utility/inp_par.F reads data from the floats parameter file into local, allocatable variables Fcoor, Fcount, Ftype, Ft0, Fx0, Fy0, Fz0, Fdt, Fdx, Fdy and Fdz. Data is then copied from these variables into the structure variable FLT(ng).

The variables in question are allocated as follows (lines 7208-7218)

            allocate ( Fcoor (Npts,Ngrids) )
            allocate ( Fcount(Npts,Ngrids) )
            allocate ( Ftype (Npts,Ngrids) )
            allocate ( Ft0(Npts,Ngrids) )
            allocate ( Fx0(Npts,Ngrids) )
            allocate ( Fy0(Npts,Ngrids) )
            allocate ( Fz0(Npts,Ngrids) )
            allocate ( Fdt(Npts,Ngrids) )
            allocate ( Fdx(Npts,Ngrids) )
            allocate ( Fdy(Npts,Ngrids) )
            allocate ( Fdz(Npts,Ngrids) )

where Npts is equal to the maximum number of floats.

In fact, the first dimension of these variables does not have to be large enough to accommodate the number of floats, but only to accommodate the number of entries in the floats data file. It is assumed, obviously, that the latter can be be greater than the former. This assumption is normally very conservative, except that it does not allow for the fact that when the entries in the floats file are read, one extra entry is always read to trigger the ERR= or END= condition in the READ statement.

The floats data file for the LAKE_SIGNELL test case sets NFLOATS=4 and then has 4 entries sspecifying initial locations, with 1 float per entry. This cause the READ statement to be executed 5 times. If compiler bounds-checking is turned on, then the 5th time it is executed, there are out-of-bounds references to the arrays being read.

The solution is to increase the first dimension of these variables by 1:

            allocate ( Fcoor (Npts+1,Ngrids) )
            allocate ( Fcount(Npts+1,Ngrids) )
            allocate ( Ftype (Npts+1,Ngrids) )
            allocate ( Ft0(Npts+1,Ngrids) )
            allocate ( Fx0(Npts+1,Ngrids) )
            allocate ( Fy0(Npts+1,Ngrids) )
            allocate ( Fz0(Npts+1,Ngrids) )
            allocate ( Fdt(Npts+1,Ngrids) )
            allocate ( Fdx(Npts+1,Ngrids) )
            allocate ( Fdy(Npts+1,Ngrids) )
            allocate ( Fdz(Npts+1,Ngrids) )

Corrected file attached.

Change History (2)

comment:1 by m.hadfield, 16 years ago

Corrected file was not attached, because it was too big. But changes are limited to the lines shown above.

comment:2 by arango, 16 years ago

Description: modified (diff)
Resolution: Fixed
Status: newclosed

Yes, I also notice this one. This seems to be a compiler dependent problem. I found this problem when compiling with gfortran. I did the fix by redefining Npts as:

    Npts=Nfloats(1)+1

I will provably revise this in the future to

    Npts=MAXVAL(Nfloats)+1

for nested grid considerations. I have to think more about it. Thank you for reporting this problem. This issue was fixed in src:ticket:184

Note: See TracTickets for help on using tickets.