Opened 5 weeks ago

Closed 4 weeks 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 5 weeks 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 weeks ago by clem

In 13714:

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

comment:3 Changed 4 weeks ago by clem

In 13715:

trunk: fix ticket #2557

comment:4 Changed 4 weeks ago by clem

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