New URL for NEMO forge!   http://forge.nemo-ocean.eu

Since March 2022 along with NEMO 4.2 release, the code development moved to a self-hosted GitLab.
This present forge is now archived and remained online for history.
ticket/1658/General (diff) – NEMO

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


Ignore:
Timestamp:
2016-06-07T17:11:43+02:00 (8 years ago)
Author:
frrh
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • ticket/1658/General

    v3 v4  
    5353'''Testing''' 
    5454 
    55 * 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.  
     55* Compilation W/ MEDUSA: 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. However, for now we stick to CPP keys and our model compiles OK using the following 3 NEMO branches/WC's: 
     56 
     57   * /data/local/frrh/nemo_br/dev_r5518_GO6_package - My WC of the GO6 package branch featuring my extra changes from [log:branches/UKMO/dev_r5518_GSI7_GSI8_landice_bitcomp_medusa dev_r5518_GSI7_GSI8_landice_bitcomp_medusa] 
     58   * branches/UKMO/dev_r5518_GC3_couple_pkg - The GC3 coupling package branch 
     59   * /data/local/frrh/nemo_br/dev_r5518_RH_MEDUSA_Stable_mod - My WC of [log:branches/NERC/dev_r5518_NOC_MEDUSA_Stable dev_r5518_NOC_MEDUSA_Stable] with additions to make coupling fields available publicly.  
     60}}} 
     61 
     62 
     63* Compilation W/O MEDUSA: Using a copy of mi-aj246, named mi-aj246_CRUN_fix_MEDcode_Nomed which is just a NEMO_CICE job - I include  /data/local/frrh/nemo_br/dev_r5518_GO6_package - My WC of the GO6 package branch featuring my extra changes from [log:branches/UKMO/dev_r5518_GSI7_GSI8_landice_bitcomp_medusa dev_r5518_GSI7_GSI8_landice_bitcomp_medusa]. This compiles OK but fails in the run with an XIOS error because the iodef.xml file is incompatible with  
     64 
     65* Running W/O coupling:  
     66   * Using suite u-ad903, but with no special changes to the namcouple and no additional changes to the NEMO namsbc_cpl namelist, we have a successful run for 1 day. i.e. This is more or less a standard GC3 
     67set-up with MEDUSA included in the ocean component but no extra Atmos-MEDUSA coupling.  
     68 
     69* Running W/ coupling:   
     70   * We can't activate all the coupling fields because most of them are not ready.... f_pco2a is still a scalar value... it needs to be a 2d array in JP's MEDUSA branch. Dust cannot be coupled as we have no source term in the atmos, pending suitable code developments. MEDUSA CO2 flux is an unknown quantity due to unknown robustness of TRIFFID code. That leaves DMS. We'll try that.... 
     71 
     72   * Take a WC of our suite... u-ad903_dmsCouple.   
     73   * Modify NEMO namsbc_cpl to add entries for our four new fields with only DMS active. 
     74   * Modify the suite namcouple to add DMS (only).  
     75   * Submit.    
    5676 
    5777