Skip to content

Reduce dimensionality of working arrays in ZDF

Daley Calvert requested to merge 234-ZDF-working-array-refactoring into main

Closes #234 (closed)

Summary of changes

  • trazdf.F90
    • Some cleanup of commented code
  • zdfddm.F90
    • All working arrays have been reduced from 2D (i,j) to scalar
  • zdfevd.F90
    • Replaced 2 3D (i,j,k) working arrays (zav[tm]_evd) with 1 (zav_evd)
  • zdfgls.F90
    • Renamed all local working arrays that did not conform to the variable naming conventions
      • e.g. prod => zprod
    • Reduced 10 3D (i,j,k) working arrays to 2D (i,k), 2 2D (i,j) working arrays to 1D (i), 3 2D (i,j) working arrays to scalar
    • Converted 4 module-level arrays to local working arrays and reduced them from 3D (i,j,k) to 2D (i,k), 2D (i,j) to 1D (i)
      • These are not used outside of zdfgls.F90
    • Loop order is now i-k-j instead of i-j-k
      • This is because the tridiagonal solver prohibits 2D slices over k; instead they have to be done over j
      • Some code was moved to avoid duplicate calculations
    • Some unnecessary calculations were removed
  • zdfmfc.F90
    • Removed diag_mfc and rhs_mfc subroutines
      • As of 16443a0b, these are no longer being used by tra_zdf. Instead, the code from these subroutines is executed directly in tra_zdf.
      • I've kept this approach- the commented out code in tra_zdf has been removed but I've kept the 'note' comments, some of which were moved into zdf_mfc
    • Removed 3 module-level arrays (edmf[abc])
      • With the removal of diag_mfc, these are no longer used
    • Removed 2 3D (i,j,k) working arrays (zedmf, zn2) and 10 2D (i,j) working arrays, and added 1 2D (i,j) working array (zwrk)
      • The first use of zedmf (to calculate the surface boundary condition of the mass flux) has been replaced by the 2D (i,j) working array zwrk
      • The second use of zedmf (to calculate the mass flux at W-levels) has been replaced by re-using edmfm
        • edmfm(ji,jj,jk) is calculated as the mass flux at W-levels
        • edmfm(ji,jj,jk-1) is then calculated as the mass flux at T-levels using the half-sum of edmfm(ji,jj,jk) and edmfm(ji,jj,jk-1)
      • zn2 was not used
      • The 2D arrays were removed either by inlining the calculations or by using zwrk instead
    • Reduced 1 4D (i,j,k,trc) working array to 3D (i,j,trc), 2 3D (i,j,k) working arrays to 2D (i,j), 1 3D (i,j,k) working array to scalar, 2 2D (i,j) working arrays to scalar
    • Some unnecessary calculations were removed
  • zdfric.F90
    • Converted the 2D (i,j) working array from automatic to allocatable
      • This only needs to be declared when ln_mldw = .TRUE.
  • zdftke.F90
    • Reduced 6 3D (i,j,k) working arrays to 2D (i,k), 5 2D (i,j) working arrays to 1D (i)
    • Loop order is now i-k-j instead of i-j-k
      • This is because the tridiagonal solver prohibits 2D slices over k; instead they have to be done over j
      • Some code was moved to avoid duplicate calculations
    • Converted module-level array apdlr to local working array z_pdlr
      • This only needs to be declared when nn_pdl = 1 and is not used outside of zdftke.F90
    • Some unnecessary calculations were removed

Testing and review

Tests

Once the development is done, the PI should complete the tests section below and after ask the reviewers to start their review.
This part should contain the detailed results of SETTE tests (restartability and reproducibility for each of the reference configuration) and detailed results of restartability and reproducibility when the option is activated on specified configurations used for this test.

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?
  • Are there significant changes in run time/memory?
    • ~40% reduction in zdf_tke runtime for ORCA025-L75
      • No reduction for ORCA2-L31
    • 25% - 50% reduction in zdf_gls runtime for ORCA025-L75
      • 15% - 35% reduction for ORCA2-L31
    • ~65% reduction in zdf_mfc runtime for ORCA025-L75
      • ~55% for ORCA2-L31
      • This only ran for RK3, MLF crashed with a grid point instability
      • MLF runs if key_vco_3d is used instead of key_vco_1d3d

Review

A successful review is needed to schedule the merge of this development into the future NEMO release during next Merge Party (usually in November).

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