Changes between Version 4 and Version 5 of ticket/1658/General

Timestamp:

2016-06-08T12:18:37+02:00 (8 years ago)

Author:

frrh

Comment:

--

ticket/1658/General

@@ -76 +76 @@
 
   
+   * Well this fails - initially because it was trying to couple fields which I didn't want to exchange. It turns out the best way to manage these  is via checking sn_rcv_atm_pco2%cldes, sn_rcv_atm_dust%cldes, sn_snd_bio_dms%cldes and sn_snd_bio_co2%cldes values. We use a value of "medusa" in the suite GUI to enable each field. I use "disable" to switch it off as far as NEMO is concerned, but you could just as well use "tomato" or anything which isn't "medusa". 
+   * Switching just to using DMS, which I believe is probably the most likely to be viable field, the thing still crashes. It turns out that the DMS field dms_surf2d and f_co2flux2d and f_pco2a are only temporary work arrays in trcbio_medusa. They are allocated, used and deallocated entirely within the life of that routine, so are completely unsuitable  for use as coupling fields in the puts and gets. 
 
+  * Contacted JP to explain the problems. I could do something along the lines of the following:
+{{{
+  create special coupling arrays which I declare and use in 
+  the NEMO coupling interface, say: DMS_out_cpl, CO2Flux_out_cpl, PCO2_in_cpl
+  and  Dust_in_cpl. Then the MEDUSA code would have to add things like
+
+   USE sbccpl, ONLY: DMS_out_cpl, CO2Flux_out_cpl
+   USE sbccpl, ONLY: PCO2_in_cpl, Dust_in_cpl
+
+   in the appropriate MEDUSA modules and just copy the appropriate values
+   to and from these arrays at the correct times. 
+}}}
+   The problem with that is that we don't really know when the coupling exchanges have happened or are about to 
+   happen so you could end up copying to and from these arrays on every timestep which is a small cost in terms of the overall model costs, but it's still not a great precedent to set. Well we're net even setting a precedent because sbccpl is full of stuff copying and processing fields on every TS which may or may not ultimately result in an actual PUT operation. So maybe as an approach it's not that bad. 
 
  
 
+ 
+