Differences between spin-up and other suites

Introduction

Now that the ocean spin-up has been split so we now have two apps, nemo_cice and ocean_passive_tracers, we can now compare directly with a coupled jobs. I'm comparing the spin-up job I have, u-ak454, which I've taken from Julien's u-aj946 with my latest UKESM0.5, u-aj599.

At the bottom of the page, I've then go on to compare our spin-up with those of Adam Blaker and Dave Storkey.

Differences between spin-up and our coupled setup

The ocean_passive_tracers app

The differences in ocean_passive_tracers/rose-app.conf are

• In [namelist:namcfcdate], nyear_res=1600 for spin-up and 1000 in coupled job. The meta says that nyear_res is `Starting years of simulation', although it doesn't seem to agree with BASIS in rose-suite.conf
• [namelist:nammedsbc] is different. For spin-up

  [namelist:nammedsbc]
  bdustfer=.true.
  cn_dir='$MED_ATM_FORCING/'
  sn_dust='ai567_dust',-1,'dustdepo',.true.,.false.,'monthly','','',
         =''
  

  and for coupled

  [namelist:nammedsbc]
  bdustfer=.false.
  cn_dir='./'
  sn_dust='dust.orca',-1,'dust',.true.,.true.,'yearly','','',''
  

  The spin-up will need to use climatology for the dust, so this is probably fine.

The nemo_cice app

The differences in nemo_cice/rose-app.conf are

• Coupled model uses [file:subbasins.nc], spin-up doesn't - see [namelist:namptr] below
• Spin-up uses [file:weights_WOA13d1_2_eorca1_bilinear.nc], [file:weights_coreII_2_eorca1_bicubic.nc] & [file:weights_coreII_2_eorca1_bilinear.nc], but coupled doesn't. I don't know what these files are for
• In [namelist:forcing_nml] both calc_strair and calc_tsfc are true for spin-up and false for coupled. This is CICE, so difficult to know what differences these make.
• Lots of differences in [namelist:icefileds_mechred_nml], but I think these are all diagnostic differences.
• Lots of differences in [namelist:icefileds_nml], but I think these are all diagnostic differences.
• Differences in [namelist:icefileds_pond_nml], but I think these are all diagnostic differences.
• In [namelist:nambdy], nn_dyn2d_dta is 1 for spin-up and 3 for coupled. This is an open boundary (BDY) option and means that
  • Spin-up uses boundary data read from bdydata.nc files
  • Coupled run uses 'external data AND tidal harmonic forcing'
  Presumably the coupled model can provide some boundary conditions, hence this difference.
• In [namelist:namberg], nn_sample_rate is 60 for spin-up and 32 for coupled. Timestep between sampling for trajectory storage
• In [namelist:namdyn_hpg, spin-up has ln_hpg_isf set to false, but this doesn't appear in coupled job. ln_hpg_isf is 'S-coordinate (sco) adapted for use with ice shelves', and I guess false is probably the same as undefined
• In [namelist:namdyn_ldf], rn_ahmb_0=0.0 is included in spin-up, but commented out in coupled job. rn_ahmb should be commented out if ln_dynldf_iso is not true, which is the case
• In [namelist:namnc4], nn_chunks_k=31 for spin-up and =75 for coupled. I think this is just an option for writing netCDF output, so not very important.
• In [namelist:namptr], ln_diaptr is false for spin-up and true for coupled, and ln_subbas is only defined for coupled where it is true. Set ln_diaptr to true to use poleward heat & salt transport module. If ln_diaptr is set to true, it opens up the options ln_diaznl, ln_subbas (which needs subbasins.nc file, see top item), ln_ptrcomp, nn_fptr and nn_fwri
• In [namelist:namrun], nn_stock and nn_write are different, but I expect that.
• In [namelist:namsbc] (surface boundary conditions),
  • ln_blk_core is true for spin-up and false for coupled. If true, use CORE Bulk formulae
  • ln_cpl is undefined for spin-up and true for coupled
  • ln_mixcpl is undefined for spin-up and false for coupled
  • ln_ssr is true for spin-up and false for coupled. If true, use sea surface restoring (requires namsbc_ssr to be set up)
  • nn_fwb is 3 for spin-up and 0 for coupled. This is control of freshwater, 3 for `Global E-P set to zero and spread over erp area' and 0 for `unchecked'.
  • nn_components is undefined for spin-up and 0 for coupled
  • nn_limflx is undefined for spin-up and -1 for coupled
  • nn_lsm is undefined for spin-up and 0 for coupled
  ln_cpl, ln_mixcpl, nn_components, nn_limflx, nn_lsm don't have rose meta data so hard to know what they're for, but presumably they all apply to coupling.
