wrong initialization of fldread structure for vectors

[smasson]

Context

As halos are no more read in the input files, we must fill them by applying the boundary conditions just after reading any file.

In consequence, a call to lbc_lnk was included in iom_get. This requires to know the type of point and the sign to properly apply the NP folding. By default, this is 'T' and +1._wp. This can be changed through the optional arguments cd_type and psgn.

This is the same story for data read with fld_read which uses iom_get.
We therefore added in the fldread structure (TYPE(FLD)) 2 new elements : cltype and zsgn to attach to the variable to be read its grid type an the sign to use in the NP folding. By default, they are defined to 'T' and +1._wp in fld_fill.
If the filed to be read by fldread is not a scalar value at T point, we must overwrite this default definition as it is done for example in src/OFF/dtadyn.F90 or src/SAS/sbcssm.F90.

Analysis

The following errors have been identified:

• in sbcblk.F90:
  • jp_wndi, jp_wndj, jp_uoatm, jp_voatm, jp_hpgi, jp_hpgj must have their sign defined to -1._wp: sf(...)%zsgn = -1._wp
• in sbcflx.F90:
  • we must add: sf(jp_utau)%cltype = 'U' and sf(jp_utau)%zsgn = -1._wp
  • we must add: sf(jp_vtau)%cltype = 'V' and sf(jp_vtau)%zsgn = -1._wp
  • the first cal to lbc_lnk can be removed (it was in fact fixing the bug)
• in sbcwave.F90:
  • jp_usd and sn_vsd must have their sign defined to -1._wp: slf_i(...)%zsgn = -1._wp

However, in sbcblk.F90 and sbcwave.F90 the computation of the stress at U and V points forces a call to lbc_lnk which corrects the problem. But the bug should be fix as we plan in the future to compute the stress at T point.
In sbcflx.F90, the bug is hidden by a call to lnc_blk that will become useless once the bug is fixed.

I haven't seen other vector field read by fld_read (except bdy staff but it is not compatible with the NP folding).

Note that this fix does not concern previous version of NEMO.

[smasson]

In 14398:

Error: Failed to load processor CommitTicketReference

No macro or processor named 'CommitTicketReference' found

[smasson]

In 14401:

Error: Failed to load processor CommitTicketReference

No macro or processor named 'CommitTicketReference' found

[smasson]

Replying to smasson:

In 14398:

Error: Failed to load processor CommitTicketReference

No macro or processor named 'CommitTicketReference' found

[14398] change the results of ORCA2 tests.
After more thinking, I think this is because of the V points on the second half of line jpj-2 (when nn_hls=1), i.e. from jpiglo/2+2 to jpiglo.
1) The bugfix modifies the sign of pwndj on the right side of half of line number jpj-1 of T points.
2) vtau uses T-point values at ji and ji+1 -> the bugfix will affect vtau on the right side of half of line jpj-2 (by using T points at jpj-1).
3) lbc_lnk on V points changes lines jpj and jpj-1 but does not touch line jpj-2.
-> So we have modified values even if we call lbc_lnk

[smasson]

[14401] passes all sette tests.
It gives the same results as [14400] except for AMM12 that is now working and was broken by [14398].