remove unneeded fields for dev/ufs-weather-model #1317
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
* remove wav_grdout routine, now moved into wav_history_mod
* remove more cap stuff from w3iorsmd. only ww3 native filenaming is possible w/ binary restarts * remove ifdef w3_ascii from w3wavemd, since the ascii commit is not yet present in mesh cap branch * clean up config variable logic for filenaming
* nrqrs can be non-zero if also using the restart from binary option
* flpart needs to be set for either historync or not
* move restart and history nc blocks outside of ww3 time testing block. * add log print messages for reading and writing restarts
* get logging working correctly for ufs * fix noclobber variable and file name in wav_history * clarify some comments
* make binary history files match when restartnc=true * rework wav_restart_mod, which originally was designed to be able to read and write restarts for testing purposes from inside wav_comp_nuopc.
* verboselog is true by default, but can be set false by config * the header text for ww3 logging as it steps through time is now turned off in w3init and placed into the mesh cap. this allows the mesh cap to order the logging correctly
* move block where addrstflds was set to before call to w3init since restarts are read in w3init * ensure that if nml file lacks a specification of extra fields, the default value of "unset" will not be returned as a field name
* only ice is added for now * tab cleanup in w3grid
* need to send explicit array bounds for ice array since it is 0:nsea * all baselines b4b against f9531d0
* intialize floutg and floutg2 which are can be unintialized when waves are in slow loop and historync is true
* local arrays dimension nx or greater are locally allocated * deallocations added, even though not required for user clarity
…o feature/pio4ww3
* global_input and _output can be allocatable
* tested by using nco to alter the nth,nk values in a restart file. The model correctly aborted after finding nth did not match the expected value
* delay the deallocation of gindex arrays until after the diagnose_mesh routine is called. This only impacts cases where dbug_flag>5, compiled with gnu+debug
* minimally allocate fields used in w3updtmd when using cmeps * use fields provided by cmeps w/o fake time-interpolation
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Pull Request Summary
Removes un-needed allocations and time-interpolation of import fields when CMEPS is used. Note this PR is built on top of the PIO PR. Changes are minimal when compared to that PR.
Description
Introduces a logical flag (
use_cmeps) which is false by default. When true, arrays that are not needed at the global domain resolution are minimally allocated and time-interpolation w/in the update routines is skipped.To test the impact, three cases were run using the same DATM-S2SW configuration used for testing the PIO work on Gaea. Each case was run out 48 hours on 816 WAV tasks, with WW3 restarts written every 2 hours.
The
ProfileMemoryconfiguration flag was turned on and memory statistics for the WW3 PETs were pulled out for every 50th PE (18 total traces). Three values were plotted:VmPeak,VmRSSandCommittedPercent. The first is the max resident size, the second is the mean resident size and the third is (as defined here) an interesting number I happened to notice in the output. I'm not sure of this last value, but it seems relevant---for example, if I use too few tasks for WAV, the model crashes and I also see values likeCommittedPercent: 166.939 %.Each of the following figures show the current dev/ufs-weather-model branch (top), the feature/pio4ww3 branch (middle) and this feature branch (bottom):
VmPeak:
VmRss:
Note here that the highest trace on the top figure shows the values for the last (
naprst) PET.CommittedPercent:
Note here that the lowest trace on all figures is the first PET.
My interpretation of these results is that a) the PIO feature itself reduces memory usage by reducing the high-memory cost of the
naprsttask and b) this feature has a measurable impact on the memory footprint of the model. However, no consistent impact on model execution time was found in my limited testing.Issue(s) addressed
Commit Message
Check list
Testing
I ran this PR against a baseline created with PR #1303. All baselines passed.