Reduce dimensionality of working arrays in ZDF
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
)
- Replaced 2 3D (i,j,k) working arrays (
-
zdfgls.F90
- Renamed all local working arrays that did not conform to the variable naming conventions
- e.g.
prod
=>zprod
- e.g.
- 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
- These are not used outside of
- 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
- Renamed all local working arrays that did not conform to the variable naming conventions
-
zdfmfc.F90
- Removed
diag_mfc
andrhs_mfc
subroutines- As of 16443a0b, these are no longer being used by
tra_zdf
. Instead, the code from these subroutines is executed directly intra_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 intozdf_mfc
- As of 16443a0b, these are no longer being used by
- Removed 3 module-level arrays (
edmf[abc]
)- With the removal of
diag_mfc
, these are no longer used
- With the removal of
- 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 arrayzwrk
- The second use of
zedmf
(to calculate the mass flux at W-levels) has been replaced by re-usingedmfm
-
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 ofedmfm(ji,jj,jk)
andedmfm(ji,jj,jk-1)
-
-
zn2
was not used - The 2D arrays were removed either by inlining the calculations or by using
zwrk
instead
- The first use of
- 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
- Removed
-
zdfric.F90
- Converted the 2D (i,j) working array from automatic to allocatable
- This only needs to be declared when
ln_mldw = .TRUE.
- This only needs to be declared when
- Converted the 2D (i,j) working array from automatic to allocatable
-
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 arrayz_pdlr
- This only needs to be declared when
nn_pdl = 1
and is not used outside ofzdftke.F90
- This only needs to be declared when
- 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 ofkey_vco_1d3d
-
~40% reduction in
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