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.
#2725 (Bug in north pole folding for npolj=4, cd_type='U') – NEMO

Opened 3 years ago

Closed 3 years ago

#2725 closed Bug (wontfix)

Bug in north pole folding for npolj=4, cd_type='U'

Reported by: omamce Owned by: systeam
Priority: low Milestone:
Component: LBC Version: v4.0.*
Severity: critical Keywords:
Cc:

Description

Starting line 97 in lbc_nfd_generic.h90
(NEMO/releases/r4.0/r4.0.6/src/OCE/LBC)

   DO ji = jpiglo/2, jpiglo-1
        iju = jpiglo-ji+1
        ARRAY_IN(ji,ipjm1,:,:,jf) = SGN_IN(jf)  * ARRAY_IN(iju,ipjm1,:,:,jf)

Than mean that the two first steps of the loop are :

ARRAY_IN[... , jpiglo/2  , ...] = ARRAY_IN [ jpiglo/2+1]
ARRAY_IN[... , jpiglo/2+1, ...] = ARRAY_IN [ jpiglo/2  ]

That was probably fine on a vector machine. A real one, with vector registers.

Anyway, on a scalar one, it leaves ARRAY_IN[... , jpiglo/2+1, ...] unchanged, which is not what we want.

An example, on a small domain :

Original ARRAY_IN :

       1   2   3   4   5   6   7   8   9  10
    ----------------------------------------
 7|   61  62  63  64  65  66  67  68  69  70
 6|   51  52  53  54  55  56  57  58  59  60
 5|   41  42  43  44  45  46  47  48  49  50
 4|   31  32  33  34  35  36  37  38  39  40
 3|   21  22  23  24  25  26  27  28  29  30
 2|   11  12  13  14  15  16  17  18  19  20
 1|    1   2   3   4   5   6   7   8   9  10

After LBC with npolj=4, cdtype=U, psgn=-1 :

      1   2   3   4   5   6   7   8   9  10
    ----------------------------------------
 7|  -42 -49 -48 -47 -46 -45 -44 -43 -42 -49
 6|   59  52  53  54 -56  56 -54 -53 -52  52
 5|   49  42  43  44  45  46  47  48  49  42
 4|   39  32  33  34  35  36  37  38  39  32
 3|   29  22  23  24  25  26  27  28  29  22
 2|   19  12  13  14  15  16  17  18  19  12
 1|    9   2   3   4   5   6   7   8   9   2

Value for j=6, i=6 is normal ? Or should it be -55 ?

We probably want :

      1   2   3   4   5   6   7   8   9  10
    ----------------------------------------
 7|  -42 -49 -48 -47 -46 -45 -44 -43 -42 -49
 6|   59  52  53  54 -56 -55 -54 -53 -52  52
 5|   49  42  43  44  45  46  47  48  49  42
 4|   39  32  33  34  35  36  37  38  39  32
 3|   29  22  23  24  25  26  27  28  29  22
 2|   19  12  13  14  15  16  17  18  19  12
 1|    9   2   3   4   5   6   7   8   9   2

Tested on :
gfortran 11.2 on Mac OS X 10.4.6
ifort 19.1 TGCC/Irene GNU/Linux 3.10.0-1160.31.1.el7.x86_64

This behaviour is present in 4.0.6 and 3.6

I suppose that it might disappear with some optimization options

Other points T, V and F seems OK. npolj=6 is OK for all points. I haven't tested other values of npolj

I've found the bug by testing a port of LBC in Python.

Commit History (0)

(No commits)

Change History (1)

comment:1 Changed 3 years ago by smasson

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

Yes, there is an error in the loop index. It should be (jpiglo/2+1) instead of jpiglo/2.
This bug has, in fact, no impact as these points are always masked.
I am not completely sure there is no such harmless bugs in the nogather version (lbc_nfd_nogather_generic.h90)...

This part was completely rewritten and corrected in the trunk (future 4.2). We won't change the r4.0-head

Note: See TracTickets for help on using tickets.