Reproducibility using enveloping bathymetry

[jamesharle]

Currently in the iterative loop on ln 1173 of domzgr.F90 (R3909 trunk) the land points are included in the bathymetric smoothing. This may not be an issue if a square processor map domain is retained i.e. jpni*jpnj = jpnij. However, if jpni*jpnj >jpnij then the number of land cells that participate in the smoothing could vary depending on the jpni and jpnj chosen. An example of the AMM12 domain is shown in the attached pdf + a full summary of the issues.

[jamesharle]

Summary of enveloping bathymetry issue + solution

[jamesharle]

bugfix done in r3926
tested for hbatt and mbathy reproducibility in AMM12 8x4, 4x8 and with removal of land processors.

[jamesharle]

Although this fix solves several of the issues, there still remains one problem to fix. A bug in the new code was also found to produce NaNs? when scaling factors are calculated. Ticket reopened and old code re-inserted.

[jchanut]

Why not assuming that we read enveloping bathymetry in a netcdf file (and move the computation in an external pre-processing program) ? This would at least be useful for Agrif in order to ensure bathymetry matching at open boundaries.

[rfurner]

Hi All,

Apologies for the confusion on this, its partly my fault.  James has come up with a new fix which entirely resolves the problem.  However, it requires new boundaries to be created for the AMM12 configuration.  In the interest of input clarity I thought it best to therefore add this bug fix as part of the merge, so the 3.5 Amm12 inputs remain valid for all of 3.5 and a new set of inputs will be available for 3.6. This isnt ideal from a developers perspective, but I think the alternative is so user unfriendly (having various inputs for different revisions of the same release) that its justified here...

I hope thats ok,

Rachel

[clevy]

Suppressing tickets opened on the trunk since more than 2 years... cleaning started!