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.
#1633 (Wrong time stamp in tidal forcing update) – NEMO

Opened 8 years ago

Closed 8 years ago

#1633 closed Bug (fixed)

Wrong time stamp in tidal forcing update

Reported by: jchanut Owned by: nemo
Priority: normal Milestone:
Component: OCE Version: v3.6
Severity: Keywords: tides
Cc:

Description

There are several bugs in the update of tidal forcing in sub barotropic loop. Noteworthy is a missing argument in the call to upd_tide (refreshment of tidal potential) in dynspg_ts that implies:

  • No resfreshment of tidal potential during barotropic loop (value frozen at central time step, despite a call every barotropic step).
  • If ln_bt_fw=.false., same problem as above but there's a very significant time lag of 2 * nn_baro * rdt seconds in the past !

Users using tides are stongly advised to track changes related to this ticket.

Commit History (3)

ChangesetAuthorTimeChangeLog
5914rfurner2015-11-24T15:18:12+01:00

pulled over bug fix from trunk, see nemo ticket #1633

5913jchanut2015-11-24T14:57:12+01:00

Correct time arguments for tidal forcing, ticket #1633

5912jchanut2015-11-24T14:42:04+01:00

Correct time arguments for tidal forcing, ticket #1633

Change History (5)

comment:1 Changed 8 years ago by jchanut

Corrected in NEMO_3_6_STABLE:

https://forge.ipsl.jussieu.fr/nemo/changeset/5912/branches/2015/nemo_v3_6_STABLE

And in trunk:

https://forge.ipsl.jussieu.fr/nemo/changeset/5913/trunk

Changes in AMM12 results are expected

comment:2 Changed 8 years ago by nicolasmartin

Effectively results in AMM12 config has changed on Trusting:

Results : ocean.output solver.stat differ
Restarts: AMM12_trust_00000576_restart_oce_out 1055 record(s) differ, 1037 of 1089 records differ more than 0.001

Diff in ocean.ouput

<   ==>> time-step=            1  abs(U) max:    1.38831038620314     
<   ==>> time-step=            1  SSS min:   12.4065699691971     
>   ==>> time-step=            1  abs(U) max:    1.38831037651113     
>   ==>> time-step=            1  SSS min:   12.4065699499566     
<   ==>> time-step=          145  abs(U) max:    1.17996826451025     
<   ==>> time-step=          145  SSS min:   12.6914238396041     
>   ==>> time-step=          145  abs(U) max:    1.17995713752074     
>   ==>> time-step=          145  SSS min:   12.6894927993044     
<   ==>> time-step=          289  abs(U) max:    1.19398661109917     
<   ==>> time-step=          289  SSS min:   12.8698631513494     
>   ==>> time-step=          289  abs(U) max:    1.19198422837464     
>   ==>> time-step=          289  SSS min:   12.8662227283950     
<   ==>> time-step=          433  abs(U) max:    1.25394228156625     
<   ==>> time-step=          433  SSS min:   13.0251812235615     
>   ==>> time-step=          433  abs(U) max:    1.25155435873531     
>   ==>> time-step=          433  SSS min:   13.0174624101055

Is that what you expected ?

comment:3 Changed 8 years ago by jchanut

Well, hard to predict. I am pretty sure things were wrong.

comment:4 Changed 8 years ago by nicolasmartin

Ok, if nobody shows up, I will take these results as new benchmark for AMM12.

comment:5 Changed 8 years ago by clevy

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