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


Ignore:
Timestamp:
2016-06-08T12:18:37+02:00 (4 years ago)
Author:
frrh
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • ticket/1658/General

    v4 v5  
    7676 
    7777   
     78   * 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".  
     79   * 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.  
    7880 
     81  * Contacted JP to explain the problems. I could do something along the lines of the following: 
     82{{{ 
     83  create special coupling arrays which I declare and use in  
     84  the NEMO coupling interface, say: DMS_out_cpl, CO2Flux_out_cpl, PCO2_in_cpl 
     85  and  Dust_in_cpl. Then the MEDUSA code would have to add things like 
     86 
     87   USE sbccpl, ONLY: DMS_out_cpl, CO2Flux_out_cpl 
     88   USE sbccpl, ONLY: PCO2_in_cpl, Dust_in_cpl 
     89 
     90   in the appropriate MEDUSA modules and just copy the appropriate values 
     91   to and from these arrays at the correct times.  
     92}}} 
     93   The problem with that is that we don't really know when the coupling exchanges have happened or are about to  
     94   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.  
    7995 
    8096  
    8197 
     98  
     99