Skip to content

Resolve "Implement tiling in RK3 and expand tiling to `wzv`/`wAimp` in MLF"

Daley Calvert requested to merge 367-rk3-tiling into main

Closes #367 (closed).

Tests

Regular checks

  • Can this change be shown to produce expected impact (option activated)?
  • Can this change be shown to have a null impact (option not activated)?
  • Results of the required bit comparability tests been run: are there no differences when activating the development?
    • If some differences appear, is reason for the change valid/understood?
    • If some differences appear, is the impact as expected on model configurations?
  • Is this change expected to preserve all diagnostics?
    • If no, is reason for the change valid/understood?
      • 43ce6b87 will change the results of the uadv_heattr/vadv_heattr/uadv_salttr/vadv_salttr diagnostics in RK3
      • 43ce6b87 also enables dia_ar5 diagnostics in RK3- these will now show as valid data rather than missing data
  • Are there significant changes in run time/memory?

Note that 3241a771 will change the results for configurations using tiling and 3D BDY damping (bdy_tra_dmp/bdy_dyn3d_dmp)- SETTE does not use this latter functionality.

Other testing

Other testing was performed using 2-month runs of ORCA2_ICE_PISCES with passive tracers turned off, with and without SI3, with MLF and RK3 timestepping, and using many different namelist parameter settings and CPP keys. Only z partial steps (zps) vertical coordinates were tested.

The testing checked for restartability, tiling reproducibility (whether using tiling changes the results) and preservation of results with respect to the main. This was done by comparing the contents of run.stat files, as well as data from most available model diagnostics and from restart files.

Review

Assessments

  • Is the proposed methodology now implemented?
  • Are the code changes in agreement with the flowchart defined at preview step?
  • Are the code changes in agreement with list of routines and variables as proposed at preview step?
    • If, not, are the discrepancies acceptable?
  • Is the in-line documentation accurate and sufficient?
  • Do the code changes comply with NEMO coding standards?
  • Is the development documented with sufficient details for others to understand the impact of the change?
  • Is the project doc (manual, guide, web, ...) now updated or completed following the proposed summary in preview section?
Edited by Daley Calvert

Merge request reports