bug in restoring coefs when zoom is active?

[clevy]

I'm setting up the new ORCA1 for CMIP6 configuration, envisaged for now with zoom functionality active (jpizoom, jpjzoom in namelist).

Christian drew my attention on the specifics of zoom (lzoom=.true.)in NEMO. I had a look at : grep -r lzoom ./NEMO
It seems that the code takes in account the zoom and the possible new closed boundaries created by the zoom properly, setting lzoom_e, lzoom_w, lzoom_s, lzoom_n

Afterwards, adjusts the restoring coefficients for damping with the following sequence:
in tradmp.F90, end of tra_dmp_init:

!                          ! Damping coefficients initialization
         IF( lzoom .AND. .NOT. lk_c1d ) THEN   ;   CALL dtacof_zoom( resto )
         ELSE               ;   CALL dtacof( nn_hdmp, rn_surf, rn_bot, rn_dep, nn_file, 'TRA', resto )
         ENDIF

Which I understand as :
if lzoom=.TRUE. CALL dtacof_zoom which only adjusts restoring coefs. on possible new closed boundaries created by zoom
otherwise, CALL dtacof to compute restoring coef.

I do not understand this sequence since I would have expected something like 1/ CALL dtacof to compute all restoring coefs. and 2/ adjust those at new closed boundaries if needed, i.e.

 !                          ! Damping coefficients initialization
         CALL dtacof( nn_hdmp, rn_surf, rn_bot, rn_dep, nn_file, 'TRA', resto )
         IF( lzoom .AND. .NOT. lk_c1d )   CALL dtacof_zoom( resto )

Same sequence appears in TRP/trcdmp et C1D/dyndmp
Did you use the zoom elsewhere than with C1D before?
Any advice on my possible misunderstanding?

[timgraham]

Hi Claire,

I think you're right about this behaviour. It's not currently possible to use damping across the domain and then a specific value at the closed boundaries.

Last year I completed a development to make this routine read the restoration coefficient from a netcdf file and an offline tool to create the file. This would allow the user to have a damping coefficient across the domain with modifications at the local boundaries. This wasn't merged because I didn't think it was needed for CMIP6 but it wouldn't be difficult to merge if you think it should be.

There are lots of other issues with the tradmp routine. For example, it's not possible to apply damping globally (only poleward of a specified non-zero latitude), it doesn't work for ORCA025 and there are lots of hard coded settings for other resolutions.

Having said that the user guide does make it clear that the code is provided as an example for users and should be modified for use on other resolutions:
"An example of the computation of γ for a robust diagnostic experiment with
the ORCA2 model is provided in the tradmp.F90 module (subroutines dtacof and
cofdis which compute the coefficient and the distance to the bathymetry, respecti-
vely). These routines are provided as examples and can be customised by the user."

I'll leave it up to you to decide if you want me to merge my branch in (it has been reviewed). I think if you just try to fix this issue in the subroutine as it is you will find there are lots more that should be fixed.

[clevy]

Hi Tim,

Decision is yes, of course!: taking out these horrible parts of the code and replacing them by a NETCDF file is a very good idea, which might as well be used for some experiments around CMIP6, and in all cases, is the kind of changes we expect for simplification and robstness of the code

[timgraham]

This has been resolved by merging a development branch into the trunk at r5102 (branches/2014/dev_r4650_masked_damping). Ticket #1296 (and associated wiki tickets) provide more information on this branch.

This requires an update to ORCA2_LIM_v3.6.tar to include resto.nc.