#2458 closed Defect (invalid)
XIOS2.5 in coupled model
Reported by: | andmirek | Owned by: | systeam |
---|---|---|---|
Priority: | low | Milestone: | Unscheduled |
Component: | SBC | Version: | trunk |
Severity: | minor | Keywords: | v4.2 |
Cc: | smasson, cetlod |
Description
Context
Building coupled configuration UM + NEMO4 with XIOS2.5 (rev 1849 trunk) results in model hanging in OASIS just before ending OASIS definition stage.
Analysis
In our configuration adding a call to a new XIOS function (introduced in rev 1587) xios_oasis_enddef() just before oasis_enddef resolved the issue. This is the message from XIOS mail list on this subject.
Revision: 1587 ?http://forge.ipsl.jussieu.fr/ioserver/changeset/1587 Author: ? ymipsl Date: ? ? 2018-10-15 16:42:33 +0200 (Mon, 15 Oct 2018) Log Message: ----------- XIOS - OASIS interaction : due to many problem occurring in the oasis/XIOS initialization phase due to a bad order of intialization call ?from both, you have now the possibily to explicitly inform xios that the servers must call oasis_enddef(). ** New rules : On model side, before calling oasis_enddef, you must add a call to "xios_oasis_enddef()" ** Old rules : oasis_enddef must be call before any call to "xios_context_initialize" otherwise it may lead to a deadlock. You can use the old rules if the variable <call_oasis_enddef> is set to false (default value is true), and by this way no need to modify the source code of the models
At the MetOffice? for XIOS2.5 compilation we have to use the latest available Cray compiler - cce/8.7.7.
At this moment it's not obvious if this problem is related to compiler we are using (it's not our default compiler); we may be able to test a different coupled configuration built with Intel compiler within couple of weeks.
As long as XIOS2.5 is at least at rev 1587 this change is neutral. There is a branch with the change (for NEMO 3.6), currently in review, to be implemented in MO package branch:
http://forge.ipsl.jussieu.fr/nemo/changeset?sfp_email=&sfph_mail=&reponame=&new=12796%40branches%2FUKMO%2Fdev_r5518_GO6_XIOS25_cpl&old=12407%40branches%2FUKMO%2Fdev_r5518_GO6_package
Recommendation
Commit History (2)
Changeset | Author | Time | ChangeLog |
---|---|---|---|
12904 | andmirek | 2020-05-11T18:04:16+02:00 | Ticket #2458 fix for the problem |
12902 | andmirek | 2020-05-11T17:58:20+02:00 | Ticket #2458 development branch |
Change History (6)
comment:1 Changed 4 years ago by andmirek
comment:2 Changed 4 years ago by andmirek
In 12904:
comment:3 Changed 4 years ago by andmirek
I didn't run sette tests. This part of the code is not tested.
Possible cause of hanging - calls to XIOS functions before any context is initialized. This is happening for instance in dia_ptr_init - see ticket #2384. To be investigated further in MO coupled configuration.
comment:4 Changed 4 years ago by smasson
- Cc smasson cetlod added
After discussion with Arnaud Caubel from IPSL.
The call to xios_oasis_enddef that was added in cpl_oasis3.F90 in [12904] is a new feature in xios-trunk.
The changeset 1587 you refer in your analysis is indeed for xios-trunk, not xios-2.5.
It does not exist in xios-2.5. You cannot call this routine with xios-2.5.
This new feature was added in xios-trunk to remove a constraint of xios-2.5:
oasis_enddef and xios_context_initialize must be called with the same order for each component of the coupled model. In nemo, oasis_enddef is called before xios_context_initialize, therefore each model coupled with NEMO - and using XIOS - must use the same order to call these routines (as theses routines are using collective communications).
With xios-trunk, there is now two available strategies.
- same as in xios-2.5: oasis_enddef and xios_context_initialize must be called with the same order. This requires to define call_oasis_enddef = .false. in iodef.xml
- new and default behavior (call_oasis_enddef = .true. in iodef.xml): add a call to xios_oasis_enddef just before the call to oasis_enddef.
Note that all the components of a coupled model must use the same strategy.
In consequence, in future version of NEMO, we will need to keep both strategies and probably add a namelist parameter to choose the strategy.
comment:5 Changed 4 years ago by andmirek
- Resolution set to invalid
- Status changed from new to closed
Not applicable to XIOS 2.5 branch used with NEMO 4.
comment:6 Changed 2 years ago by nemo
- Keywords v4.2 added
In 12902:
svn+ssh://andmirek@forge.ipsl.jussieu.fr/ipsl/forge/projets/nemo/svn/NEMO/branches/2020/dev_r40_XIOS_OASIS