Custom Query (964 matches)
Results (127 - 129 of 964)
Ticket | Owner | Reporter | Resolution | Summary |
---|---|---|---|---|
#181 | Fixed | SWAN coupling mpi_finalize | ||
Description |
for the SWAN coupling, the call mpi_finalize is now located at the bottom of Master/mct_coupler.h Here is the problem: It is not clear which model will get there first. Typically this will be ROMS. However, SWAN needs time to collect the contents of the individual output files and conglomerate them into single output files (don't ask me why SWAN does this, it is just the way it is). But if ROMS goes thru it's finalize step, then calls mpi_finalize, well that is bad news for the SWAN because it may not have finished pulling together the output. Suggested Solution: Place an mpi_barrier in mct_coupler.h before the call to mpi_finalize so that all processors from all models need to check in before finalize occurs. |
|||
#182 | Fixed | Incorrect FORMAT statement number in def_floats.F | ||
Description |
In ROMS/Utility/def_floats.F, line 334 WRITE (Vinfo(19),20) 1000.0_r8*Sd50(i,ng) should be WRITE (Vinfo(19),40) 1000.0_r8*Sd50(i,ng) Corrected file attached. |
|||
#183 | Fixed | Corrections to read_FloatsPar in inp_par.F | ||
Description |
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. |