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.
#2557 (Wrong behaviour of tab_2d_3d (and possible the others).) – NEMO

Opened 4 years ago

Closed 4 years ago

#2557 closed Bug (fixed)

Wrong behaviour of tab_2d_3d (and possible the others).

Reported by: orioltp Owned by: systeam
Priority: low Milestone: 2020 WP
Component: SI3 Version: trunk
Severity: major Keywords:
Cc:

Description

Context

When extending the mixed-precision implementation into the sea-ice, we came up with an unexpected problem.
To summarize, when we implemented the emulator inside the ICE code, we got a floating point overflow appearing in the surface pressure gradient. It was strange because at this point even if we are using the emulator, we were still using double-precision. We were tracking down the issue trying to find out where our tool made a mistake, but instead we found that what was misbehaving is not the version with the emulator but the original one.
...

Analysis

Tracking down the origin of the differences, we found that those started at iceistate.f90, in this routine call:
{{{#!
CALL tab_2d_3d( npti, nptidx(1:npti), ztsu_2d , t_su )
}}}
Arriving at this call, in both cases all the variables are identical, but after this call the values of t_su are different.
What is happening is that in the version with the emulator, the input values of t_su are ignored (as expected having in mind that the variable is defined as output), while in the original version the behaviour is more like a inout variable. For some reason that we ignore our compiler (intel 2019) treats this variable as an inout.
To recap, when the compiler behaves as it is intended by the standard, the code gives a floating overflow.
...

Fix

In case the desired behaviour is the inout one, this should be replaced in the code. If instead it should be out, it would be necessary to track down what is originating the floating point overflow.
...

Commit History (2)

ChangesetAuthorTimeChangeLog
13715clem2020-11-02T17:00:19+01:00

trunk: fix ticket #2557

13714clem2020-11-02T16:59:55+01:00

4.0-HEAD: fix ticket #2557. Sette results are unchanged

Change History (4)

comment:1 Changed 4 years ago by clem

The desired behavior is indeed inout.
I suppose it has always been working with only out because most (all?) compilers treat variables as inout instead
The routine icetab.F90 should be corrected accordingly

comment:2 Changed 4 years ago by clem

In 13714:

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

comment:3 Changed 4 years ago by clem

In 13715:

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

comment:4 Changed 4 years ago by clem

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.