Issue459 oasis ocean coupling #641
Draft
Conversation
This file contains hidden or 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
Define a new IOceanBoundary derived module for the OASIS ocean coupling. I simply copied and renamed the ConstantOceanBoundary module. Next steps are to include the OASIS calls themselves.
It belongs there, but it doesn't look like m_couplingArrays is actively used.
setData should contain the initialisation calls, updateBefore the receive calls and updateAfter the send calls.
Adds a setMetadata function to PrognosticData, which passes ModelMedata to IAtmosphereBoundary and IOceanBoundary derived classes. This allows them to call OASIS functions to initialise the coupling. This can be done much better, but this commit acts a check-point, more than anything else.
All the communicator and partitioning calls are common to ocean, atmosphere, and wave coupling. So, I created OASISCoupled.hpp to keep those calls. OASISCoupledOcean (and others later) then inherits from this class and calls the parent class' setMetadata function in its own setMetadata call. The rest of the child's setMetdata function then takes care of the def_var and end_def calls
Only formatting changes.
We need to call oasis_c_terminate before MPI_Finalize is called. So, I put this in the destructor of OASISCoupled.hpp and make sure that the destructor of OASISCoupledOcean.hpp calls this. This should work, as the model object goes out of scope in main.cpp before MPI_Finalize is called.
But no actual code.
This adds functionality to find OASIS to cmake and some oasis calls to OASISCoupled.hpp. It compiles, but I haven't tested anything yet!
Move from all comments to actual code that compiles for the OASIS calls. We still don't have any passing of information to the ocean - this needs implementing. Most of the fields from the ocean to ice are implemented already, but we're missing ssh and we need special handling for mld (which is optional).
Something seems to have gone wrong in merge commit 1a155c9. Reverting the error makes testTOPAZOcn run again.
OASIS needs to know how many seconds have passed since the experiment started. I've added a simple internal counter for this, which is local to OASISCoupled.hpp.
No other changes
This uses std::map<std::string, int> to link the namcople strings and the values returned by oasis_c_def_var. Much better than what I had before!
There are now a lot of options to set, so that it's flexible what you put in the namcouple file.
I (optionally) pushed MLDKey to cplStringsIn before it could be redefined by the configuration system.
Member
Author
|
I set up this draft PR to help @andreapiacentini and me figure out how to get the OASIS coupling with NEMO working. There's still a good deal of work left ... |
Just so Andrea and Sophie see what I'm thinking
Just sorting out and gathering some output strings.
The OASIS calls, init_comp, get_localcomm, terminate, def_partition, and end_def can only be called once, so they must be moved out of the OASISCoupled class and it's children. This makes the program structure less nice, but I can't think of a better way to do it. It also leaves OASISCoupled with only OASISTime and updateOASISTime(), but I suppose that it's worth having anyway.
It's useful for testing.
More useful things like LD_LIBRARY_PATH and PYTHONPATH being automtically set.
This makes the CMakeLists.txt file look more standard and putts all essential functionality into FindOASIS.cmake. It would also catch the extremely unlikely case when some of the component libraries of OASIS are missing or in a different location from the rest. Also, a bit of reformatting.
Search for either psmile.MP1 or psmile.MPI2, pluss some clarifying comments.
But it still crashes because of a problem with the namcouple file.
It used to run with two MPI processes, but that's not right (even though it should technically work). I also added an "add_test" block.
NEMO sends the fraction of shortwave radiation absorbed in the first ocean layer. This is useful to have in a coupled context (probably for every ocean model), but by including it we also have to manually account for it in the stand-alone context (done now in TOPAZOcean.cpp).
Our traditional setup expects it to be called "I_sic", so we'll stick to that. Calling it "I_conc" was just a mistake anyway.
Split lines that were too long; ./physics/test/CMakeLists.txt ============================= ./physics/test/CMakeLists.txt:50: [C0301] Line too long (109/100) ./physics/test/CMakeLists.txt:51: [C0301] Line too long (107/100)
I had it on my disk, but didn't manage to commit it last time(!)
This too should have happened in a previous commit.
I needed to add FracQSWKey to the cplStringsIn list, and to initialise the fracQSWAbs variable (.resize()).
We were sending the full DG field to OASIS and NEMO didn't know what to do with that. So now, I only send the mean. This involves a copy, but I'm not sure if I can get around that.
NoOASISError is more descriptive than OASISError. The error message says OASIS was not compiled in.
Read in the azimuth angle from the restart file and use this to rotate the ocean velocity and ice-ocean stress vectors on receive and send, respectively. Also, clang-format auto changes.
Previously, I sent random values and then rotated afterwards. It made no sense but should do now!
This is to prevent memory corruption through a buffer overrun. We just pass a pointer to the first element. If we don't resize, then OASIS will happily write into parts of memory that haven't been reserved by Eigen.
Murphy strikes again, I guess.
This is quite hackish, but should work. We'll want to do this much more nicely in the future!
My testing setup is too complicated, so I didn't catch this last time.
clang-format and replace std::bind with lambda
This should avoid memory problems.
I was using ModelArray, UField, VField, and HField a bit interchangebly. This should be ok (but I'm not sure), but it's confusing. So now, it's HField everywhere.
Added Logged::debug messages to check if keys and ids make sense.
We'll ask OASIS to do it for us - at least until we have access to the underlying CG fields.
# Conflicts: # core/src/DevStep.cpp # core/src/Model.cpp # core/src/ModelMetadata.cpp # core/src/include/ModelMetadata.hpp # core/src/main.cpp # physics/test/CMakeLists.txt
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 Title
Fixes #459
Task List
Change Description
Please write a summary of the change and specify which Issue this fixes. This should cover the motivation for making the change and provide almost enough context to review the change in isolation. While the issue description is a good place to discuss the failure/requirements, this is the ideal space for explaining why this design fixes the issue and why you designed it the way you did.
Text goes here
Test Description
Please describe the tests you have written that verify the enhancement works or that the bug fix has been remedied. For a bug fix, please ensure a complete description of the failure is available here or in the issue such that a reviewer can verify that the testing is suitable. This is a good place to highlight any manual testing you may have had to perform.
Please describe any operating system limitations placed on the testing (if appropriate).
If your tests fixes any issue, please explain that in the comment you provided in the test file by referencing the issue within the comment and please record the mapping here e.g.
Text goes here
Documentation Impact
Please describe any changes to the documentation not captured above or, if made in a seperate pull request, please link to the corresponding PR or issue.
Text goes here
Other Details
If you have run any static analysis, including complexity analysis, or run coverage testing which has not been captured by an automated tool, please link or copy it here.
Text goes here
Pre-Request Checklist
Please complete your pull request description and delete the instructional text before submitting.
Congratulations and thank you for making your contribution to neXtSIM_DG!