Add DLND to moab coupler #6567
Merged
Add DLND to moab coupler #6567
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
use existing lnd_domain attribute in infodata we do not differentiate on coupler side if data land or not still need to send the proper land domain file
domain file is actually set, in shr_strdata_type%domainFile all the other data models use the first stream file for domain information land is the one that actually has that member set in the SDLND structure it is easier to get it from there, then from stream the domain file in regular land case is defined by fatmlndfrac file
iMOAB_ApplyScalarProjectionWeights is not used anymore all maps are done now with seq_map method, and there is only one instance of iMOAB_ApplyScalarProjectionWeights in E3SM using moab driver
only intel on chrysalis complained about it It could be a cause for trouble later on
|
vijaysm
reviewed
Aug 28, 2024
|
I tested this branch on different platforms, and chrysalis is working fine; gce, perlmutter, and my laptop (gnu compiler) all fail to compress the log files at the end. So the bug I saw earlier is not solved yet. Somehow, it worked on gce when I tested 2 weeks ago; needs more work |
compute rof lnd interaction only if rof_c2_lnd is true we were computing an unnecessary map always even if rof_c2_lnd is false (for most coupled cases it is true)
in case rof c2 lnd, we were not retrieving the the MPI group needed for comm graph computation, for same grid path we were retrieving it for intx only how come we never had samegrid land rof before ?
vijaysm
requested changes
Sep 11, 2024
vijaysm
approved these changes
Sep 18, 2024
rljacob
added a commit
that referenced
this pull request
Sep 20, 2024
Add data land capability for moab driver; case tested: --res r05_r05 --compset RMOSGPCC standard data moab model, mainly adapt from data ocean implementation major change: Initialize all factors set by MOAB area correction init routine to 1.0. It affects all models, but it seems that some values were not initialized for data land case. On chrysalis, with intel compiler, it actually complained about non initialized values when applying correction factors. The compressing file errors seen during development were caused by non-ascii characters in the log files. Those were caused by an uninitialized mapper, for which we were still creating a MOAB map. It was never used, it is fixed properly now, the moab map is not computed anymore. [BFB]
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.
Add data land capability for moab driver;
case tested: --res r05_r05 --compset RMOSGPCC
standard data moab model, mainly adapt from data ocean implementation
major change: Initialize all factors set by MOAB area correction init routine to 1.0. It affects all models,
but it seems that some values were not initialized for data land case.
On chrysalis, with intel compiler, it actually complained about non initialized values when applying correction factors.
The compressing file errors seen during development were caused by non-ascii characters in the log files.
Those were caused by an uninitialized mapper, for which we were still creating a MOAB map. It was never used,
it is fixed properly now, the moab map is not computed anymore.
[BFB]