Changes between Version 2 and Version 3 of ticket/1658/General

Timestamp:

2016-06-07T11:36:04+02:00 (8 years ago)

Author:

frrh

Comment:

--

ticket/1658/General

@@ -10 +10 @@
 
 
-'''Developmemt'''
+'''Development'''
 
 The MEDUSA code itself is held in a development branch, created and maintained at NOC named, at time of writing, [log:branches/NERC/dev_r5518_NOC_MEDUSA_Stable dev_r5518_NOC_MEDUSA_Stable]
@@ -39 +39 @@
 interface to avoid this because this branch, although only part of the GO6 configuration, actually features changes relating to coupled models (for reasons of avoiding code clashes!) particularly w.r.t. the magic numbers used for coupled field indexing. 
 
+Discussing with Tim Graham, he's happy for the MEDUSA interface to be added to the GO6 definition (i.e. to [log:branches/UKMO/dev_r5518_coupling_GSI7_GSI8_landice_bitcomp dev_r5518_coupling_GSI7_GSI8_landice_bitcomp] or a variant of that branch) provided we can disable the MEDUSA code to allow that branch to continue to be compatible with all existing non MEDUSA configurations.
+
+That should be do-able. It seems we'll have to control the relevant code with key_medusa, which is not ideal, unless we can introduce dummy modules containing dummy variable declarations which would allow us to 
+control things within sbccpl.F90, etc purely with run time logicals.  
+
+Initially I start on the basis of controlling things with CPP keys. 
+
+* Created new NEMO vn3.6 branch:  [log:branches/UKMO/dev_r5518_GSI7_GSI8_landice_bitcomp_medusa dev_r5518_GSI7_GSI8_landice_bitcomp_medusa]
+* Merged in  [log:branches/UKMO/dev_r5518_coupling_GSI7_GSI8_landice_bitcomp dev_r5518_coupling_GSI7_GSI8_landice_bitcomp] at revision 6659
+* Added MEDUSA-specific coupling interface changes to sbccpl.F90 (revisions 6659-6670 inclusive). NOTE: These are not finalised in any sense since we have no UM/coupler source for the incoming dust, the incoming f_pco2a field is not defined as a 2D field in MEDUSA, merely as a single value scalar and the f_co2flux2d probably has nowhere to go in the UM while bugs remain to be fixed in the UM TRIFFID scheme. 
+* So the only field we might reasonably couple and expect to deal with realistically at the moment is the MEDUSA->UM DMS field.    
+
+'''Testing'''
+
+* Compilation: Using a copy of u-ad903 we have successful compilation. BUT to achieve this I have to take a copy of Julien's [log:branches/NERC/dev_r5518_NOC_MEDUSA_Stable dev_r5518_NOC_MEDUSA_Stable] and make modifications to ensure that various necessary fields are made publicly  available in order to allow them to be referenced in the main NEMO code. The method of doing this is to move the declaration of the necessary fields to the top of the appropriate module definition. This is not necessarily ideal since there are numerous similar variables not required for coupling which remain defined within subroutines in the modules. It may be that an alternative approach is to define the coupling fields within sbccpl or cpl_oasis and then have those referenced by the MEDUSA code. This approach may also allow us to dispense with CPP keys in the main NEMO code but does have the overhead of needing MEDUSA to copy the fields to and from their ultimate target and source arrays. 
+
+  
+
+