add parallel-netcdf capability to speed up writing out FV3LAM final analysis #4
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
North American 3km Domain is very large, containing 3640x2520x65 grid points.
For this domain, GSI spends a substantial amount of time on the writing-out of the final analysis in NetCDF format. In Jet, this is roughly measured as 6~8 minutes depending the disk performance.
Add the parallel-netcdf capability for the writing part can save 3~4 minutes (also depending the disk performance). This may not be a big deal for research or retrospective GSI runs, but helps improve the overall turnaround time for Jet realtime RRFS runs.
I used NCL amd checked the differences between regular write and parallel-netcdf write. The max differences for different variables are as follows:
U/V: 8E-5
T: 3E-5
delp: 7E-4
q : 2E-7
These are small compared to their original values. The diff figure shows that these differences are more like random noise, not related to the parallel writing layout.
By default, use parallel netcdf writing. Otherwise, need to set npePgrp_rfv3=1 in gsiparm.anl.