Custom Query (986 matches)

There are couple of typos in nesting.F when deallocating Fmsk in fine2coarse2d and fine2coarse3d. We have:

#  ifdef MASKING
      IF (allocated(F)) THEN
        deallocate (Fmsk)
      END IF
#  endif

instead of

#  ifdef MASKING
      IF (allocated(Fmsk)) THEN
        deallocate (Fmsk)
      END IF
#  endif

This results in a memory leak in nesting applications with more than one refinement grid. It also depend on how compilers deal with local allocatable variables and their pointers. This may affect the land/sea masking when averaging fine grid solution into coarse grid.

Please update! Many thanks to John Warner for bringing to my attention.

There seems to be a problem when setting the time-stepping in multiple (more than one) telescoping grids. Recall that technically inside ROMS, a telescoping grid is a refined grid with RefineScale > 0 including another finer refined grid inside. For more information about telescoping grids check the ​following information in the forum.

The variable RefineStepsCounter in ntimestep.F need to be set to zero every time that the parent coarser grid steps for all of telescoped finer resolution children grids:

              ...
            ELSE IF (RefinedGrid(ng).and.(RefineScale(ng).gt.0)) THEN
              IF (step_counter(ng).le.(WindowSteps(ig)+1)) THEN
                IF (Telescoping(ng)) THEN
                  my_Nsteps(ig)=1
                  step_counter(ng)=step_counter(ng)+1
                  RefineStepsCounter(ng)=RefineStepsCounter(ng)+1
                  DO il=nl+1,NestLayers         ! When a parent steps,
                    gn=GridNumber(ig,il)        ! set all its telescoped
                    IF (Telescoping(gn)) THEN   ! children counters to
                      RefineStepsCounter(gn)=0  ! zero
                    END IF
                  END DO
                ELSE
                  my_Nsteps(ig)=RefineSteps(ng)
                  step_counter(ng)=step_counter(ng)+RefineSteps(ng)
                  RefineStepsCounter(ng)=RefineStepsCounter(ng)+        &
     &                                   RefineSteps(ng)
                END IF
              ELSE
                ...

Many thanks to John Warner for correcting this problem.

In nested applications, all the model arrays are made larger to include the additional contact points in the contact areas. See the following ​forum post for details (top figure showing contact areas and contact points).

In nesting applications, all the metrics arrays are initialized to spval, which is a very large value. This is very important since it is the only mechanism that we have to check if all the values for the metric arrays were fill correctly at the contact points. Their values are computed in the Matlab script contact.m. They are read in ROMS from input NGCNAME NetCDF file.

In routine metrics.F, we call subroutine fill_contact and use the spval_check to check if all the contact points values where properly assigned. If not, it will stop computations and issue an appropriate error message. There is no other way in the current nesting design to check for this. This is extremely important!

However in routine initialize_grid of module mod_grid.F, we have the following statements:

!
!  Set initialization value that it is special in nexting to just
!  load contact points that have not been initialized from the
!  regular physical grid. This is done to make sure that all these
!  important metric values have been set-up correctly.
!
#ifdef NESTING
      IniMetricVal=spval                   ! very large value
      IniMetricVal=IniVal
#else
      IniMetricVal=IniVal
#endif

Obviously, this is typo since IniMetricVal is still zero in nesting applications. I don't know were the second reassignment comes from. It should not affected any nested application but it is a good idea to have this safeguard in case that an user changes the input contact NetCDF file. We need to have instead:

#ifdef NESTING
      IniMetricVal=spval                   ! very large value
#else
      IniMetricVal=IniVal
#endif

Many thanks to Tarandeep Kalra and John Warner for bringing this to my attention.