Changes between Version 59 and Version 60 of ticket/1851/General

Timestamp:

2017-03-09T16:48:41+01:00 (7 years ago)

Author:

frrh

Comment:

--

ticket/1851/General

@@ -455 +455 @@
 There's a suspicious looking bit of code in here which does;
 
-{{{
+{{{    IF( kt /= nit000 ) THEN                      !          Swap of forcing fields          !
+         !                                         ! ---------------------------------------- !
+         rnf_b    (:,:  ) = rnf    (:,:  )               ! Swap the ocean forcing fields except at nit000
+         rnf_tsc_b(:,:,:) = rnf_tsc(:,:,:)               ! where before fields are set at the end of the routine
+         !
+      ENDIF
+}}}
+
+And later on we have...
+
+{{{
+
       IF( kt == nit000 ) THEN                          !   set the forcing field at nit000 - 1    !
          !                                             ! ---------------------------------------- !
@@ -472 +483 @@
 }}}
 
-So this lump of code can only be called on the first TS after a restart... putting writes in here confirms that it is and that the first IF condition qualifies so it's reading rnf_b and rnf_tsc_b
-from the dump. However it seems that if it wasn't reading the dump it wants to transfer rnf to rnf_b and rnf_tsc to rnf_tsc_b. I don't get how that can make sense. 
-
-If it's the first TS of a restart  where's it getting its values from? Ancillaries?  Maybe it's OK.  
+So it means on every TS except a restart it's setting rnf_b = rnf and rnf_tsc_b = rnf_tsc. 
+A restart is the only occasion when these things emerge from sbc_rnf with different values. The rest of the time the _b and standard values are identical. Talking to Tim he agrees this is fishy. He says that the reading of rnf_b from the restart is legitimate because we need the value from the last TS, but our rnf value should be different. So it's the CRUN at TS 33 which is at fault. In fact all non-restart timesteps will have incorrectly identical values for rnf and rnf_b. 
+
+We need to ensure that this swapping is done before the new rnf value is obtained (from the coupling), not after!
+
+This appears to have been in code for a very long time. Tim confirms that it was present in GC2! 
+
+The only reason we're able to identify this (and the CICE restart bug) now is because we now have a restartable atmosphere. Until we had that (some time in the last year) we would never 
+have been able to spot these sorts of bugs, w/o some sort of dummy interface. 
+     
+