[NEC] Wrong time indexing while using `ln_apr_dyn` with monthly forcing

Versions
,
1

Dear all,

I’m using NEMO r4.0.2 as a stand alone model forced by monthly atmospheric files with time frequency of 1h. The input files have different length, for example with number of records = 672 in February and 744 in March.

When using monthly input file for atmospheric pressure (PRES) and ln_apr_dyn = .true., the namsbc_apr section in the namelist_cfg looks like:

namsbc_apr
namsbc_apr1570×251 15.8 KB

During the run time, following error encounters:

 ===>>> : E R R O R
         ===========

           iom_get_123d, file: NFORC/PRES_y2018m03.nc, var: PRES
 start and count too big regarding to the size of the data,
 (istart(3) + icnt(3) - 1) =        645
  is larger than idimsz(3) =     644

The time index of the previous month instead of the current month is used.

It seems that the file containing PRES variable for the previous month is opened for the initialization, but never closed after getting the first information.

Does someone of you use monthly atmopsheric forcing files and was having similar troubles with the time indexing and may have a hint how to solve this?

Kind regards,
Janna

2

This behaviour seems to occur using the NEC (nfort) compiler.
Using intel mpiifort the time stepping seems fine.

3

Hei Janna,

So the very same thing does not happen on a different platform ?

/robinson

4

Which value do you have for nn_leapy?

5

Hi Robinson,
you got it right, it doesn’t happen on a different platform (x86 host for the NEC vector machine).

One question for all:
is NEMO code tested on a vector machine like NEC?

Cheers,
Janna

6

Hi,
nn_leapy is 1, leap years are taken into account.
To clarify the example, the time step is always wrong in the months after the shorter ones, like April/May, June/July, September/October, November/December.

7

I know there is some benchmark with nemo on NEC but I am not aware of any real usage…