Custom Query (964 matches)

Corrected few bug to the major upgrade in ​src:ticket:263

• Corrected ad_convolution.F at line 764: the END IF needs to be before the endif CPP token.
• Corrected CPP directive in tl_convolution.F at line 755.
• Corrected reporting of NLpenalty in w4dpsas_ocean.h.
• Changed model flag from iRPM to iNLM in obs_cost.F during the computation of NLpenalty in the W4DPSAS algorithm.
• Corrected the computation of minimum and maximum tile fractional coordinates used to process the observations. Added new routine get_domain in get_bounds.F to facilitate the computation of such values. Notice that different ranges are computed for FULL_GRID option wich includes interior and boundary points. Also, mod_ncparam.F was modified to compute such values. It still have activated the incorrect computation.
• Fixed few problems in inp_par.F when reporting HdecayF. I Also removed the MPI reduction to the DOMAIN(ng) structure. It is not longer needed.
• Corrected few typos in the internal documentation.

Many thanks to Gregoire Broquet for reporting some of these problems.

When DISTRIBUTE and INLINE_2DIO are defined (which normally happens only on the UNICOS_SN platform) there is a misalignment problem when 3D u-grid variables are written to a netCDF file: successive rows of data are out of step by 1, leading to a skewing of the fields. The same error occurs (I think) when data are read from a restart file.

I have traced this to functions mp_gather2d and mp_scatter2d in distribute.F. These have code to adjust the offset for U and V grids:

      IF ((MyType.eq.p2dvar).or.(MyType.eq.u2dvar)) Io=1
      IF ((MyType.eq.p2dvar).or.(MyType.eq.v2dvar)) Jo=1

However this doesn't anticipate the possibility that mp_gather2d and mp_scatter2d will be called for 3D variables, as happens when INLINE_2DIO is defined. To cover this case, the code should be changed to the following

      IF ((MyType.eq.p2dvar).or.(MyType.eq.u2dvar).or.                  &
     &    (MyType.eq.p3dvar).or.(MyType.eq.u3dvar)) Io=1
      IF ((MyType.eq.p2dvar).or.(MyType.eq.v2dvar).or.                  &
     &    (MyType.eq.p3dvar).or.(MyType.eq.v3dvar)) Jo=1

A modified version of distribute.F is attached.

The recent IO updates appear to have broken a tidally-forced application of mine. The tidal period and parameters (elevation amplitude, etc) are not being read from the file, as illustrated by the following output:

    GET_NGFLD   - tidal period
                   (Min =  3.11285267-303 Max =  3.11285267-303)
    GET_2DFLD   - tidal elevation amplitude
                   (Min =  1.00000000E+37 Max = -1.00000000E+37)
    GET_2DFLD   - tidal elevation phase angle
                   (Min =  1.00000000E+37 Max = -1.00000000E+37)

The problem seems to be that in ROMS/Nonlinear/get_idata.F at line 101, NTC(ng) (i.e. the number of tidal consttituents) is set to 0

      IF (iic(ng).eq.0) THEN
        NTC(ng)=0
        CALL get_ngfld (ng, iNLM, idTper, ncFRCid(idTper,ng),           &
     &                  nFfiles(ng), FRCname(1,ng), update(1),          &
     &                  1, MTC, 1, 1, 1, NTC(ng), 1,                    &
     &                  TIDES(ng) % Tperiod(1))
#  if defined AVERAGES_DETIDE && (defined SSH_TIDES || defined UV_TIDES)
        TIDEname(ng)=TRIM(ncfile)
#  endif
      END IF

and it never acquires any other value. (In my application it should be 1.) Therefore all the subsequent read requests return 0 data values.

As an ad hoc fix, setting NTC(ng) to 1 in get_idata.F causes sensible tidal forcing data to be read from the file

    GET_NGFLD   - tidal period
                   (Min =  4.47141632E+04 Max =  4.47141632E+04)
    GET_2DFLD   - tidal elevation amplitude
                   (Min =  9.37254056E-02 Max =  1.37402248E+00)
    GET_2DFLD   - tidal elevation phase angle
                   (Min =  2.47094957E+00 Max =  5.79200999E+00)

I don't know how NTC(ng) should get its value, however.