Add multi-coupler option for multi-instance simulations #1704
Comments
|
I see the following supported use cases for the multi-coupler:
Are there any other use cases? @billsacks? @mvertens? @jedwards4b? |
|
With respect to your item 3 ESP will currently have three instances - we would need to add code in the driver or the ESP component to ignore the call if instance > 1. |
|
For a multi-coupler case, if there is a non-stub component which does not support multiple instances (e.g., Wave Watch?), an error MUST be generated (with the usual exception for ESP components which do not interact with the coupler). To me, this means that the case-control system must know whether the selected case components support multi-instance. |
|
Doesn't this indicate a bug in the component interface? All components should work with multiple instances. |
|
Yes, it can be considered a bug (for Wave Watch, ESP is specifically for models which work outside the coupled system) but I do not think we have the power to reject components which only support a single instance so I suppose that the options are to add in a check or fix Wave Watch before bringing in the multi-coupler functionality. |
|
Both ERS_C3.T62_g16.CECO.cheyenne_intel.pop-ecosys and ERS_N3.T62_g16.CECO.cheyenne_intel.pop-ecosys |
|
@gold2718 I don't know of any use cases other than the ones you mention. But, unless things have changed recently, I think this one actually has more stringent requirements
If I remember correctly, all prognostic components must be run with Regarding WW3: I recently had to introduce a B1850GWs compset simply for the sake of being able to test multi-instance capability in B1850G (@fischer-ncar is the one who pointed out this was needed). I guess we need to do something like this for other compsets that want to test NCK, _N3, _C3, etc. |
|
That is better than nothing but it would be better if handled in the case-control system. |
|
I agree - I was actually just about to edit my comment to say that. |
|
WW3 may even end up getting fixed but as we move forward with more collaboration (read accepting more models into CESM), this issue is going to keep popping up. |
|
@billsacks, yes, there is a special check for prognostic components (starting at line 1611 in cesm_comp_mod.F90). I have updated my list above to make that clear. |
Implementation of multiple MCT drivers as an option for multi-instance simulations. If multi-instance is enabled, N drivers are run, each with one instance.
Also (changes not directly related to multi-driver):
Changed interface of check_lockedfiles (check_lockedfiles.py) to take a case instead of a caseroot.
Use case.get_env instead of EnvBuild in check_lockedfiles.py
Changed check_case (case_submit.py) to not take a caseroot input.
Cleaned up memleak testing in _check_for_memleak (system_tests_common.py)
Fixed bad format in build_xcpl_nml (buildnml.py)
Test suite: scripts_regression_tests.py
Test baseline: NA
Test namelist changes: NA
Test status: bit for bit
Fixes: #1704
Fixes: #1714
User interface changes?: new --multi-driver option to create_newcase and _C# modifier to tests
Update gh-pages html (Y/N)?: Y
Code review: @gold2718
ghost
removed
the
Currently, multi-instance simulations share a single coupler instance which must handle coupling for each instance in a serial fashion. In order to alleviate this bottleneck, @rmontuoro has implemented a modification allowing one coupler instance per model instance. In order to manage this feature from the CIME case control system, we need to specify the user interface (arguments to
create_newcaseandcreate_testalong with any relevant XML variable changes) and also specify the supported semantics to allow for proper error checking.The text was updated successfully, but these errors were encountered: