+Gracefully handle longer input parameter lines #89
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
Added the ability to detect and handle multiline parameter specifications that are longer than INPUT_STR_LENGTH after the lines have been concatenated. Many instances where character strings are set to length INPUT_STR_LENGTH are replaced by param_file_type%max_line_len. This commit partially addresses MOM6 issue mom-ocean#75. All answers and output are bitwise identical in cases that worked previously, but there is a new element in the publicly visible param_file_type, and some cases where there had previously been errors due to very long input specification may now work.
Make the lines of the param_file_type individually allocatable to support arbitrarily long input lines. This required the introduction of a new private type to hold the actual allocatable array, so the lines are now an array of this type. All answers are bitwise identical.
Use a character buffer to minimize the memory footprint associated with reading the input parameters on root_PE and broadcasting it to all PEs. All answers are bitwise identical.
Now that INPUT_STR_LENGTH is only used as the size of a single temporary character string, the maximum permitted line length can be increased to a larger value without unduly impacting the memory footprint of the model, so it has been increased to 1024. If this is not large enough, considering that MOM6 also supports line continuation, there is a bigger problem than this limit. Some message strings were also changed to be allocatable, while others have sizes that are set using param_file_type%max_line_len. Also eliminated the hard-coded internal parameter all_PEs_read, which had a note that it should have been eliminated in about 2010 (before MOM6 existed). All answers and output are bitwise identical.
|
Thanks for working on this. I tried out the PR with my full Northwest Atlantic setup and can confirm it works as expected. |
marshallward
approved these changes
Mar 25, 2022
Codecov Report
@@ Coverage Diff @@
## dev/gfdl #89 +/- ##
============================================
+ Coverage 28.99% 29.02% +0.03%
============================================
Files 245 245
Lines 72177 72223 +46
============================================
+ Hits 20925 20962 +37
- Misses 51252 51261 +9
Continue to review full report at Codecov.
|
|
Gaea regression: https://gitlab.gfdl.noaa.gov/ogrp/MOM6/-/pipelines/15064 ✔️ |
This was referenced May 16, 2022
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.
This PR is a series of commits that will enable to MOM6 to handle much longer
input parameter lines, of up to 1000 characters in a single line, and with no
limit for lines with continuation. This required the addition of a new internal
function and type, but all changes are private to the MOM_file_parser module.
This PR addresses the problems noted in MOM6 issue #75, which can be closed once
this PR is accepted. All answers and output are bitwise identical in any cases
that worked before.
The commits in this PR include: