New URL for NEMO forge!   http://forge.nemo-ocean.eu

Since March 2022 along with NEMO 4.2 release, the code development moved to a self-hosted GitLab.
This present forge is now archived and remained online for history.
#2458 (XIOS2.5 in coupled model) – NEMO

Opened 4 years ago

Closed 4 years ago

Last modified 2 years ago

#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)

ChangesetAuthorTimeChangeLog
12904andmirek2020-05-11T18:04:16+02:00

Ticket #2458 fix for the problem

12902andmirek2020-05-11T17:58:20+02:00

Ticket #2458 development branch

Change History (6)

comment:1 Changed 4 years ago by andmirek

In 12902:

Error: Failed to load processor CommitTicketReference
No macro or processor named 'CommitTicketReference' found

svn+ssh://andmirek@forge.ipsl.jussieu.fr/ipsl/forge/projets/nemo/svn/NEMO/branches/2020/dev_r40_XIOS_OASIS

Last edited 4 years ago by andmirek (previous) (diff)

comment:2 Changed 4 years ago by andmirek

In 12904:

Error: Failed to load processor CommitTicketReference
No macro or processor named 'CommitTicketReference' found

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.

Version 0, edited 4 years ago by andmirek (next)

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
Note: See TracTickets for help on using tickets.