Opened 6 years ago

Closed 3 years ago

Last modified 3 years ago

#1503 closed Bug (fixed)

TOP not conservative with vvl

Reported by: cbricaud Owned by: cetlod
Priority: low Milestone:
Component: OCE Version: release-3.6
Severity: Keywords:
Cc:

Description

a passive tracer is initilized with 1 everywhere in the domain
we should find 1 at the end of the run… but it is not the case.
problem of surface boundary condition.

Commit History (0)

(No commits)

Change History (8)

comment:1 Changed 6 years ago by timgraham

  • Version changed from nemo_v3_4 to nemo_v3_6_alpha

I've reproduced this behaviour in the ORCA2 model with no surface forcing and no ice model.

Looking at the restart file after 10 timesteps the largest changes in concentration occur where the bathymetry is shallowest. Also I think (just from a quick look in ncview) the concentration has decreased where SSH has increased and the concentration has increased where SSH has decreased.

comment:2 Changed 5 years ago by timgraham

After comparing my setup with Andrew's setup this is due to using Euler timestepping for TOP (ln_top_euler = .true. in namelist_top_cfg). With this option set to .false. the concentration is still 1 after 15 timesteps.

The question now is what we should do to fix this. Should this option just be disabled in the code for the VVL case or should we try to fix the code so that it works?

comment:3 Changed 5 years ago by timgraham

For now I propose adding the following lines to trcini.F90:

IF(ln_top_euler .AND. lk_vvl) &
   &  CALL ctl_stop('ln_top_euler option does not conserve with VVL; Set ln_top_euler=.false.')

and a USE dom_oce so that it had access to lk_vvl.

Does anyone have any objections to this?

Last edited 3 years ago by nicolasmartin (previous) (diff)

comment:4 Changed 5 years ago by vichi

Hi all
are you sure this is not just a problem of the advection scheme? If you use TVD then the time integration is based on a leapfrog scheme and Asselin filter. And of course the ln_top_euler is going to force the time step to be the wrong one and not in line with the volume change.
If you try to run with the MUSCL advection the change should be much smaller (although there is still a problem of mass conservation with vvl)

marcello

comment:5 Changed 5 years ago by acc

A couple of questions arising from a look at tra_nxt_vvl (trnxt.F90) which is used for both 'TRA' and 'TRC' calls:

 1.           zfact1 = atfp * rdttra(jk)

for both 'TRA' and 'TRC' calls; but rdttrc may be different to rdttra if nn_dttrc > 0?

2.
                  IF( ll_tra .AND. jk == 1 ) THEN           ! first level only for T & S
                      ze3t_f = ze3t_f - zfact2 * ( emp_b(ji,jj) - emp(ji,jj) )
                      ztc_f  = ztc_f  - zfact1 * ( sbc_tsc(ji,jj,jn) - sbc_tsc_b(ji,jj,jn) )
                  ENDIF

but shouldn't the emp correction be done for all dissolved tracers (or is it already accounted for elsewhere)?. Playing with these doesn't help the fundamental problem here with ln_top_euler.

Version 0, edited 5 years ago by acc (next)

comment:6 Changed 5 years ago by jchanut

Hi,
I found in several places (trcadv, trczdf,…) this trick to set the tracer time step:

         IF( neuler == 0 .AND. kt == nittrc000 ) THEN     ! at nittrc000
            r2dt(:) =  rdttrc(:)           ! = rdttrc (restarting with Euler time stepping)
         ELSEIF( kt <= nittrc000 + 1 ) THEN               ! at nittrc000 or nittrc000+1
            r2dt(:) = 2. * rdttrc(:)       ! = 2 rdttrc (leapfrog)
         ENDIF

The problem is that condition 2 is never satisfied with substepping, hence the time step remains an Euler time step.
One should rather have:

 ELSEIF( kt <= nittrc000 + nn_dttrc ) THEN
    r2dt(:) = 2. * rdttrc(:)


Last edited 3 years ago by nicolasmartin (previous) (diff)

comment:7 Changed 3 years ago by clevy

  • Owner changed from nemo to cetlod
  • Version changed from nemo_v3_6_alpha to nemo_v3_6_STABLE

comment:8 Changed 3 years ago by cbricaud

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

solved in trunk and nemo 3.6 stable

Note: See TracTickets for help on using tickets.