$Id$ Wed 12 Feb 2020 Anders Levermann poses the idea to configure a model to investigate a theory about monsoon formation that he had put up some time ago. A simplified planet, with two circumglobal land belts north and south of the equator. Atmosphere GCM , i.e. AM2; Ocean replaced by prescribed SST, to avoid spinup costs. land_lad , flat topography. Ensemble runs: vary distance and width of the two land belts. We already use a similar setup with atmosphere Aeolus and fixed ocean surface, named Aeolus_lad-init-21-mar-clim . But for monsoon investigation, Aeolus does not yet seem to be usable. * What grid resolution is required to actually get Monsoon? (on the assumption that the atmosphere model has the potential at all) AL> The GCM atmosphere definitely has the ability to demonstrate a monsoon. The current global models all show monsoon systems which I reasonably realistic. So the currently used atmospheric resolution of CMIP-6 climate models is definitely sufficient. We can go coarser if that is not feasible, but we should try to be as fine as we can afford with an atmosphere only model. * what SST forcing data to use? The coupler just needs a NetCDF file on regular lat-lon grid. It does regridding in space and time at run time on the fly. We only need to adjust the metadata in a suitable fashion. AL> The SST can be set uniformly along a latitude and the latitudinal distribution can be taken from the currently observed field (for example the zonally averaged SST field?). It is not really crucial how this is set precisely, BUT it is important that the season cycle is included. So probably, I should produce a time-dependent zonally averaged SST field from observations and use this to populate a 2D field which is varying within a year according to the seasonal cycle. * In above-mentioned Aeolus_lad-init-21-mar-clim setup, besides SST also some other surface data sets are used: - albedo, including sea-ice albedo - roughness - set to global uniform values - surface currents speeds - set to zero (see data_table in above-mentioned setup) AL> We do not really need sea ice. [roughness] Not needed [surface currents speed] Can be used also in our new set-up. * how to handle river runoff? on flat land surface, probably just distribute uniform along coasts. -> But without real ocean, that should not really matter. AL> The simplest river-runoff scheme possible (I remember in C3a we had something like "uniform-coast" which would be fine. * on real Earth, monsoon depends on mountain topography (Himalaya) ? Apparently it is part of Anders' theory to show that monsoon can also work an flat topography (?) AL> And it does :) ... The mountain stuff is extra :) * Iff using a full MOM5 ocean: - circumglobal land belts create 3 disjoint ocean basins. Especially the one at the equator could easily become numerically unstable, - a tripolar ocean grid does not make sense in this case, without Antarctica, and without land in the vicinity of the North Pole. -> use regular grid. However, that most probably requires some kind of filtering around the grid singularities, but filter code might have been removed from MOM5? AL> I think it would be good to avoid a 3d ocean if at all possible. ----------- Mon Mar 23 13:09:56 CET 2020 Lets start with the atmosphere configuration of CM2.1p1 144x90 cells = 2.5x2 deg resolution. (ESM2M_pi-control_C2 uses the same atmos and ocean grid as CM2.1p1) (The AM3 and AM4 configurations use a cubed-sphere grid :-( -------- Wed Mar 25 23:28:54 CET 2020 Looking at ERA-Interim: sstk is defined on ocean only. e.g. it does not have any values for antarctica. skt and t2m are on land surface, thus too cold in polar regions. Lets try sealevel temperatur t_1000mb. Vivien had downloaded daily values 1979-2019 for her work in /p/projects/climber3/atm_data/ERA_Interim/uvt_pressure_levels/ However , 2019 is not yet complete in that downloaded data, so lets limit to 1979-2018. cd /p/projects/climber3/petri/Jetstream-Vis/ECMWF ln -s ../../../atm_data/ERA_Interim/uvt_pressure_levels/???? . rm 2019 cdo -b F32 enlarge\,2018/uvt_EI_daily_mean_2018_12.nc \ -ydaymean -zonmean -sellevel\,1000 -selvar\,t \ -cat '????/uvt_EI_daily_mean_????_??.nc' \ t-daily-1000-90S-90N-1979-2019-ydaymean-zonmean-enlarged.nc ------------ 0. Lets start with an artifical orography map: two circumglobal stripes , 10 deg wide, equatorwards boundary at +/- 10deg. mkdir INPUT cd INPUT cp -p ../../CM2.1p1/INPUT/atmos_hgrid.nc . cd .. use "INPUT/atmos_hgrid.nc" let xbounds='x'[Y=1] let ybounds='y'[X=1] define axis/X/edges/units=degrees_east X=xbounds define axis/Y/edges/units=degrees_north Y=ybounds def grid/x=x/y=y xygrid let y_y=y[gy=xygrid] let xyvar=0*'x'[d=1,gxy=xygrid@asn]-3000 let horo = if (y_y gt 20) or (y_y lt 10 and y_y gt -10) or (y_y lt -20) then xyvar else 10 def att/output horo.long_name="orography height" def att/output/type=string horo.units="m" save/clobber/file=horo-10-10.nc horo 1a. use the horizontal atmos grid from CM2.1p1 also for ocean, ice and land 1b. Generate ocean mosaic ../../../src/tools/make_solo_mosaic/make_solo_mosaic \ --num_tiles 1 --dir ./ --mosaic_name ocean_mosaic \ --tile_file atmos_hgrid.nc --periodx 360 1c. The ocean vertical grid of CM2.1p1 has 50 levels, which the make_topog tool remarks as ``wasteful'' for our case. #cp -p ../../CM2.1p1/INPUT/ocean_vgrid.nc . ../../../src/tools/make_vgrid/make_vgrid \ --center c_cell \ --grid_name ocean_vgrid \ --nbnds 4 --bnds 0\,70\,200\,3000 --nz 4\,2\,2 1d. Generate ocean topography ../../../src/tools/make_topog/make_topog \ --verbose \ --mosaic ocean_mosaic.nc \ --topog_type realistic \ --vgrid_file ocean_vgrid.nc \ --topog_file ../horo-10-10.nc --topog_field HORO --scale_factor -1 \ --bottom_depth 3000 \ --output topog.nc ==>NOTE from get_boundary_type: x_boundary_type is cyclic ==>NOTE from get_boundary_type: y_boundary_type is solid_walls Note: The vertical grid specification contains the correct number of levels to efficiently contain the specified topography. Warning: very thin partial cell at 6, 2 (possibly because of netcdf-accuracy) is changed from 3000 to 3000 If this is not wanted, pass --min_thickness 0 when running make_topog [..] Searching for isolated T cells... removed_isolated_cells: none found Partial cell restriction Restricting partial cell # 0 to a min thickness of 5.52698 Restricting partial cell # 1 to a min thickness of 12.4865 Restricting partial cell # 2 to a min thickness of 155.487 Restricting partial cell # 3 to a min thickness of 426.5 restrict_partial_cells: No cells were found whose partial cells were too thin. Enforcing the minimum number of ocean cells in the vertical to be 2 enforce_min_depth: No modifications needed Successfully generate topog.nc 2a. We have copied the atmos horizontal grid already. 2b. Generate atmos mosaic ../../../src/tools/make_solo_mosaic/make_solo_mosaic \ --num_tiles 1 --dir ./ --mosaic_name atmos_mosaic \ --tile_file atmos_hgrid.nc --periodx 360 3b. Generate land mosaic. ../../../src/tools/make_solo_mosaic/make_solo_mosaic \ --num_tiles 1 --dir ./ --mosaic_name land_mosaic \ --tile_file atmos_hgrid.nc --periody 1 4. Generate grid_spec mosaic file This also generates land_mask.nc and ocean_mask.nc ../../../src/tools/make_coupler_mosaic/make_coupler_mosaic \ --verbose \ --atmos_mosaic atmos_mosaic.nc \ --land_mosaic land_mosaic.nc \ --ocean_mosaic ocean_mosaic.nc \ --ocean_topog topog.nc \ --check \ --mosaic grid_spec NOTE: tiling error is 0.000000% ***** Congratulation! You have successfully run make_coupler_mosaic 5. Generate land topography We just use the HORO-file from step 0 6. Generate cover type map alias vegetation map * land_lad: ! veg_to_use choice of method for defining vegetation [character] ! 'variable' - use input map to index vegetation parameter vectors ! 'constant' - use veg_index_constant to index veg parameter vectors ! 'cons_tun' - use tuned global constant vegetation ! 'cons_ssl' - use Manabe Climate Model-like vegetation (forces use_climap to be true) ! !---- Cover (vegetation) type. There are 12 possible cases: veg_to_use can ! take 4 values, and glaciers can be (1) absent, (2) based on input cover ! field, or (3) based on climap albedo field. (use of climap albedo forces ! use of climap to locate glaciers, if glaciers are used.) the code ! ensures consistency between cover_type field and glacier mask, with ! the latter taking precedence: where glacier based on input cover field ! must be removed in deference to climap or if no glaciers are used, ! such points are assigned tundra (or global constant) type. ! ! the following namelist vectors contain properties indexed by cover (veg) type: ! 0 ocean ! 1 (BE) broadleaf evergreen trees [rainforest] ! 2 (BD) broadleaf deciduous trees [middle europe / E USA] ! 3 (BN) broadleaf/needleleaf trees [middle europe] ! 4 (NE) needleleaf evergreen trees [N Russia / S Canada] ! 5 (ND) needleleaf deciduous trees [taiga] ! 6 (G) grassland ! 7 (D) desert ! 8 (T) tundra ! 9 (A) agriculture ! 10 (I) ice ! 11 (L) lake ! 12 (TV) tuned global vegetation ! 13 (SV) Manabe Climate Model-like vegetation ! 14 (SI) Manabe Climate Model-like ice/glacier For a first try, just use global uniform grassland type 6. Note that in cover_type_field.nc longitude goes -180..180 cdo -b I32 -f nc4 -expr\,'cover=6' -seltimestep\,1 \ ../../CM2M_coarse_BLING/INPUT/cover_type_field.nc \ cover_type_field.nc 7. river routing : ===== land_lad ==== The file river_destination_field contains two times 96x80 values (2*96*80=2*7680). (802 = 2+2*400 lines, 15364 = 3+1+7680*2 words) -------- 96, 80, -1.876 (20i4) # columns: starting with south pole 85 85 85 85 85 85 85 85 85 85 84 84 84 84 84 84 84 84 84 84 84 84 84 84 84 84 84 84 84 84 84 84 84 84 84 84 84 84 84 84 50 50 50 50 50 50 50 50 50 50 50 50 50 50 50 50 50 50 50 50 84 84 84 84 84 84 84 84 84 84 84 84 84 83 83 84 84 84 84 84 84 84 84 84 84 84 84 84 84 84 84 84 84 85 85 85 [..] # last line: North Polar ocean: each column into itself 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 # rows. starting with south pole 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 [..] # last line: North Polar ocean: the row itself 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 -------- Apparently, there is one pair of values for each surface cell. The first value denotes column, the second value denotes row index of the destination cell. Cells which point to themselfes are ocean cells. The input data is regridded dynamically to the actually used model grid resolution. After regridding, for each land cell it is made sure that its runoff goes into an ocean cell. Apparently, runoff from each cell goes directly into its corresponding ocean cell (???) The regridded river routing map is sent to static diag fields rivers|dest|destination points|none|2|F| 0.000000000000000E+000|||lon,lat rivers|basin|river basins|none|2|F| 0.000000000000000E+000|||lon,lat subroutine init_routing ( glonb, glatb, gfrac, is,ie, js,je, i_dest,j_dest ) call mpp_open (unit, 'INPUT/river_destination_field', action = MPP_RDONLY) read (unit,*) n_lon_in, n_lat_in, wb_degrees read (unit,*) input_format do j=1,n_lat_in read(unit,input_format) (input_1(i,j),i=1,n_lon_in) end do do j=1,n_lat_in read(unit,input_format) (input_2(i,j),i=1,n_lon_in) end do route_input = input_1 + n_lon_in*(input_2-1) deallocate ( input_1, input_2 ) First approach: each land point drains towards its nearest coast cell. Seufz. Am einfachsten ein Stueck C-Code schreiben. gcc -g -Wall -O2 createriverrouting.c -o createriverrouting ./createriverrouting 10 10 rivers-10-10 ln -s rivers-10-10 rivers-10-10-2 let dlon=`360/144` let dlat=`180/90` define axis/x=-180:180:`dlon`/edges x144 define axis/y=-90:90:`dlat`/edges y90 define grid/x=x144/y=y90 g144x90 set data/ez/variables=rdf1/grid=g144x90/skip=2/columns=144 "rivers-10-10" set data/ez/variables=rdf2/grid=g144x90/skip=722/columns=144 "rivers-10-10-2" fill rdf1[d=1]+144*(rdf2[d=2]-1) cp -p rivers-10-10 INPUT/river_destination_field --------------- head ../CM2.1p1/INPUT/groundwater_residence_time_field 360 180 -180 (8e12.4) 0.2591E+07 0.2591E+07 0.2591E+07 0.2591E+07 0.2591E+07 0.2591E+07 0.2591E+07 0.2591E+07 [..] 0.2591E+07 apparently corresponds to ``1 week''. &land_properties_nml geo_res_time = 5184000.0 ! time constant when use_single_geo is true (2 months) / But we have use_single_geo = F inorder to use our hand-crafted river_destination_field Thus, lets set the groundwater_residence_time_field to all-constant 1 week rm INPUT/groundwater_residence_time_field echo ' 360 180 -180' > INPUT/groundwater_residence_time_field echo '(8e12.4) ' >> INPUT/groundwater_residence_time_field for i in `seq 1 8100` do echo ' 0.2591E+07 0.2591E+07 0.2591E+07 0.2591E+07 0.2591E+07 0.2591E+07 0.2591E+07 0.2591E+07' >> INPUT/groundwater_residence_time_field done chmod a-w INPUT/groundwater_residence_time_field --------------- cp -p ../CM2.1p1/INPUT/input.nml . cp -p ../CM2.1p1/INPUT/*table* . Parameters of the land-properties-Module. That looks a little bit messy. For starters, I filled in these parameters: ------------- &land_properties_nml veg_to_use = 'variable' !veg_index_constant = 3 dynamic_cover_type = .false. ! read one static time slice from cover_type_field.nc read_old_ascii_cover = .false. cover_dataset_init_year = 1860 cover_dataset_entry = 1860, 1, 1, 0, 0, 0, soil_to_use = 'constant' soil_index_constant = 2 use_glaciers = .true. use_climap = .false. ! dont use albedo_data.nc use_desert_albedo_map = .false. ! dont use albedo_data.nc use_single_geo = .true. ! dont use groundwater_residence_time_field but constant geo_res_time geo_res_time = 5184000.0 ! default value use_topo_rough = .true., ! use INPUT/maast_70ma_topography.nc as specified in topography_nml. max_topo_rough = 100.0, ! ... But is the Cretacious map resolution sufficient for this??? topo_rough_factor = 0.01, use_single_basin = .false. / -------------- EBM CM2M_coarse_BLING 070Ma CM2.1p1 Striped &LAND_PROPERTIES_NML DO_ALL_MCM = F, F F F F VEG_TO_USE = constant, variable variable variable constant SOIL_TO_USE = constant, variable constant variable constant USE_GLACIERS = T, T T T F USE_CLIMAP = T, F F F F USE_DESERT_ALBEDO_MAP = T, T F T F DO_MCM_MASKING = F, F F F USE_SINGLE_BASIN = F, F F F F USE_SINGLE_GEO = T, F T F F I_DEST0 = 1, 1 J_DEST0 = 1, 1 VEG_INDEX_CONSTANT = 3, 3 3 6 SOIL_INDEX_CONSTANT = 2, 2 2 2 2 SOIL_INDEX_ICE_SUBSTITUTE = 1, 1 1 1 GEO_RES_TIME = 5184000.0, 5184000.0 5184000.0 5184000.0 5184000.0 T_RANGE = 10.0, 10.0 10.0 10.0 USE_TOPO_ROUGH = F, T T T T MAX_TOPO_ROUGH = 100.0, 100.0 100.0 100.0 100.0 TOPO_ROUGH_FACTOR = 1.0, 0.01 0.01 0.01 0.01 SFC_HEAT_FACTOR = 1.0, 0.25 0.25 0.25 NUM_SFC_LAYERS = 0, 6 0 6 6 DYNAMIC_COVER_TYPE = T, F F F F READ_OLD_ASCII_COVER = F, T F T F COVER_DATASET_INIT_YEAR = 1860, 1860 1860 1860 1860 COVER_DATASET_ENTRY = 1860,1,1,0,0,0,1860,1,1,0,0,0 1860,1,1,0,0,0 1990,1,1,0,0,0 1860,1,1,0,0,0 RECONCILE_LAKES = F, F F F F SOIL_INDEX_LAKE_SUBSTITUTE = 1 1 1 1 1 / ----------------- From field_table remove all the cross-land-mix parameterisations. In input.nml deactivate CFC tracer package &generic_tracer_nml do_generic_tracer=.true. do_generic_CFC=.false. do_generic_TOPAZ=.false. / --------- Modify data_table similar to the fixed-surface setup from Aeolus_lad-init-21-mar-clim * Sea-level temperature: cp -p /p/projects/climber3/petri/Jetstream-Vis/ECMWF/t-daily-1000-90S-90N-1979-2019-ydaymean-zonmean-enlarged.nc INPUT/ We must adapt the time axis attributes so that FMS data_override recognizes it as climatological ``modulo'' axis, with correct calendar attribute. Also we need to remove the data for 29-feb to adapt it to the noleap 365_day calendar that we use in MOM. The del29feb operator apparently also updates the calendar attribute to 365_day . For the time interpolation module, make sure which dimension corresponds to which axis. And invert latitudes to run -90 to 90 to comply with expectations of the horizontal interpolation in FMS data_override. cdo del29feb -invertlat /p/projects/climber3/petri/Jetstream-Vis/ECMWF/t-daily-1000-90S-90N-1979-2019-ydaymean-zonmean-enlarged.nc \ INPUT/t-daily-1000-90S-90N-1979-2019-ydaymean-zonmean-enlarged.nc ncatted -a calendar\,time\,m\,c\,365_day -a modulo\,time\,c\,c\," " \ -a cartesian_axis\,time\,c\,c\,"T" \ -a cartesian_axis\,level\,c\,c\,"Z" \ -a cartesian_axis\,latitude\,c\,c\,"Y" \ -a cartesian_axis\,longitude\,c\,c\,"X" \ INPUT/t-daily-1000-90S-90N-1979-2019-ydaymean-zonmean-enlarged.nc * Albedo: The ice model computes first albedo for ice-covered cells, and leaves open-sea-cells at 0. Then it invokes ocean_albedo(), which fills in the open-sea cells with values for albedo_{vis,nir}_di{f,r} (but leaves albedo untouched). CM2.1p1 use namelist option ocean_albedo_option = 3 See ice_param/ocean_albedo.F90 ! ocean_albedo_option = 3 : simple analytic dependence on zenith angle ! used by J. E. Taylor, et. al., ! QJRMS, 1996, Vol. 122, 839-861 ! albedo = 0.037/[1.1*(cos(Z)**1.4) + 0.15] where(coszen .ne. 0.0) cos14 = coszen**1.4 elsewhere cos14 = 0.0 endwhere where(ocean) albedo_vis_dir = 0.037/(1.1*cos14 + 0.15) endwhere albedo_vis_dif = albedo_vis_dir ! this is wrong, use albedo_option=5 albedo_nir_dir = albedo_vis_dir albedo_nir_dif = albedo_vis_dir ! this is wrong, use albedo_option=5 First attempt: The cosine of the zenith angle we get from running coupled Aeolus with namelist parameter test_astro = T. That writes out 400 days of data. We select just the first year of that. But note that that is on Aeolus resolution! cdo -selvar\,coszen -seldate\,0001-01-01T00:00:00\,0001-12-31T23:59:59 \ ../../work/CM2.1p1/history/00020101.atmos_daily.nc fms_astro_cosz-daily.nc can mode up use "../../work/CM2.1p1/history/00010108.atmos_month.nc" ! for the grid use fms_astro_cosz-daily.nc !use era-interim-ci-6hourly-90S-90N-1980-1989-ydaymean.nc !use era-interim-fal-12hourly-90S-90N-1980-1989-ydaymean.nc set mem/size=300 let gridatm=land_mask[d=1] let gridcosz=coszen[d=2] let cos14 = if coszen[d=2] ne 0.0 then coszen[d=2]^1.4 else 0.0 let ocean_albedo_vis_dir = 0.037/(1.1*cos14 + 0.15) let ocean_albedo_vis_dif = ocean_albedo_vis_dir ! this is wrong, use albedo_option=5 let ocean_albedo_nir_dir = ocean_albedo_vis_dir let ocean_albedo_nir_dif = ocean_albedo_vis_dir ! this is wrong, use albedo_option=5 let albedo = 0*ocean_albedo_vis_dir[gxy=gridatm,gt=gridcosz] let albedo_vis_dir = ocean_albedo_vis_dir[gxy=gridatm,gt=gridcosz] let albedo_nir_dir = ocean_albedo_nir_dir[gxy=gridatm,gt=gridcosz] let albedo_vis_dif = ocean_albedo_vis_dif[gxy=gridatm,gt=gridcosz] let albedo_nir_dif = ocean_albedo_nir_dif[gxy=gridatm,gt=gridcosz] save/file="ocean_albedo-daily.nc" albedo, albedo_vis_dir, albedo_nir_dir, albedo_vis_dif, albedo_nir_dif -> enter into data_table Now, create symlinks to input files from CM2.1p1 , but remove restart files. cd INPUT ln -s ../../CM2.1p1/INPUT/* . rm *.res* In several places, the subgrid topography standard deviation is used to compute surface rough for drag calculation schemes. Default is to read it from INPUT/navy_topography.data.nc using subroutine get_topog_stdev(). One place is atmos_param/mg_drag/mg_drag.F90 That can be configured to read pre-computed roughness values from INPUT/mg_drag.res.nc: in input.nml set &mg_drag_nml source_of_sgsmtn = 'input' / and create a modified version of CM2.1p1/INPUT/mg_drag.res.nc with variable ghprime just set to constant 0. cdo minc\,0 ../../CM2.1p1/INPUT/mg_drag.res.nc mg_drag.res.nc Next place is land_properties.F90 . In input.nml set &land_properties_nml [..] topo_rough_source = 'input' ! compute == use get_topog_stdev() topo_rough_file = 'INPUT/mg_drag.res.nc' topo_rough_var = 'ghprime' [..] / However, in our current topography, this roughness is simply 0. Thus we could just disable using the roughness calculations. &land_properties_nml use_topo_rough = .false. / &damping_driver_nml do_mg_drag = .false. / ------------------------------- Mon May 25 12:14:03 CEST 2020 This runs crash-free for one day, on 30 CPUs. It also runs crash-free for 10 years. -> history-run-01 On 04.06.20 09:30, Stefan Petri wrote: Al> [..] die 00020101.atmos_month.nc sind [..] AL> ist das AL> einfach die erste zeit und nicht das ende des laufes [..] ? > > In den Zeitreihen, die ich das letzte Mal mitgeschickt hatte, sehen wir > bei temp am Anfang des ersten Jahres einen deutlichen Einschwingvorgang, > aber ab dem 2.. Jahr sieht das stabil aus. In den Nierderschlaegen sehe > ich das Einschwingen gar nicht so deutlich. > Allerdings ist in der Temperatur eine Assymetrie zw. NH und SH zu sehen, > sowohl land-only als auch atmos-bottom. Ich vermute mal, die kommt i.W. > durch das ERA-Interim-Forcing [plot angetackert], vielleicht auch durch > die Erdumlaufbahn im solar forcing (?). > > Weiterhin faellt mir grad auf, dass in der Konfiguration vermutlich auch > noch pre-industrial Aerosole drin sind. (Files history/*.atmos_scalar.nc > und history/00020101.atmos_month_aer.nc) > Deren raeumliche Verteilung ist ebenfalls an real-world Geographie > angelehnt, d.h. Nord/Sued-Assymetrie. Da muss ich schauen, wie ich die > wegkonfiguriert kriege. FATAL from PE 0: aerosolrad_package_mod: if aerosol impacts are not desired, aerosol_data_set must be set to " " -> in input.nml &aerosol_nml ! source of aerosol data, either 'climatology' file (default) ! or single column 'input' file ! or calculate a column for location and time specified ('calculate_column') ! or 'predicted' (calculated online) aerosol_data_source = 'predicted' time_varying_species = F,F,F,F,F,F,F,F,F,F,F,F,F,F,F,F,F,F,F,F,F !family_names = "no","nada","nix","zilch" !in_family1 = F,F,F,F,F,F,F,F,F,F,F,F,F,F,F,F,F,F,F,F,F, !in_family2 = F,F,F,F,F,F,F,F,F,F,F,F,F,F,F,F,F,F,F,F,F, !in_family3 = F,F,F,F,F,F,F,F,F,F,F,F,F,F,F,F,F,F,F,F,F, !in_family4 = F,F,F,F,F,F,F,F,F,F,F,F,F,F,F,F,F,F,F,F,F, !data_names = !filename = "aerosol.climatology.nc" &aerosolrad_package_nml do_lwaerosol = .false. ! .true., do_swaerosol = .false. ! .true., ! if aerosol impacts are not desired, aerosol_data_set must be set to " " aerosol_data_set = " " ! 'shettle_fenn', optical_filename = "aerosol.optical.dat", !aerosol_optical_names = "sulfate_30%", "sulfate_35%", "sulfate_40%", "sulfate_45%", ! "sulfate_50%", "sulfate_55%", "sulfate_60%", "sulfate_65%", ! "sulfate_70%", "sulfate_75%", "sulfate_80%", "sulfate_82%", ! "sulfate_84%", "sulfate_86%", "sulfate_88%", "sulfate_90%", ! "sulfate_91%", "sulfate_92%", "sulfate_93%", "sulfate_94%", ! "sulfate_95%", "sulfate_96%", "sulfate_97%", "sulfate_98%", ! "sulfate_99%", "sulfate_100%","organic_carbon","soot", ! "sea_salt", "dust_0.1", "dust_0.2", "dust_0.4", ! "dust_0.8", "dust_1.0", "dust_2.0", "dust_4.0", ! "dust_8.0" #We have an experimental operator called mergegrid for this task: # #cdo setrtomiss,-1e33,1e33 file3.nc file4.nc # create file4 with the grid of file3 and set all values to miss #cdo mergegrid file4.nc file1.nc file5.nc # merge all grid points of file1 to file4 and store it to file5 #cdo mergegrid file5.nc file2.nc file6.nc # merge all grid points of file2 to file5 and store it to file6 # #This operator is not documented, yet. AL> ERA-Interim forcing? Can we just mirror the northern hemisphere, AL> to obtain symmetry? I would like that. AL> aerosols could be just left out,m if possible. Else, mirror at the equator? GF> We need a symmetrical temperature field as forcing, and should leave out the aerosols. GF> those have a clear north-south-assymmetry. AL> when you do mirror, please use the southern hemisphere from era-interim and mirror it to AL> northern hemisphere. The south is "cleaner" because there is almost only water and antarctica. cdo -del29feb \ -invertlat \ -add \ -invertlat \ -setgrid\,/p/projects/climber3/petri/Jetstream-Vis/ECMWF/S-N-grid \ -setcindexbox\,0\,1\,480\,1\,120 \ /p/projects/climber3/petri/Jetstream-Vis/ECMWF/t-daily-1000-90S-90N-1979-2019-ydaymean-zonmean-enlarged.nc \ -setcindexbox\,0\,1\,480\,1\,121 \ /p/projects/climber3/petri/Jetstream-Vis/ECMWF/t-daily-1000-90S-90N-1979-2019-ydaymean-zonmean-enlarged.nc \ INPUT/t-daily-1000-SHmirrored-1979-2019-ydaymean-zonmean-enlarged.nc ncatted -a calendar\,time\,m\,c\,365_day -a modulo\,time\,c\,c\," " \ -a cartesian_axis\,time\,c\,c\,"T" \ -a cartesian_axis\,level\,c\,c\,"Z" \ -a cartesian_axis\,latitude\,c\,c\,"Y" \ -a cartesian_axis\,longitude\,c\,c\,"X" \ INPUT/t-daily-1000-SHmirrored-1979-2019-ydaymean-zonmean-enlarged.nc Tue Jun 9 15:19:27 CEST 2020 I have now mirrored in space at the equator. That changes the annual cycle. Maybe also rotation by 6 months in time is necessary. [eraint-t1000-ydaymean-hemiave.png] black: original climatology red: south hemisphere mirrored to NH solid line: global mean dashed: hemisphere mean The three red lines are identical to the black line for SH mean, just shifted a little for better visibility in the plot. As before, plots attached of the model outputs. Does not really look symmetrical between NH and SH curves. Maybe because of the annual cycle (see above). Also looked at SW flux down at TOA. That should show insolation in the annual cycle, without influence of SST forcing or topography. Einmal Zeitreihe ueber global und heimspheric mean. Das sieht nach einer leichten Assymmetrie zw. NH und SH aus. Und einmal zonal mean annual mean, das sieht sehr schoen symmetrisch aus. Und noch ein plot mit den 12 monthly mean zonal mean swdn_toa Kurven. Da taucht auch eine kleine Asymmetrie z.B. zw. Juni und Dezember auf (die beiden obersten Schwarz-mit-plus bzw. Schwarz-mit-kreuz Kurven. Da vermute ich jetzt mal, dass kommt daher, dass das Sonnenjahr gegen das Kalenderjahr um ca. 2/3 Monat verschoben ist. -> history-run-02 ----------------- rotate NH by 6 months? cdo operators seltime shifttime mergetime But: the thermal equator moves with sun angle throughout the annual cycle. I.e. the zonal mean temperature is not symmetrical to the geographical equator. Sigh. One possibility: search for thermal equator in the data and mirror there. -> Program in Ferret? C? alternate approach: synthetic ``ideal Temperature distribution'' let pi=3.14159265358979323846 let deg_to_rad=`pi/180` set mem/size=1000 cancel mode up use "INPUT/t-daily-1000-90S-90N-1979-2019-ydaymean-zonmean-enlarged.nc" let t_max=`'t'[y=@max,i=@max,l=@max]` DEFINE VARIABLE t_max=301.4832153320313 let t_min=`'t'[y=@min,i=@min,l=@min]` DEFINE VARIABLE t_min=241.4859466552734 let t_delta=`t_max-t_min` DEFINE VARIABLE t_delta=59.9972686767579 And a program which computes the solar latitude for the day-of-year, as presumed approximation of the thermal equator. ifort -g -O -warn -w dailydeclination.F90 -o dailydeclination ./dailydeclination > declinations.txt define grid/t=time grid365 set data/ez/grid=grid365/var="dayofyear,d1,d2,d3,thermeq" declinations.txt plot thermeq let yy=y[gy='t',d=1] ! (1*241*1*1*1*1) ! amplitude of thermal equator could be tuned by factor here let cos_y_t_eq = cos((yy-thermeq)*deg_to_rad) ! (1*241*1*365*1*1) ! Minimum value: -0.39779 ! Maximum value: 1 let/unit="K" t_ideal_zonal = t_max - (1-cos_y_t_eq)*t_delta let t_ideal='t'[d=1]*0+t_ideal_zonal ! Total # of data points: 42223200 (480*241*1*365*1*1) ! # flagged as bad data: 0 ! Minimum value: 231.47 ! Maximum value: 301.48 ! Mean value: 281.85 (unweighted average) ! Standard deviation: 17.954 save/file="INPUT/t-ideal.nc" ncatted -a calendar\,time\,m\,c\,365_day -a modulo\,time\,c\,c\," " \ -a cartesian_axis\,time\,c\,c\,"T" \ -a cartesian_axis\,level\,c\,c\,"Z" \ -a cartesian_axis\,latitude\,c\,c\,"Y" \ -a cartesian_axis\,longitude\,c\,c\,"X" \ INPUT/t-ideal.nc -> history-run-03a 23.06.20 10:35 in the 3rd test run, the north-south symmetry is clearly improved, but not yet perfect with the clouds. Looking further through logfiles and namelists. - for CO2 a global uniform value 352.72 is used, according to the measured state at 1.1.1990. - apparently, in the radiation module also CH4 ( 1688.6) and NO2 (308.45) are used. NO2 appears global constant, the value 308.45 seems again to represent 1.1.1990. Same for CH4. Those should not distrub symmetry. Run the model with strace, make a list of files that are actually used, remove all other files from the INPUT directory. Then we can inspect the remaining files.... - set groundwater_residence_time_field to globl constant value, see above. -> history-run-03b -> no visible improvements in North-South symmetry. - a ozone climatology is read, which shows real-world assymmetry and continental outlines. o3.climatology.nc is read in src/atmos_param/sea_esf_rad/ozone.F90, invoked from radiative_gases.F90 . There appears no option to just omit ozone. Easiest workaround might be to simply set o3.climatology.nc to constant 0 ? cdo mulc\,0 ../../CM2.1p1/INPUT/o3.climatology.nc o3.climatology.nc ncatted -a climatology\,time\,c\,c\,'0000-01-01 00:00:00, 1998-01-01 00:00:00' \ -a calendar\,time\,m\,c\,julian \ -a cartesian_axis\,time\,c\,c\,T \ -a _FillValue\,time\,c\,d\,-9999.0 \ o3.climatology.nc -> compute_qs: saturation vapor pressure table overflow, nbad= 10368 Next try: constant global mean values cdo enlarge\,../../CM2.1p1/INPUT/o3.climatology.nc \ -fldmean ../../CM2.1p1/INPUT/o3.climatology.nc \ o3.climatology.nc ncatted -a climatology\,time\,c\,c\,'0000-01-01 00:00:00, 1998-01-01 00:00:00' \ -a calendar\,time\,m\,c\,julian \ -a cartesian_axis\,time\,c\,c\,T \ -a _FillValue\,time\,c\,d\,-9999.0 \ -a units\,time\,m\,c\,'days since 1800-01-01 00:00:00' \ o3.climatology.nc -> /p/projects/climber3/petri/POEM/work/StripedPlanet/history-run-03c/ 23.06.20 11:44 AL> that is superb. I would now look at precipitation maps throughout the year. It looks just fine. The exact atmosphere composition should not be important for our purposes, I think. I think, after looking at precipitation maps some more runs would be nice. I will get back to you. ========= 22.04.21 16:36 AK> with Anders, we have decided to change the setting to have just one land stripe on the NH. AK> I have created a new horo-10N.nc and adapted topog.nc May 04, 2021 16:56 cd POEM/work/StripedPlanet-10N-10/INPUT rm atmos_mosaic.nc atmos_mosaic_tile1Xland_mosaic_tile1.nc atmos_mosaic_tile1Xland_mosaic_tile1.nc atmos_mosaic_tile1Xocean_mosaic_tile1.nc land_mosaic.nc land_mosaic_tile1Xocean_mosaic_tile1.nc ferret use atmos_hgrid.nc let xbounds='x'[Y=1] let ybounds='y'[X=1] define axis/X/edges/units=degrees_east X=xbounds define axis/Y/edges/units=degrees_north Y=ybounds def grid/x=x/y=y xygrid let y_y=y[gy=xygrid] let xyvar=0*'x'[d=1,gxy=xygrid@asn]-3000 let horo = if (y_y gt 20) or (y_y lt 10) then xyvar else 10 def att/output horo.long_name="orography height" def att/output/type=string horo.units="m" save/clobber/file=horo-10N-10.nc horo quit ../../../src/tools/make_topog/make_topog --verbose --mosaic ocean_mosaic.nc --topog_type realistic --vgrid_file ocean_vgrid.nc --topog_file horo-10N-10.nc --topog_field HORO --scale_factor -1 --bottom_depth 3000 --output topog.nc ../../../src/tools/make_solo_mosaic/make_solo_mosaic --num_tiles 1 --dir ./ --mosaic_name atmos_mosaic --tile_file atmos_hgrid.nc --periodx 360 ../../../src/tools/make_solo_mosaic/make_solo_mosaic --num_tiles 1 --dir ./ --mosaic_name land_mosaic --tile_file atmos_hgrid.nc --periody 1 ../../../src/tools/make_coupler_mosaic/make_coupler_mosaic --verbose --atmos_mosaic atmos_mosaic.nc --land_mosaic land_mosaic.nc --ocean_mosaic ocean_mosaic.nc --ocean_topog topog.nc --check --mosaic grid_spec ../../../exp/StripedPlanet/createriverrouting 10 10 rivers-10-10 cp -p rivers-10-10 river_destination_field ----------------------------------------- 01.06.21 14:55 AK> during analysis of the monsoon planet data, it shows that an ocean AK> with dynamic surface temperature would be very useful in AK> combination with certain CO2 concentrations. AK> what would be the best approach? 02.06.2021 16:52 SP> some time ago, Georg had received that for a mixed-layer / slab-ocean component, SP> but we have not yet used that for serious things. 03.06.21 08:46 AL> This the ocean I was talking about. Do you have an idea how to get that running? AL> https://www.gfdl.noaa.gov/fms-slab-ocean-model-technical-documentation/ SP> I have committed an update to the mixed layer code. I compiles, but I have not yet run it. On 03.06.21 13:23, Stefan Petri wrote: > > in input.nml we must now set do_ocean = .true. and do_ice = .true. > > Further we must comment out some entries in the data_table > > "ICE", "t_surf", "T_IDEAL", "INPUT/t-ideal.nc", .false., 1.0 > > If and how roughness length and albedo come from the slab ocean, I have to look up. > The concerns the entries: > > "ICE", "rough_mom", "", "", .false., 0.00026452 > "ICE", "rough_heat", "", "", .false., 0.00020200 > "ICE", "rough_moist", "", "", .false., 0.00011408 > > "ICE", "albedo", "albedo", > "INPUT/ocean_albedo-daily.nc", .true., 1.0 > "ICE", "albedo_vis_dir", "albedo_vis_dir", > "INPUT/ocean_albedo-daily.nc", .true., 1.0 > "ICE", "albedo_nir_dir", "albedo_nir_dir", > "INPUT/ocean_albedo-daily.nc", .true., 1.0 > "ICE", "albedo_nir_dif", "albedo_nir_dif", > "INPUT/ocean_albedo-daily.nc", .true., 1.0 > "ICE", "albedo_nir_dif", "albedo_nir_dif", > "INPUT/ocean_albedo-daily.nc", .true., 1.0 > > Because the slab ocean does not have currents, I think we can leave > > "ICE", "u_surf", "", "", .false., 0.0 > "ICE", "v_surf", "", "", .false., 0.0 > > just enabled. > > Repeated reminder: flux exchange between atmosphere and ocean goes always > through the ice Module, also in places where no ice is floating around. > Thus, the entries in the data_table are tagged with "ICE". > > I guess, that for now also the Ice-Model should be switched to > ``slab''. Whether the ``full'' Ice-Model ``pays out'' quality-wise'' > without ocean currents, will be seen. > In input.nml > > &ice_model_nml > slab_ice = .true. On 03.06.21 13:57, Stefan Petri wrote: > > in input.nml , the ocean_model_nml must be commented out, > because that is for the ``full'' MOM5 implementation. > For the slab ocean, these are the default values: > > &ocean_model_nml > mixed_layer_depth = 50.0, ! meters > mixed_layer_salin = 33.333, ! parts per thousand > layout = 0,0, > do_qflux_adj = .false., > do_restore_sst = .false., > sst_restore_timescale = 5.0 ! days > / > > All the other ocean_*nml do not harm, but could be deleted for maintainability. > > Further, in data_table the lines > "ICE", "sic_obs", "SIC","./INPUT/sst_ice_clim.nc",.false.,0.01 > "ICE", "sit_obs", "SIT","./INPUT/sst_ice_clim.nc",.false.,1.06 > "ICE", "sst_obs", "SST","./INPUT/sst_ice_clim.nc",.false.,1 > > must be commented out. They tell the sea-ice module > to read certain data from climatology files. > However, if I understand the code correctly, these 3 variables > are just used for comparison with observations. > Anyways, for the StripedPlanet we dont havesuch data to feed in. > > And with that, the model starts to run. On 04.06.21 12:57, Stefan Petri wrote: > A newer version of the mixed-layer-ocean Code is public available at > https://github.com/NOAA-GFDL/SM2 > There, this component is called ocean_slab genannt. It requires a newer version > of the FMS infra structure than it comes with MOM5, but appears on first sight > equivalent concerning the physics. The example configuration is compressed 8GB in size. > I could not get it compiled on first effort, it is very picky with its requirements for > NetCDF/HDF5/MKL/whatever libraries/Versions. But it could be useful as reference to > publicly available code. 04.06.21, 14:47 GF> Now the sea-ice model does not have dynamics? GF> Of course there are no ocean current,s but wind would GF> be useful for some situations. As far as I understand, at least with option slab_ice = .true. the ice is driven only by ocean currents, which is 0 with the slab ocean. If, how and where with the non-slab-ice the wind stress impacts the ice advection I have not completely understood yet. In any case the wind stress is passed on to the ocean (but is ignored by the slab ocean). AL> for the Monsoon we prefer to have just thermo dynamic ice, if that runs stable. On 07.06.21 15:07, Anja Katzenberger wrote: > Hallo, > > ich habe mir den Output des von Stefan aufgesetzten Testlaufs fuer 20 > Jahre angeschaut. > > Die global gemittelte Oberflaechentemperatur scheint sich langsam aber > sicher bei 295K einzupendeln, womit der slab ocean ca 6K ueber dem > nicht-slab Setup mit 289K liegt (ohne dass wir den C02 in der Atmosphaere > schon angepasst haben). Die Eisbedeckung scheint nach 20 Jahren auch > relativ stabil, wobei da ein Blick auf die naechsten Jahre wahrscheinlich > schon noch gut waere. > > Der globale Niederschlag scheint sich nach 20 Jahren ganz gut > eingependelt zu haben (mit precip einmal aus der *land_month.nc > Outputdatei und einmal aus der *atmos_month.nc Outputdatei). Aehnlich fuer > die Evaporation. > > Bevor wir die Atmosphaere auf vorindustriell umstellen und die Laeufe mit > den unterschiedlichen Streifen-Setups starten, wuerde ich daher nochmal > die naechsten paar (vielleicht nochmal 10?) Jahre anschauen. > Und das Ding ist in der Tat recht warm und eisarm ;) Das liegt sicherlich zum Teil an der Kontinentalkonfiguration (mehr Ozean, flachere Orographie), sicherlich aber auch an den Randbedingungen. > > @Stefan: Wie sind die CO2-Konzentration und die Solarkonstante fuer diesen Lauf? Stefan: SOLAR_CONSTANT 1366.862182617188 rrvco2 352.7218933105469 Im Original-Setup CM2.1p1 schweben dazu ja noch Staub und Aerosole rum, die ich rausgeworfen habe. Georg: Danke! Also bei einer Solarkonstante von 1367 W/m2 zucke ich ja etwas zusammen. Wir wissen jetzt doch schon seit etlichen Jahren, dass die eher bei 1361 W/m2 liegt ;) Anja: danke dir fuer deine Einschaetzung. Genau, als naechstes ist die Umstellung der Randbedingungen dran, da wir die eigentlichen Experimente mit vorindustriellen Bedingungen und spaeter mit 4xCO2 machen wollen. Die eigentlichen Experimente sind dann Setups mit verschiedenen Streifenbreiten und -lagen. Die aktuelle Konfiguration ist interessant, weil man direkt slab mit nicht slab ocean vergleichen kann, zu vorindustriell haben wir bisher noch keine Laeufe zum vergleichen. Stefan: ich starte mal - weitere 10 Jahre slab - 30 Jahre slab mit Werten fuer 1860 statt 1990. (40 Jahre werden fuer short jobs knapp) (die INPUT/co2_gblannualdata faengt bei 283 an. 1800.5 283.1878 1801.5 283.3157 1802.5 283.4393 1803.5 283.5584 .. 1859.5 285.9040 1860.5 286.0533 1861.5 286.1936 ... 2002.5 372.4675 2003.5 374.9000 2004.5 376.7250 ) Wir koennen auch in der Datei fuer 1850 co2 auf 280 ppm setzen. Aber was machen wir dann mit den anderen Gasen (O3, n2o, ch4, f113, f11, f12, f22) ? On 08.06.21 12:47, Anders Levermann wrote: > habe das set-up mit Anja jetzt besprochen. wir bleiben bei 1850 mit 280 > ppm. 40 Jahre einpendeln dann 10 Jahre Lauf mit 5 verschiedenen > topographien. dann gehen wir schrittweise mit co2 hoch. > > 1. frage: wie verhaelt sich der moisture-advection feedback (hypothese: > er stabilisiert den Monsun ueber Land und verlaengert die Saison. das > haben wir in den atmos-only laeufen gesehen) > 2. Frage: springt ein monsoon an, wo vorher keiner war, wenn es waermer > wird. Ein Warmstart mit veraenderter Topographie duerfte problematisch sein, weil im ocean_model.res der Zustand mit Land-See-Maske abgespeichert wird. In den Restart-Files des Land-Modells ebenfalls. Aber das Modell ist ja einigermassen schnell, so dass der Spin-Up nicht alluzusehr wehtut (im Gegensatz zum 3-D Ozean mit 100en Jahren spinup ...) 18:20 Also, statt in der INPUT/co2_gblannualdata rumzuschimeren koennen wir in der input.nml &radiative_gases_nml die Werte setzen &radiative_gases_nml verbose = 3 gas_printout_freq = 240 time_varying_co2 = .true., co2_variation_type = 'linear', ! co2_dataset_entry = 1860,1,1,0,0,0, co2_specification_type = 'base_and_trend' co2_data_source = 'namelist' co2_base_time = 2019,1,1,0,0,0, co2_base_value =0.000750 !0.00040936 co2_change_rate=1.0 Wobei co2_change_rate=1.0 bedeutet stay at 100% == "keine Aenderung". Fuer 1% change muss man eintragen co2_change_rate=1.01 oops, der 1860-Lauf ist beim Init gecrasht. FATAL from PE 0: MPP_OPEN: error in OPEN for INPUT/cns_700_12001400. Die cns_* werden benutzt in lw_gases_stdtf.F90 Module that computes longwave gas transmission functions Klingt als waers erstmal von topographie unabhaengig. -> symlinks auf alle INPUT/cns_* files des CM2.1p1/INPUT setzen. cd .../POEM/exp/StripedPlanet/INPUT ln -s ../../CM2.1p1/INPUT/cns_* . cd ../../../work/StripedPlanet-slab-1860/INPUT ln -s ../../../exp/StripedPlanet/INPUT/cns_* . On 09.06.21 11:46, Stefan Petri wrote: > For the desired 280ppm-configuration we do not need to mess around in the INPUT/ files, > but can set that directly in the input.nml > (Thanks to Markus Dr"uke, who tried that recently for coupling with LPJmL) > > Stefan > > &radiative_gases_nml > verbose = 3 > gas_printout_freq = 240 > > time_varying_co2 = .true., > co2_variation_type = 'linear', > ! co2_dataset_entry = 1860,1,1,0,0,0, > co2_specification_type = 'base_and_trend' > co2_data_source = 'namelist' > co2_base_time = 2019,1,1,0,0,0, > co2_base_value =0.000750 !0.00040936 > co2_change_rate=1.0 > > Where co2_change_rate=1.0 means stay at 100% == "no change". > For 1% change you must enter co2_change_rate=1.01 A warm restart with modified topography is most probably problematic, because in ocean_model.res the state with the old land-sea-mask is stored. Also in the restart files of the land model. But the model is reasonably fast, so that spin-up does not hurt too much (in contrast to a full 3-D ocean which would need several centuries spinup ...) ----------- Fri May 26 17:56:09 CEST 2023 modified createriverrouting.c so that it can also create river routing maps for planets with just one land stripe. ----------- Tue May 30 14:55:40 CEST 2023 try to have a look at the generated maps before the model is started: gcc -g -Wall -O2 -o printrivermap printrivermap.c ./printrivermap ../CM2.1p1/INPUT/river_destination_field > CM2.1p1-rivers.txt We see that the order of latitudes needs to be reverted from our previous assumptions. For the 2-stripes case that does not matter, but for the 1-stripes case. However, this is irrelevant when using the slab ocean. In land_lad, runoff water is immediately removed from the source land cell, and is poured either into the ocean at a coast cell, or vanishes (for inland sinks). The slab ocean, on the other hand, does not care for the incoming runoff. It has no currents which could be influenced by freshwater. === === ============================== === === Thu Jan 23 13:54:41 CET 2025 Nina Doerfler wants to investigate atmospheric rivers on a planet with idealized surface topography. Instead of circumglobal land stripes, now one square piece of land, because she needs a western coast. Approximate USA as simple square 120W - 80W, 30N - 50N cp -av POEM/work/StripedPlanet-slab/INPUT POEM/work/SquaredPlanet-USA/INPUT-00010101 cd POEM/work/SquaredPlanet-USA/INPUT-00010101 rm atmos_mosaic.nc atmos_mosaic_tile1Xland_mosaic_tile1.nc atmos_mosaic_tile1Xland_mosaic_tile1.nc atmos_mosaic_tile1Xocean_mosaic_tile1.nc land_mosaic.nc land_mosaic_tile1Xocean_mosaic_tile1.nc ferret use atmos_hgrid.nc let xbounds='x'[Y=1] let ybounds='y'[X=1] define axis/X/edges/units=degrees_east X=xbounds define axis/Y/edges/units=degrees_north Y=ybounds def grid/x=x/y=y xygrid let x_x=x[gx=xygrid] let y_y=y[gy=xygrid] let oceandepth=0*'x'[d=1,gxy=xygrid@asn]-3000 let horo = if (y_y gt 30) and (y_y lt 50) and (x_x gt `360-120`) and (x_x lt `360-80`) then 10 else oceandepth def att/output horo.long_name="orography height" def att/output/type=string horo.units="m" shade horo; go land save/clobber/file=horo-square-usa.nc horo quit /p/projects/climber3/petri/POEM/src/tools/make_topog/make_topog --verbose --mosaic ocean_mosaic.nc --topog_type realistic --vgrid_file ocean_vgrid.nc --topog_file horo-square-usa.nc --topog_field HORO --scale_factor -1 --bottom_depth 3000 --output topog.nc ../../../src/tools/make_solo_mosaic/make_solo_mosaic --num_tiles 1 --dir ./ --mosaic_name atmos_mosaic --tile_file atmos_hgrid.nc --periodx 360 ../../../src/tools/make_solo_mosaic/make_solo_mosaic --num_tiles 1 --dir ./ --mosaic_name land_mosaic --tile_file atmos_hgrid.nc --periody 1 ../../../src/tools/make_coupler_mosaic/make_coupler_mosaic --verbose --atmos_mosaic atmos_mosaic.nc --land_mosaic land_mosaic.nc --ocean_mosaic ocean_mosaic.nc --ocean_topog topog.nc --check --mosaic grid_spec cover_type_field and groundwater_residence_time_field are set as above. For now, lets just try without rivers. The slab ocean does not care for runoff anyway. &land_properties_nml/use_single_geo = T #../../../exp/StripedPlanet/createriverrouting 10 10 rivers-10-10 #cp -p rivers-10-10 river_destination_field TODO: find out why ice_sst_climatology is enabled in data_table ? For now: disable that, to avoid influence of real-world topography data. Make sure we have all the cns_* files for the radiation transport calculation in INPUT? (resp. symlinks to them).