Opened 2 years ago

Closed 22 months ago

#2100 closed Defect (fixed)

Missing value in ORCA2 ouput

Reported by: mathiot Owned by:
Priority: low Milestone: 2018 release-4.0
Component: OCE Version: trunk
Severity: minor Keywords: outputs, XIOS,
Cc:

Description

Context

ORCA2 outputs (SETTE tests outputs at least) have a band of missing value (1e20) on the E/W overlap region at ji=1 and ji=182 (at least on MetO Cray computer). The north fold overlap region is not affected. I expect this issue to affect all the configurations.

Analysis

I see some issue about this, especially for the users:

  • It is not coherent with the overlap region along the north fold.
  • It will maybe break some tools (CDFTOOLS).
  • I am not sure missing value (1e20) in the output without land suppression and without ln_maskland are expected.

Recommendation

  • Output only the interior data could maybe avoid to add lbclnk for some diagnostics.
  • I think we should at least be coherent, ie mask all the overlap region or fill those points with a valid data. If it is communicated in the release, maybe the masking of the overlap is not an issue (user are aware and need to update there tools if needed).

Commit History (2)

ChangesetAuthorTimeChangeLog
9903smasson2018-07-09T15:04:55+02:00

trunk: bugfix following [9802], see #2100

9802smasson2018-06-15T11:47:25+02:00

trunk: put back data in outputs file for e-w periodicity, see #2100

Change History (8)

comment:1 Changed 2 years ago by smasson

I raised the question a few months ago during a telco when I updated mppini and introduced this "new feature" :-)
Nobody seams really concerned at that time…
I agree, this is not really consistent, the North pole should also have missing values.
Are you sure you have 1.e20 values? I thought it should be NaN…

comment:2 Changed 2 years ago by mathiot

I double check. On our system, ncview shows me a value of 1e20 and _FillValue in the netcdf is also defined to 1e20. It is the same value as the one used to fill the land processor.

comment:3 Changed 2 years ago by smasson

In 9802:

trunk: put back data in outputs file for e-w periodicity, see #2100

comment:4 Changed 2 years ago by smasson

  • Resolution set to fixed
  • Status changed from new to closed

done, see [9802]

comment:5 Changed 2 years ago by acc

  • Resolution fixed deleted
  • Status changed from closed to reopened

The current code modifies the size of restart datasets too. This is unintentional and leads to restart failures in ORCA2 SETTE tests. Restart attempts are stopped by a 'impossible to identify the domain' message. I believe the fault arises due to the use of the same:

      IF ( ltmppatch ) THEN
         nldi_save = nldi   ;   nlei_save = nlei
         nldj_save = nldj   ;   nlej_save = nlej
         IF( nimpp           ==      1 ) nldi = 1
         IF( nimpp + jpi - 1 == jpiglo ) nlei = jpi
         IF( njmpp           ==      1 ) nldj = 1
         IF( njmpp + jpj - 1 == jpjglo ) nlej = jpj
      ENDIF

body of routine

      IF ( ltmppatch ) THEN
         nldi = nldi_save   ;   nlei = nlei_save
         nldj = nldj_save   ;   nlej = nlej_save
      ENDIF

construct in both iom_init and routines called within it (such as set_grid). Since nlei_save etc. are common to the module, the second and subsequent use of the construct sets the saved values to the changed values and the original values are irretrievably lost. The best solution depends on whether or not the nested routines are used elsewhere and needs investigation.

Last edited 2 years ago by nemo (previous) (diff)

comment:6 Changed 2 years ago by smasson

I am a little bit lost… the problem occurs only when you use xios to write the restart files (nn_wxios /= 0), no?
When nn_wxios == 0 restarts are open with iom_open and not iom_init so it should work, no?

comment:7 Changed 2 years ago by smasson

In 9903:

trunk: bugfix following [9802], see #2100

comment:8 Changed 22 months ago by mathiot

  • Resolution set to fixed
  • Status changed from reopened to closed

Data in outputs file for e-w periodicity had been put back and the model is restartable (thanks to Sebastien and Andrew).

Note: See TracTickets for help on using tickets.