om3Xcoarse model ================ A cross-breed between om3_core3 and CM2M_coarse_BLING . This is an attempt to create a ocean-only model on coarse grid. It uses the code from om3_core , and ocean grid and ocean-data from CM2M_coarse_BLING, atmos and land grid, as well as ocean and land forcing data from om3_core. Model resolutions: om3Xcoarse CM2M_coarse_BLING om3_core Ocean: 120x80x23 120x80x23 360x200x50 Land: 144x90 96x60 144x90 Atmos: 144x90 96x60 144x90 Supergrid resolutions: Ocean: 240x160 240x160 720x400 Land: same as atmos Atmos: 288x180 192x120 288x180 input.nml , data_table , field_table , diag_table are initially taken from om3_core . Subsequently, input.nml, data table, and field_table are modified to be more similar to CM2M_coarse_BLING, because those parameters are more suited for the coarser resolution than those from om3_core. Increase all occurences of diag_step and energy_diag_step, their default values cause much computation overhead, whic his not needed for our purposes. For speedup, exploit larger timesteps: Increase dt_cpld, dt_atmos, dt_ocean from 7200 to 28800, and baroclinic_split from 1 to 4. This gives significant speedup, with vanishing difference in results. Further: om3_core uses both bryan_lewis_diffusivity and ocean_vert_tidal mixing enabled, while CM2M_coarse_BLING does not use bryan_lewis, which is more apropriate. Thus, disable bryan_lewis in the input.nml, and copy tidal mixing parameters from CM2M_coarse_BLING. This improves speed, and causes only minimal changes in the results (maybe those changes are even improvements). field_table modifications: In the "xland_mix" , "xland_insert" , and "diff_cbt_enhance" sections, remove all the "xland" and "diffcbt" entries, and replace them with the entries of the corresponding section from CM2M_coarse_BLING's field_table. data_table modifications: Set "ongrid" to .false. for files that are not regridded to new ocean resolution (see overview below) Comment-out the entries for c14o2_flux_abiotic_pcair_atm and co2_flux_abiotic_pcair_atm. also the corresponding tracer definitions in the field_table. (the corresponding data files are then not really needed anymore in the INPUT/ directory) field_table modifications: om3_core's field_table contains definitons for many tracers that we are not interested in. Remove all of them, except for temp and salt, which are required in the code. According to previous PIK research results, Prather Second Order Moments advection scheme is superior. Thus set the horizontal and vertical advection scheme of those two remining tracers to psom, even though it costs about 20% more compute time. ERROR: as we found out during Moritz Kreuzers work, the PSOM implementation in MOM5 is broken by design :-( Thus, dont use it! ### ### Overview of data files that are used in om3_core ### ## specified in the data_table cfc.bc.nc # ATM, ongrid=false 360x200 ocmip2_siple_co2_atm_am2_bc-1-9999.nc # ATM, ongrid=true - in adapted resolution from CM2M_coarse_BLING? # om3_core: 144x90 , CM2M_coarse_BLING: 96x60 # history = "OCMIP2 historical CO2 boundary conditions created from splco2.dat using /archive/jes/fms/coarse_cm/grids/cm_om1p5_m30_grid_spec.nc" # the file contains geographically uniform values for each time slice, so that # regridding is not critical. slp_.nc # ATM, ongrid=false 192x94 q_10_mod.clim.nc # ATM, ongrid=false 192x94 t_10_mod.clim.nc # ATM, ongrid=false u_10_mod.clim.nc # ATM, ongrid=false v_10_mod.clim.nc # ATM, ongrid=false ncar_precip_clim.nc # ICE, ongrid=false 192x94 ncar_rad_clim.nc # ICE, ongrid=false # maybe we can simply set ongrid=false with coarse resolution ??? RUNOFF.nc # ICE, ongrid=true 360x200 # -> no we cannot. Although the metadata in that files does not show it, # this is already regridded onto tripolar grid. It gets obvious when # viewing in ferret or ncview against the land-contour overlay. # There, the runoff that is meant to come from siberian coast # appears just across the middle of the arctic sea. # That means, we must indeed either # a) create a properly regridded tripolar runoff forcing, or # b) use a non-regridded but regular-lat-lon-grid - and thoroughly check if what # the model sees as input is really what we intend to ... # http://data1.gfdl.noaa.gov/~nnz/mom4/COREv2/data_NYF/CORRECTED/runoff.15JUNE2009.nc # seems to the source file that was used to generate the tripolar RUNOFF.nc # It has the land cells set to missing-values. However, when the coupler interpolates # the input from this file onto the ocean grid, it does not exactly fit the # ocean model's land-sea-mask, thus some missing-values enter the ocean model # as runoff values, leading to an early model crash. Thus: cdo setmiss 0.0 runoff.15JUNE2009.nc runoff.15JUNE2009-zeroed.nc # and specify this file in the data_table Anthony Bosse wrote on 1. April 2011: As suggested during the last ocean meeting, I have modified the output runoff computed by the model by adding runoff at the coastal area per hand where there was many runoff going on land. There is 7% less global runoff than in the original file, so it lies yet within the 10% interval. This produced a new file on the tripolar grid which can be found under: /iplex/01/climber3/bosse/mom4p1_pubrel_18dec2009/work/om3Xcoarse_matthias/INPUT/new_runoff.nc and can be used as input for the model. I have just tested it and it works well. Just specified on data_table "ICE" , "runoff" , "RUNOUT" , "./INPUT/new_runoff.nc" , .true. , 1.0 sst_ice_clim.nc # ICE, ongrid=false 360x180 and 180x91 ## data files that are used by shared/oda_tools # they seem to contain trace data from floating buoys # not on any grid, can be taken from om3_core CTDO1990.nc DRBO1990.nc MBTO1990.nc MRBO1990.nc OSDO1990.nc XBTO1990.nc ## independent of resolution - regridded on-the-fly in topography module # identical file in all GFDL-provided model setups navy_topography.data.nc ## some files are available in coarsened resolution from CM2M_coarse_BLING basin_mask.nc chl.nc mixdownslope_mask.nc restore_mask.nc roughness_amp.nc tideamp.nc # two restart files, specified in field_table, available in CM2M_coarse_BLING ocean_temp_salt.res.nc ocean_age.res.nc ## only in om3_core ocmip2_abiotic_c14_atm_hist_om3_bc-1-9999.nc # # history = "C14 boundary conditions created from c14.dat using /home/rds/iron-fert/om3/input/fe_dep_ginoux_gregg_om3_bc.nc" # # this file is specified in field_table; 360x200, ocean grid # "namelists","ocean_mod","ocmip2_abiotic/abiotic" # frac_14catm_file = INPUT/ocmip2_abiotic_c14_atm_hist_om3_bc-1-9999.nc # frac_14catm_name = C14 # / # # This gives the concentration of isotope C14. # In the first timesteps it is uniform across the planet. # In timesteps 193 to 206 it is divided into three latitudinal belts: < -20S, -20S..20N, > 20N # There is a steep peak in timestep 203. # This pattern corresponds to the nuclear weapon tests performed in the 1960s. # See also ocmip2_abiotic_c14.gif # # 235 timesteps: # ncview: 23-Dec-2000, 23-Jun-3764, ...(annual)... , 23-Jun-3995, 23-Dec-3999, 23-Dec-11998 # ferret: 01-JAN-0001, Jul 1764, ... , Dec 1999, 01-JAN-9999 # cdo: 0001-01-01 , 1763-04-29, ...(annual)... , 1994-03-04, 1998-09-02, 9992-05-11 # # Regridding this file should be non-critical, because it contains only # very coarse-resolution features. # However, it is defined with uneven latitudinal resolution, like the tripolar ocean grid, # thus should most probably be regridded with FMS tools. # two files that seem to be regridded from levitus data? # They are defined on the tripolar ocean grid. salt_sfc_restore.nc temp_sfc_restore.nc # Somewhere on the GFDL FTP server there is a preprocessing.tar archive, # available in the vicinity of some early MOM4 version, # which halso contains files with these names. # That temp_sfc_restore.nc has only minor differences in metadata, # compared to om3_core distribution for the 18dec2009 version, but exactly # the same data values. The salt_sfc_restore.nc have differences in the data, # mainly over land (where it should not matter), but also in the arctic region, # Amazon inflow, and pacific ocean. # The file from om3_core has land values masked out - but only in some time steps. # # now collect input data files # cp -p ../../../exp/om3_core1/INPUT/navy_topography.data.nc . # station data from floating buoys for shared/oda_tools/ cp -p ../../../exp/om3_core1/INPUT/CTDO1990.nc \ ../../../exp/om3_core1/INPUT/DRBO1990.nc \ ../../../exp/om3_core1/INPUT/MBTO1990.nc \ ../../../exp/om3_core1/INPUT/MRBO1990.nc \ ../../../exp/om3_core1/INPUT/OSDO1990.nc \ ../../../exp/om3_core1/INPUT/XBTO1990.nc \ . cp -p ../../../exp/om3_core1/INPUT/cfc.bc.nc \ ../../../exp/om3_core1/INPUT/ocmip2_siple_co2_atm_am2_bc-1-9999.nc \ ../../../exp/om3_core1/INPUT/slp_.nc \ ../../../exp/om3_core1/INPUT/?_10_mod.clim.nc \ ../../../exp/om3_core1/INPUT/ncar_*_clim.nc \ ../../../exp/om3_core1/INPUT/RUNOFF.nc \ ../../../exp/om3_core1/INPUT/sst_ice_clim.nc \ . cp -p ../../../exp/CM2M_coarse_BLING/INPUT/basin_mask.nc \ ../../../exp/CM2M_coarse_BLING/INPUT/chl.nc \ ../../../exp/CM2M_coarse_BLING/INPUT/mixdownslope_mask.nc \ ../../../exp/CM2M_coarse_BLING/INPUT/restore_mask.nc \ ../../../exp/CM2M_coarse_BLING/INPUT/roughness_amp.nc \ ../../../exp/CM2M_coarse_BLING/INPUT/tideamp.nc \ ../../../exp/CM2M_coarse_BLING/INPUT/ocean_temp_salt.res.nc \ ../../../exp/CM2M_coarse_BLING/INPUT/ocean_age.res.nc \ . # the last 3 files still need to be regridded (!?!) cp -p ../../../exp/om3_core1/INPUT/ocmip2_abiotic_c14_atm_hist_om3_bc-1-9999.nc . cp -p ../../../exp/om3_core1/INPUT/salt_sfc_restore.nc \ ../../../exp/om3_core1/INPUT/temp_sfc_restore.nc \ . # # begin of grid generation # mkdir -p exp/om3_coarse/INPUT cd exp/om3_coarse/INPUT cp -p ../../../exp/CM2M_coarse_BLING/INPUT/ocean_mosaic.nc \ ../../../exp/CM2M_coarse_BLING/INPUT/ocean_hgrid.nc \ ../../../exp/CM2M_coarse_BLING/INPUT/ocean_vgrid.nc \ ../../../exp/CM2M_coarse_BLING/INPUT/topog.nc \ . cp -p ../../../exp/om3_core1/INPUT/land_hgrid.nc \ ../../../exp/om3_core1/INPUT/land_mosaic.nc \ ../../../exp/om3_core1/INPUT/atmos_hgrid.nc \ ../../../exp/om3_core1/INPUT/atmos_mosaic.nc \ . # the make_coupler_mosaic tool requires a dimension named ntiles # but this not contained in the GFDL-provided topog.nc files # sigh. the name topog.nc is hardcoded in the ocean topography module ncap2 -o topog-ntiles.nc -s 'defdim("ntiles",1)' ../../../exp/CM2M_coarse_BLING/INPUT/topog.nc mv topog-ntiles.nc topog.nc ../../../src/tools/make_coupler_mosaic/make_coupler_mosaic \ --ocean_mosaic ocean_mosaic.nc \ --land_mosaic land_mosaic.nc \ --atmos_mosaic atmos_mosaic.nc \ --ocean_topog topog.nc \ --check mv -i mosaic.nc grid_spec.nc # # end of grid generation - successful # # # Do the regridding # ../../../src/tools/fregrid/fregrid \ --input_mosaic ../../om3_core1/INPUT/ocean_mosaic.nc \ --output_mosaic ./ocean_mosaic.nc \ --input_dir ../../om3_core1/INPUT \ --input_file salt_sfc_restore.nc \ --scalar_field salt # sigh. correct metadata for the fregrid tool ncatted -o temp_sfc_restore+cartesian.nc -a cartesian_axis\,MONTH_IRREG\,c\,c\,T temp_sfc_restore.nc ../../../src/tools/fregrid/fregrid \ --input_mosaic ../../om3_core1/INPUT/ocean_mosaic.nc \ --output_mosaic ./ocean_mosaic.nc \ --input_file temp_sfc_restore+cartesian.nc \ --output_file temp_sfc_restore.nc \ --scalar_field temp ncatted -o ocmip2_abiotic_c14_atm_hist_om3_bc-1-9999+cartesian.nc \ -a cartesian_axis\,TIME\,c\,c\,T \ ../../om3_core1/INPUT/ocmip2_abiotic_c14_atm_hist_om3_bc-1-9999.nc ../../../src/tools/fregrid/fregrid \ --input_mosaic ../../om3_core1/INPUT/ocean_mosaic.nc \ --output_mosaic ./ocean_mosaic.nc \ --input_file ocmip2_abiotic_c14_atm_hist_om3_bc-1-9999+cartesian.nc \ --output_file ocmip2_abiotic_c14_atm_hist_om3_bc-1-9999.nc \ --scalar_field C14 ### Bad temperature= 0.585E+95 at i= 35 pe= 0 Bad temperature= 0.585E+95 at i= 36 pe= 0 Bad temperature= 0.585E+95 at i= 37 pe= 0 Bad temperature= 0.585E+95 at i= 38 pe= 0 Bad temperature= 0.748E+95 at i= 157 pe= 0 Bad temperature= 0.748E+95 at i= 158 pe= 0 Bad temperature= 0.748E+95 at i= 159 pe= 0 Bad temperature= 0.748E+95 at i= 160 pe= 0 Bad temperature= 0.748E+95 at i= 161 pe= 0 Bad temperature= 0.748E+95 at i= 162 pe= 0 Bad temperature= 0.748E+95 at i= 163 pe= 0 Bad temperature= 0.748E+95 at i= 164 pe= 0 Bad temperature= 0.747E+95 at i= 173 pe= 0 Bad temperature= 0.747E+95 at i= 174 pe= 0 Bad temperature= 0.585E+95 at i= 175 pe= 0 Bad temperature= 0.581E+95 at i= 176 pe= 0 Bad temperature= 0.585E+95 at i= 177 pe= 0 Bad temperature= 0.581E+95 at i= 178 pe= 0 Bad temperature= 0.585E+95 at i= 179 pe= 0 Bad temperature= 0.585E+95 at i= 181 pe= 0 Bad temperature= 0.748E+95 at i= 295 pe= 0 Bad temperature= 0.748E+95 at i= 296 pe= 0 Bad temperature= 0.748E+95 at i= 297 pe= 0 Bad temperature= 0.748E+95 at i= 298 pe= 0 Bad temperature= 0.748E+95 at i= 299 pe= 0 Bad temperature= 0.748E+95 at i= 300 pe= 0 Bad temperature= 0.748E+95 at i= 301 pe= 0 Bad temperature= 0.748E+95 at i= 302 pe= 0 Bad temperature= 0.747E+95 at i= 311 pe= 0 Bad temperature= 0.747E+95 at i= 312 pe= 0 Bad temperature= 0.581E+95 at i= 313 pe= 0 Bad temperature= 0.581E+95 at i= 314 pe= 0 Bad temperature= 0.748E+95 at i= 474 pe= 0 Bad temperature= 0.748E+95 at i= 477 pe= 0 Bad temperature= 0.748E+95 at i= 478 pe= 0 Bad temperature= 0.748E+95 at i= 481 pe= 0 Bad temperature= 0.748E+95 at i= 482 pe= 0 Bad temperature= 0.748E+95 at i= 485 pe= 0 Bad temperature= 0.748E+95 at i= 486 pe= 0 Bad temperature= 0.748E+95 at i= 489 pe= 0 Bad temperature= 0.747E+95 at i= 506 pe= 0 Bad temperature= 0.747E+95 at i= 509 pe= 0 Bad temperature= 0.581E+95 at i= 513 pe= 0 Bad temperature= 0.582E+95 at i= 514 pe= 0 Bad temperature= 0.581E+95 at i= 515 pe= 0 Bad temperature= 0.582E+95 at i= 516 pe= 0 Bad temperature= 0.582E+95 at i= 809 pe= 0 Bad temperature= 0.747E+95 at i= 810 pe= 0 Bad temperature= 0.582E+95 at i= 811 pe= 0 Bad temperature= 0.747E+95 at i= 812 pe= 0 Bad temperature= 0.747E+95 at i= 1027 pe= 0 Bad temperature= 0.747E+95 at i= 1028 pe= 0 Bad temperature= 0.747E+95 at i= 1400 pe= 0 Bad temperature= 0.747E+95 at i= 1402 pe= 0 Bad temperature= 0.748E+95 at i= 14007 pe= 0 Bad temperature= 0.748E+95 at i= 14012 pe= 0 Bad temperature= 0.748E+95 at i= 14549 pe= 0 Bad temperature= 0.748E+95 at i= 14552 pe= 0 Bad temperature= 0.394E+95 at i= 20312 pe= 0 Bad temperature= 0.394E+95 at i= 20315 pe= 0 Bad temperature= 0.394E+95 at i= 20598 pe= 0 Bad temperature= 0.394E+95 at i= 20600 pe= 0 Bad temperature= 0.298E+95 at i= 22898 pe= 0 Bad temperature= 0.298E+95 at i= 22901 pe= 0 Bad temperature= 0.748E+95 at i= 24339 pe= 0 Bad temperature= 0.748E+95 at i= 24341 pe= 0 Bad temperature= 0.748E+95 at i= 24685 pe= 0 Bad temperature= 0.748E+95 at i= 24689 pe= 0 Bad temperature= 0.748E+95 at i= 24694 pe= 0 FATAL: lookup_es: saturation vapor pressure table overflow, nbad= 69 Ice%t_surf(1:120,1:80,1:6) Ocean%t_surf(120,80) (75,2) (76,2) (62,3) (63,3) (64,3) (65,3) (70,3) (75,3) (75,4) (75,5) (13,36) (18,55) (44,66) (68,79) bad values appear after first call to update_ocean_model() ocean_sfc%u_surf and %v_surf have mostly entries with value 1e-40 ??? in sum_ocean_sfc() , Ocean_sfc%t_surf is computed from sst(:,:) , which comes from T_prog(1)%field(:,:,1,taup1=1) Also, Ocean_sfc%s_surf is computed from T_prog(2)%field(:,:,1,taup1=1) and looks similarly bad. compute_frazil_heating(), called from update_ocean_tracer() if (freezing_temp_simple) then k=1 do j= do i= tfreeze = a1*T_Prog(index_salt%field(i,j,k,taup1) if (T_prog(index_temp)%field(i,j,k,taup1) < tfreeze) then T_prog(index_temp)%field(i,j,k,taup1) = tfreeze endif enddo enddo endif a1: -0.054 taup1: 1 k: 1 j: 75 i: 2 index_temp: 1 index_salt: 2 T_Prog(index_salt)%field(i,j,k,taup1) index 32,2,1,1: 1.7e93 index 75,2,1,1: -1e+96 index 31,3,1,1: 1.7e+93 invtri() line 192 ff. called from vert_diffuse_implicit() in ocean_vert_mix.F90 line 1760 T_prog(salt_index)%field(:,:,:,taup1) is passed as parameter z ! decomposition and forward substitution array f() contains strange values array mask is at bad address ??? comes from Grd%tmask line 186 ! top and bottom b.c. f(i,1) = z(i,j,1) + topbc(i,j)*tdt_aidif*mask(i,j,1)/dh(i,j,1) i: 32 j: 2 z(32,2,1): 34.089 tdt_aidif: 7200 topbc(32,2): 2.57e+93 :-( second parameter passed from T_prog(2)%stf dh(32,2,1): 1 z = Grd%tmask(32,2,1): 1.0 T_prog(2)%stf(32,2) gets its bad value in flux_adjust() line 3380 in ocean_sbc.F90 from array flx_restore; called from update_ocean_model() line 1230 . line 3350: flx_restore(75,2): -1.99e+96 flx_restore(76,2): -1.99e+96 salt_damp_factor: 0.00199 data(75,2): -1e99 data(76,2): -1e99 data(77,2): 34.58 Array data seems to come from reading restore file data, this looks like a regridding error in the region of the Weddel Sea. The land-sea mask that is obtained from topog.nc does not match the land-sea-mask that is implicitly contained in the restore file in form of missing-values. topog.nc was copied from CM2M_coarse_BLING, while the restore file was regridded using the copied grid specification. See data excerpts below. Possible solutions that come to mind: 1. hand-edit the regridded salt_sfc_restore.nc 2. try with different regridding tool (using traditional instead of mosaic grid description) 3. try to regrid from ``original'' levitus data set, not from om3_core. Wherever to get such thing from. -> levitus_ewg.nc 4. Extract surface salinity from CM2M_coarse_BLING/INPUT/ocean_temp_salt.res.nc , which should at least be defined on the same land-sea-mask as the corresponding topog.nc =========== The above regridded file salt_sfc_restore.nc contains this same values for variable salt. salt(73,2,:): -99 ... salt(76,2,:): -99 salt(77,2,:): 34.58 ... salt(87,2,:): 34.09 salt(88,2,:): -99 grid_x_T(73)=-67.5 grid_y_T(2)=-76.5094 time(1)=0.5 salt(193)=-99 psu grid_x_T(74)=-64.5 grid_y_T(2)=-76.5094 time(1)=0.5 salt(194)=-99 psu grid_x_T(75)=-61.5 grid_y_T(2)=-76.5094 time(1)=0.5 salt(195)=-99 psu grid_x_T(76)=-58.5 grid_y_T(2)=-76.5094 time(1)=0.5 salt(196)=-99 psu Original salt_sfc_restore.nc from om3_core: grid_x_T(211)=-69.5 grid_y_T(6)=-76.5 time(1)=0.5 salt(2011)=-99 psu grid_x_T(212)=-68.5 grid_y_T(6)=-76.5 time(1)=0.5 salt(2012)=-99 psu grid_x_T(213)=-67.5 grid_y_T(6)=-76.5 time(1)=0.5 salt(2013)=-99 psu grid_x_T(214)=-66.5 grid_y_T(6)=-76.5 time(1)=0.5 salt(2014)=-99 psu grid_x_T(215)=-65.5 grid_y_T(6)=-76.5 time(1)=0.5 salt(2015)=-99 psu grid_x_T(216)=-64.5 grid_y_T(6)=-76.5 time(1)=0.5 salt(2016)=-99 psu grid_x_T(217)=-63.5 grid_y_T(6)=-76.5 time(1)=0.5 salt(2017)=-99 psu grid_x_T(218)=-62.5 grid_y_T(6)=-76.5 time(1)=0.5 salt(2018)=-99 psu grid_x_T(219)=-61.5 grid_y_T(6)=-76.5 time(1)=0.5 salt(2019)=-99 psu grid_x_T(220)=-60.5 grid_y_T(6)=-76.5 time(1)=0.5 salt(2020)=-99 psu grid_x_T(221)=-59.5 grid_y_T(6)=-76.5 time(1)=0.5 salt(2021)=-99 psu grid_x_T(222)=-58.5 grid_y_T(6)=-76.5 time(1)=0.5 salt(2022)=-99 psu grid_x_T(223)=-57.5 grid_y_T(6)=-76.5 time(1)=0.5 salt(2023)=-99 psu grid_x_T(224)=-56.5 grid_y_T(6)=-76.5 time(1)=0.5 salt(2024)=-99 psu grid_x_T(225)=-55.5 grid_y_T(6)=-76.5 time(1)=0.5 salt(2025)=-99 psu grid_x_T(226)=-54.5 grid_y_T(6)=-76.5 time(1)=0.5 salt(2026)=-99 psu grid_x_T(227)=-53.5 grid_y_T(6)=-76.5 time(1)=0.5 salt(2027)=34.6413002014 psu grid_x_T(228)=-52.5 grid_y_T(6)=-76.5 time(1)=0.5 salt(2028)=34.6348991394 psu grid_x_T(229)=-51.5 grid_y_T(6)=-76.5 time(1)=0.5 salt(2029)=34.6273002625 psu The topog.nc file contains depth(73,0): 0 depth(74,2): 0 depth(75,2): 249.54 depth(76,2): 424.92 ... depth(87,2): 506.61 depth(88,2): 0 depth(89,2): 0 ============ Approach 4.: ncks -F -v salt -d zaxis_1\,1 -o salt_sfc_restore.nc-extracted-from-CM2M_coarse_BLING \ ../../CM2M_coarse_BLING/INPUT/ocean_temp_salt.res.nc ncatted -a units\,Time\,m\,c\,'days since 1900-01-01 00:00:00' \ -a calendar_type\,Time\,c\,c\,NOLEAP \ -a modulo\,Time\,c\,c\,' ' \ salt_sfc_restore.nc-extracted-from-CM2M_coarse_BLING ln -s salt_sfc_restore.nc-extracted-from-CM2M_coarse_BLING salt_sfc_restore.nc The ocean_temp_salt.res.nc from the CM2M_coarse_BLING distribution, for their first timestep at time 1-Jan-0002, looks more similar to the levitus_ewg.nc than the salt_sfc_restore.nc from the om3_core distribution. The latter shows an overall tendency to 34.something PSU, while the former two data sets tend to 35.something. Next experiment: On July 5th, 2011, Matthias Hofmann wrote: I have had a look into your mom4.1 simulations. The distribution diff_cbt seems to be reasonable. However, there are several spots in the Pacific Ocean (over rough topography) showing very high diffusivities inside the whole water column. In order to test the impact of topography on vertical diffusivities we should conduct a further experiment (500 - 1000 years) with "use_wave_dissipation=.false." and "use_drag_dissipation=.false.". -------------------- Wed Nov 4 10:11:47 CET 2020 Back-Port improvements and corrections made to CM2M_coarse_BLING into om3Xcoarse. Copied from CM2M_coarse_BLING/README: ++++++++++ https://groups.google.com/forum/#!topic/mom-users/GhmoD6IYvxM On Mon, Jun 8, 2015 at 4:42 PM, Elizabeth Maroon wrote: I've been trying to spin up a coupled MOM5 simulation with the CM2M_coarse_BLING.output from the MOM test data repository, but the state that evolves has some problems. [..deep water starts forming in the North Pacific...AMOC completely shuts off...] I've been trying to figure out more about this coarse configuration. I originally started using it because it allows me to complete fully-coupled simulation on our local computers and to test out ideas relatively quickly. Is this configuration the same as the one used in Galbraith et al (2011) [http://journals.ametsoc.org/doi/abs/10.1175/2011JCLI3919.1] (CM2Mc) or a different one? The ocean model used in that paper did not seem to have a problem with north Pacific deep water. If the test case I've been using is not CM2Mc, is the CM2Mc configuration available anywhere? On Sun, Jun 14, 2015 at 3:53 PM, Eric Galbraith wrote: As far as I know, the CM2M_coarse_BLING model included in the repository is an updated version of what we called CM2Mc in the 2011 paper, and should be well suited for your interests. So, glad to hear you're trying to use it! However, the problem you describe sounds odd for a pre-industrial control run with CM2Mc. I have run many simulations with the model (using the MOM5 codebase, and my own namelists), and although it's possible to turn off the AMOC and turn on a PMOC as you described by hosing the North Atlantic with freshwater, I have never seen it happen otherwise. Normally the pre-industrial simulation looks pretty good - the North Pacific Intermediate Water tends to be a bit too strongly ventilated, but the AMOC chugs along at about 18 Sv. It's possible that one of the boundary condition files is inappropriate, or that something got mixed up in a namelist. If you'd like, you can download the following files, which should be all (most?) of the pieces required to run my most recent version: http://earth.cs.mcgill.ca/mom5_fv.tar http://earth.cs.mcgill.ca/CM2Mc.boundaryFiles.tar http://earth.cs.mcgill.ca/fms.tar http://earth.cs.mcgill.ca/siena_blingv2_y1_131014.cpio http://earth.cs.mcgill.ca/CM2Mc_v1p5_control The first tar file should contain all of the source code (Siena release) and the compile script. The second and third contain all of the required boundary condition files (and maybe some extras). The fourth is the initial conditions file. The last is the runscript. Perhaps you could try comparing the namelist settings directly, and see if there are any differences in the boundary condition files? The namelists might differ a bit, but the boundary condition files should be identical, I think, with the exception of the BLING files (these are for the biogeochemical module, which you probably aren't interested in, and which I've changed quite a bit). On Mon, Aug 17, 2015 at 5:24 PM, Elizabeth Maroon wrote: I wanted to let you know that I was able to produce a CM2Mc with a reasonable AMOC (and no PMOC) thanks to your help. There were many namelist differences in many modules, especially in the ice model and a couple in the ocean vertical tidal mixing module (as you correctly foresaw). I changed all of the namelist parameters that looked physically-relevant (rather than parameters that affect things like frequency of diagnostic-writing) to the ones that were default in your configuration. I also used your initial conditions (the defaults online had no orography in fv_rst.res.nc). I ran CM2Mc for more than 500 years and there was no hint of anything strange in the Pacific, so for my uses, this model will work great now. I've tried to backtrack to determine which module was the most at-fault in producing the weird climotology, but I haven't had much luck. I've run the model for 50 years with all of the working-parameters except with either the old tidal mixing parameters or ice model parameters. With the original parameters that I started with, it would only take 20-30 years before the Pacific would sink substantially, but in these runs with all the new parameters (except a few chosen ones), there was only deep sinking in the Atlantic. Figuring out which parameters are at fault is not a priority of mine (given other academic constraints), but if I have more time, I'd run your IC with all of the old parameters to determine if the new IC were instrumental in getting a stable configuration or if it was something in the namelists. For anyone in the future who has these issues, I've included at the bottom of this message the changes I made to the default CM2Mc namelists from the MOM5 data repository. --- Namelists changes --- [..] Marked in input.nml with comment ! EM ++++++++++ In the field table of Eric Galbraith et al (see above) there are some cross-land mixxing entries around Java, which are not in the ``official'' distribution. ++++++++++ On 22.09.20 19:31, Eric Galbraith wrote: > Hi Willem! > > Sorry to hear you're having trouble! I am not familiar with what has happened with the official GFDL release over the years - are there any other names listed in the code? Niki Zadeh perhaps? If so you might ask them. I haven't run the model myself in 5 or 6 years now (I'm doing global fishing and hunter gatherer models now). > > I think I originally used _b to indicate BLING tracers (vs. TOPAZ tracers, which had no such suffix). > > If you are running out of O2 and DIC specifically, I'd guess it's because you have an inconsistency in your air-sea boundary conditions. Perhaps the model is looking for the atmospheric pO2 and pCO2 with _b suffixes, and your boundary conditions are providing these without suffixes? Or vice versa? As I recall, there is no error for missing atmospheric pressures - it just sets the atmosphere to zero, which should cause rapid outgassing. -------------- Oct 7 2020 15:24 following Erics suggestions in his mail from 22.09.20 19:31 (see above), modified the ``official'' generic_BLING.F90 by removing all the _b suffixes from all tracer names. Also many tracer names in the file INPUT/ocean_bling.res.nc needed renaming accordingly. However, BLING is not (yet) used in our om3Xcoarse setup. ------------- Wed Nov 18 10:13:06 CET 2020 I have now merged our latest ocean parameterisation that we use in the LPJ coupling into the ocean+seaice setup. There are 1000 years of decadal output in /p/projects/climber3/petri/POEM/work/om3Xcoarse-EM3 history/ 29900101.*.nc In the same directory, there are still 500 years of daily output, produced accidentally. Just in case someone wants to have a look at, I leave it there for some days. But I think it is generally useless and will remove it next week. For comparison, output from the old setup is in /p/projects/climber3/petri/POEM/work/om3Xcoarse/history/29900101.*.nc The changes are in the input.nml, marked with comment ! EM , and in the field table, cross-land-parameterizations around Indonesia.