Opened 7 years ago
Closed 5 years ago
#1905 closed Bug (wontfix)
Asselin filtering of tracers in tranxt.F90 with VVL and lk_dynspg_ts.AND.ln_bt_fw==.true. incorrectly assumes that e3t will be Asselin filtered
Reported by: | agn | Owned by: | agn |
---|---|---|---|
Priority: | high | Milestone: | |
Component: | OCE | Version: | v3.6 |
Severity: | minor | Keywords: | VVL, tracer conservation, forward barotropic |
Cc: | davestorkey |
Description
Context
With VVL, Asselin filtering is normally applied both to tracer load (tn*e3tn) and to the layer thickness (e3t) itself. Because e3n is used for the dynamics as well as for the tracers, e3n is not yet filtered at the stage where the tracer load is filtered in tra_nxt_vvl; instead a temporary Asselin-filtered variable ze3t_f is employed to represent the (newly filtered) e3n that will be e3b for the next time step. The filtered tracer value (the new tb that used to be tn) is then calculated by Asselin filtering of the tracer load and then dividing by the temporary Asselin-filtered variable ze3t_f so that next time step tb*e3b is correct.
The e3b for the next time step is then finally set by Asselin filtering in dyn_nxt.
Analysis
In the case where (lk_dynspg_ts.AND.ln_bt_fw) == .true., e3t is not Asselin filtered when e3tn is set to e3tb for the next time step. However the code in tra_nxt_vvl does not check this and always assumes that e3tn will be filtered, so that tracer load is not conserved.
Fix
Insert a check in tra_nxt_vvl to divide the newly Asselin filtered before tracer load by e3tn rather than the filtered value ze3t_f when (lk_dynspg_ts.AND.ln_bt_fw) == .true
Commit History (0)
(No commits)
Attachments (1)
Change History (5)
Changed 7 years ago by jchanut
comment:1 Changed 7 years ago by jchanut
comment:2 Changed 6 years ago by clevy
- Owner changed from nemo to agn
- Status changed from new to assigned
comment:3 Changed 6 years ago by clevy
- Priority changed from major to critical
comment:4 Changed 5 years ago by jchanut
- Resolution set to wontfix
- Severity set to minor
- Status changed from assigned to closed
Fix implemented in NEMO 4.0 (see task #1959) but won't be solved in release 3.6.
Hi George,
Yes, there is indeed a conservation issue if lk_dynspg_ts=T. This has been reported earlier though "hidden" in ticket #1529. The solution is however not that straightforward I think. We have written a note a while ago with a possible (advective) correction (see attached document; statement below eq. 10. refers to the problem).
Jérôme