Opened 15 years ago

Closed 15 years ago

#269 closed bug (Fixed)

Tidal forcing data not being read from forcing file

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 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.

Change History (1)

comment:1 by arango, 15 years ago

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

Yes, good catch! I fixed this logic in a more robust way by inquiring the number of tidal constituents for all nested grids in mod_tides.F. I cleaned get_idata.F to use the parallel interface of mod_netcdf.F. Similar logic is done in mod_sources.F to inquire the number of point sources Nsrc(ng) from input NetCDF file.

I also corrected a parallel bug in inp_par.F when either W4DVAR or W4DPSAS is activated. The nTLM(ng)=nHIS(ng) was inside of a code that it is only executed by the master thread. Many thanks to Brian Powell for reporting this problem.

Note: See TracTickets for help on using tickets.