• In [namelist:namsbc_core], different forcing files used. We use our 30 years of forcing files for spin-up and centrally located files for coupled job
• In [namelist:namsbc_cpl], lot of differences as you'd expect for this coupling namelist.
• In [namelist:namsbc_isf]
  • ln_divisf is true for spin-up and undefined for coupled. If ln_divisf is true, apply isf melting as a mass flux or in the salinity trend
  • For sn_depmax_isf, sn_depmin_isf & sn_rnfisf, the 2nd argument is -1 for spin-up and -12 for coupled. The 2nd argument is frequency of data, where negative means months - so looks fine
• In [namelist:namsbc_rnf]
  • ln_rnf_depth_ini is undefined for spin-up and false for coupled. No meta data.
  • ln_rnf_mouth is true for spin-up and false for coupled. `Specific treatment at river mouths'
  • nn_rnf_depth_file & rn_dep_max are undefined for spin-up but =0 & 150. for coupled. No meta data.
  • sn_cnf uses 'socoeff' for spin-up and 'socoefr' for coupled. It's the variable name, so it's probably just different for the different files they're reading
  • sn_rnf: the jobs use different files, and the fifth argument is false for spin-up and true for coupled. The fifth argument is true if the data is climatology
• In [namelist:namsbc_ssr] (see ln_ssr option above, which says this section is needed if ln_ssr is true, as for coupled job. I think all the differences will be a consequence of this.)
  • ln_sssr_bnd is true for spin-up and undefined for coupled
  • nn_sssr is 2 for spin-up and 0 for coupled
  • nn_sstr is 1 for spin-up and 0 for coupled
  • rn_deds, rn_dqdt, rn_sssr_bnd, sn_sss, sn_sst are defined for spin-up, but not for coupled
• In [namelist:nametra_ldf], rn_ahtb_0 is undefined for spin-up and 0.0 for coupled. The normal setting is 0.0, so I think these options will amount to the same thing.
• In [namelist:namtrd], ln_tra_trd is false for spin-up and true for coupled. I've come across this before and I think it's just a diagnostic trend.
• In [namelist:namtsd], ln_tsd_init and ln_tsd_tradmp are true and false for spin-up but undefined for coupled
• There are a lot of differences in [namelist:setup_nml] but I think these are science changes

Summary of what might be key differences

• Spin-up includes [file:weights_WOA13d1_2_eorca1_bilinear.nc], [file:weights_coreII_2_eorca1_bicubic.nc] & [file:weights_coreII_2_eorca1_bilinear.nc] and I don't know what they're for
• Both CICE options calc_strair and calc_tsfc are true for spin-up and false for coupled
• Coupled run has ln_diaptr set to true, which uses the poleward heat and salt transport model, but it's false for spin-up.
• The spin-up uses sea surface restoring.
• There seems to be different different treatment of river mouths.

Differences between our spin-up and other configurations

The job's I'm comparing are

• Julien's u-ak454
• Adam's u-ah006
• Dave's u-ah494 (this is ORCA025)

I'm trying to ignore diagnostic differences

• nn_sample_rate (timesteps between sampling fro trajectory storage). I think this should be units of days, which is a multiple of 32. It should probably be 32. Dave agrees.
• ln_diaptr (use poleward heat & salf transport module). I'm not sure about - module says is does not work with lk_vvl. It's a diagnostic, so not massively important, but Dave thinks we should have it on
• ln_dm2dc (approximate diurnal cycle of solar forcing from daily mean data). I think the frequency of our input is better than diurnal, so I think this is OK. Dave agrees.
• nn_fwb (control of freshwater budget: 0 is unchecked and 3 is Global E-P set to zero and spread over erp area). I don't know. Dave think this was conscious decision from Till to have this turned on.
• nn_sstr (temperature restoring: 1 is add retroaction to SST, 0 is don't). Probably change to 0 like the others. Dave agrees.
• rn_deds. I think our current setup is a typo, and it should be -33.333 like the others. Dave says this is massive, I will affect the AMOC (he wasn't sure in which direction). Julien says this is deliberate done to keep the ocean more closely locked to the SSS (and SST) forcing from the atmosphere. With it the AMOC is about 14 sv, without it was 8-9 sv.
• 5th arg to sn_sss. We probably don't want climatology, so I think this is fine. Dave agrees.