Changes between Version 70 and Version 71 of ticket/1851/General

Timestamp:

2017-04-04T14:58:06+02:00 (7 years ago)

Author:

frrh

Comment:

--

ticket/1851/General

@@ -570 +570 @@
 Further protracted tracking of origins of differences leads eventually to ffetop (from zirondep). This is zero on a TS following a restart but not in the NRUN. It turns out that this has been fixed with an update to the MEDUSA branch during the time (4 weeks now) I've been chasing these bugs! Upgrading my job to use a wc based on the very latest revision  7766, confirms that the total iron concentration field no longer diverges at TS33. However other things do still diverge! Again I only see things drifting at TS 34 which again is suggestive of things being updated in the wrong sequence following a restart. However MS is also investigating and has suspicions about a particular timestep of a field being used when it shouldn't be (i.e. it's using an _n value when it should be using a _b value). I'll hold off and wait to see what comes of that.   
 
+Nothing doing initially, so returned to work on the coupled case.... this leads to variables gtru and gtrv (also, annoyingly referred to as pgu and pgv via name changes in argument lists) which are different on the first TS after a restart. Marc has come up with a fix which addresses restartability in his non-coupled set up. This involves saving gtru and gtrv in the restart dump. I'm suspicious about the positioning of calls to zps_hde in MEDUSA and whether it uses the appropriate tracer timestep field in each case. Anyway, including MS's fixes by hand in my medusa debugging working copy  I seem to now have tracer restarts matching at 2 days for NRUN v CRUN cases. It remains to be seen whether this is the most appropriate solution. 
+
+See MS's fix branch at https://forge.ipsl.jussieu.fr/nemo/log/branches/UKMO/dev_r5518_medusa_fix_restart and GMED ticket https://code.metoffice.gov.uk/trac/gmed/ticket/313
+
+I have a number of questions:
+   * NEMO seems to deal OK with this for tracers 1 aqnd 2 (T and S) without saving gradient fields. How does it do that.
+   * MEDUSA calls trcini which  calls zps_hde using trn. Should it really be doing that? Why doesn't it use trb?
+   * MEDUSA seems to update gtru/v after trc_rad and before trc_trp. Is that analogous to main NEMO?
+   * MEDUSA calculates fo everything including the first 2 tracers which are T and S(aren't they?) Why does it do that? These presumably shouldn't need recalculation since MEDUSA doesn't directly update them and in fact only ever influences them indirectly via a full coupled model!? 
+
+
+ 
+