Werner: Original-Datensatz DDM30 in /data/biosx/LPJ/input_new/DDM30.asc Stefan: Die gleiche Datei , sowie ein README zum Erstellen von weiteren Hilfsdateien (?) finde ich auch in data/biosx/LPJ/input_river/ Welches davon ist aktueller? Brauchen / wollen / koennen wir das in /data/biosx/LPJ/input_river/README beschriebene Vorgehen auch fuer die Climber-4 Koppelung? Oder ist das ``nur'' fuer die Bassin-weise Domain-Zerlegung der River-Routing-Info? Werner: die beiden DDM30.asc sind identisch. Das README in input_river bezieht sich primar auf das Zerlegen der anderen Inputfiles in die disjunkten River basins. Dies war in der Version ohne River-routing Parallelisierung notwendig. Wir brauchen die Dateien lake fraction und bei Landuse neighb_irrigation. Wie die neigbour irrigation erzeugt wurde, muessten wir noch in Erfahrung bringen. The map is generated with a cellsize of 30 arc minutes and is distributed as a zipped ASCII-grid that can be easily imported in most GIS-software that support rasters or grids. The direction of outflow from cell is according to the ArcInfo/ArcView convention as follows: ``0'' is assigned to internal sinks and to cells draining into the ocean while ``1'', ``2'', ``4'', ``8'', ``16'', ``32'', ``64'' and ``128'' standing for the outflow directions E, SE, S, SW, W, NW, N or NE. -9 is missing_value, for ocean cells. http://www.geo.uni-frankfurt.de/ipg/ag/dl/datensaetze/3_drainage_direction_map/index.html http://www.uni-frankfurt.de/45217896/3_drainage_direction_map? http://www.uni-frankfurt.de/45218101/DDM30 About LPJ river routing: can mode upcase define axis/units=degrees_east/x=-179.75:179.75:0.5 x05deg define axis/y=89.75s:89.75n:0.5 y05deg define grid/x=x05deg/y=y05deg grid05deg set data/ez/variables=ddm_orig/grid=grid05deg/skip=6/columns=720 "/data/biosx/LPJ/input_new/DDM30.asc" ! this data set appears upside-down let ddm_rev=yreverse(ddm_orig) let/title="DDM30" ddm=ddm_rev[g=grid05deg@asn] set att ddm.missing_value=-9 ! sigh. for whatever reason ferret an attribute long_name_mod to some bogus value can att/output ddm.long_name_mod set var/outtype=short ddm save/clobber/file="DDM30.nc" ddm shade/levels=h ddm frame/file="DDM30.gif" define region/X=-60:-40/Y=-10:10 amazonmouth Thus: ..../src/land_atlantes/lpj_trunk/bin/drainage grid.bin DDM30.asc drainage.bin This maps -9 -> -9 0 -> -1 direction 2^n -> index of destination cell I.e. LPJ cells with river destination -9 are ocean cells according to DDM30, LPJ cells with river destination -1 are inland sinks or coast cells. DDM30 may contain drainage directions from coast cells into adjacent ocean cells, but that information is discarded in the drainage program. DDM30 does not contain data for Antarctica! The river_data.nc in the GFDL-supplied ESM2M_pi-control_C2 example setup contains data for Antarctica, at 144x90 resolution. The river_destination_field files in the GFDL-supplied CM2M_coarse_BLING and CM2.1p1 example setups contain (different) Antarctica data at 96x80 resolution. ln -s river_destination_field river_destination_field2 ferret define axis/x=-178:178:`360/96` x96 define axis/y=-89:89:`180/80` y80 define grid/x=x96/y=y80 g96x80 set data/ez/variables=rdf1/grid=g96x80/skip=2/columns=96 "river_destination_field" set data/ez/variables=rdf2/grid=g96x80/skip=402/columns=96 "river_destination_field2" fill rdf1[d=1]+96*(rdf2[d=2]-1) Note that land_lad computes for each land cell its corresponding ocean-shore cell, where the water from the land cell enters the ocean. In-land river routing seems not to be calculated explicitly by land_lad. Thus, this data set cannot be used for LPJ river routing. However, even if we put that data into LPJ, it would still not calculate the runoff ? It might better to take runoff from the land_lad{2} part for Antarctica and combine that with the LPJ-generated runoff for the rest of the world. mmhh, what about Greenland? DDM30 has data for Greenland. But Greenland consists entirely of Rock/Ice, which is not considered by LPJ. Does it nevertheless calculate runoff for Greenland? Other River Runoff datasets on the Web: Data Set: ISLSCP II RIVER ROUTING DATA (STN-30P) The Simulated Topological Network (STN-30p) data set provides the large-scale hydrological modeling community an accurate representation of the global river system at 0.5 degree and 1.0 degree spatial resolutions. STN-30p represents the potential connectivity of the continental land mass by assigning one of eight (E, SE, S, SW, W, NW, N, NE) possible flow directions to each continental grid cell (Jenson 1988, Band 1993). Vorosmarty, C. J., and B. Fekete. 2011. ISLSCP II River Routing Data (STN-30p). In Hall, Forrest G., G. Collatz, B. Meeson, S. Los, E. Brown de Colstoun, and D. Landis (eds.). ISLSCP Initiative II Collection. Data set. Available on-line [http://daac.ornl.gov/] from Oak Ridge National Laboratory Distributed Active Archive Center, Oak Ridge, Tennessee, U.S.A. doi:10.3334/ORNLDAAC/1005 webmap.ornl.gov/wcsdown/dataset.jsp?ds_id=1005 PMIP 2 River Routing Data - Paelo Model Intercomparison Project Generating the data The data sets were produced with the HYDRA river routing model with unlimited runoff in order to determine potential river routes. The model predicted river direction, river routes and river basins. Please note that the HYDRA simulations produced many more rivers and river basins than what is commonly incorporated in climate models. This information was not reduced because it was not yet clear what would be most useful to do... Note about the topography The modern topography that was used is different from the one used by W. R. Peltier in ICE-5G. It was produced by combining several different 5-minute Digital Elevation Models, using the best one for each region to ensure a reasonably correct simulation of the modern drainage network. The LGM topography was then generated by applying the 21ka-0ka topographic anomaly from the ICE-5G data set to the modern data set. The land-ice was then overlaid as a mask on this topography. The river direction windrose The directions of the rivers stored in the river_dis_[0,21]k.nc use the following convention: NW = 8 N = 1 NE = 2 W = 7 E = 3 SW = 6 S = 5 SE = 4 http://pmip2.lsce.ipsl.fr/design/river/ Total Runoff Integrating Pathways (TRIP) http://hydro.iis.u-tokyo.ac.jp/~taikan/TRIPDATA/TRIPDATA.html Current version of 1-dgree TRIP is "970522," and resolution of 1 degree by 1 degree longitude/latitude grids. 0.5x0.5 degree version is also available. /home/bloh/cprog/test/map.c ---------------- Tue Jun 30 13:49:05 CEST 2020 I have added topography height output to lpj_driver.F90 . It is not used in the model, but expected to be useful for preparation of an enhanced river routing map. The data is obtained from FMS topography_mod , which reads the navy_topography.nc . lpj_topo_05deg.nc contains the resulting horo, together with the land-sea mask. See also ../Cretaceous/README_Cretaceous_MOM5 cd exp/CM2M_coarse_BLING_LPJ_05/Data-For-LPJ/Rivers ../../../Cretaceous/expand-map ../lpj_topo_05deg.nc horo lpj_land_mask lpj_topo_05deg-expanded.nc invoke grass. make sure that region is set correctly!!! r.in.gdal --v --o input=NETCDF:/p/projects/climber3/petri/POEM/exp/CM2M_coarse_BLING_LPJ_05/Data-For-LPJ/Rivers/lpj_topo_05deg-expanded.nc:horo output=horo g.region raster=horo g.region -p r.watershed --v memory=30000 elevation=horo \ drainage=drainage_direction_land+sea threshold=1 r.out.gdal --v input=drainage_direction_land+sea \ format=netCDF \ output=/p/projects/climber3/petri/POEM/exp/CM2M_coarse_BLING_LPJ_05/Data-For-LPJ/Rivers/lpj_topo_05deg-expanded-drainage_direction_land+sea.nc ferret -> /p/projects/climber3/petri/POEM/exp/CM2M_coarse_BLING_LPJ_05/Data-For-LPJ/Rivers/lpj_topo_05deg-expanded-drainage_direction_land+sea-band1.gif ../watershed-to-DDM30 \ lpj_topo_05deg-expanded-drainage_direction_land+sea.nc Band1 \ lpj_topo_05deg-expanded.nc lpj_land_mask \ DDM-lpj_topo_05deg.asc can mode upcase define axis/units=degrees_east/x=-179.75:179.75:0.5 x05deg define axis/y=89.75s:89.75n:0.5 y05deg define grid/x=x05deg/y=y05deg grid05deg set data/ez/variables=ddm_orig/grid=grid05deg/skip=6/columns=720 "DDM-lpj_topo_05deg.asc" ! this data set appears upside-down let ddm_rev=yreverse(ddm_orig) let/title="DDM_lpj_topo_05deg" ddm=ddm_rev[g=grid05deg@asn] set att ddm.missing_value=-9 ! sigh. for whatever reason ferret an attribute long_name_mod to some bogus value can att/output ddm.long_name_mod set var/outtype=short ddm save/clobber/file="DDM-lpj_topo_05deg.nc" ddm shade/levels=h ddm frame/file="DDM-lpj_topo_05deg.gif" ------------ Wed Jul 8 19:41:41 CEST 2020 The lpj_driver can now write river routing in vector-like format to NetCDF. However, it is difficult to teach the diag manager to use non-geographical axes. Thus, we write out two variables lpj_runoff_dest_lon and lpj_runoff_dest_lat, which contain for each cell the longitude resp. latitude of its river destination cell, or missing_value for ocean cell, sinks, etc. In ferret, we convert those to data that is apropriate for plotting the river routing network: use lpj_static.nc ! first create maps of source cell coordinates. ! this is just the identity map, but with missing_values inherited from ! the destination cell coordinates. let lpj_runoff_src_lon=0*LPJ_RUNOFF_DEST_LON+X[G=LPJ_RUNOFF_DEST_LON] let lpj_runoff_src_lat=0*LPJ_RUNOFF_DEST_LAT+Y[G=LPJ_RUNOFF_DEST_LAT] ! unravel those into 1-D fields let seq_src_lon=ysequence(lpj_runoff_src_lon) let seq_src_lat=ysequence(lpj_runoff_src_lat) let seq_dst_lon=ysequence(LPJ_RUNOFF_DEST_LON) let seq_dst_lat=ysequence(LPJ_RUNOFF_DEST_LAT) ! and recombine into columns. the first 2 columns ! are src and destination coordinate, ! the 3rd column is filled with missing_value ! so that plot/vs divides the data set into lines with ! 2 points each. let lon2=xcat(seq_src_lon,seq_dst_lon) let lonbad=if seq_src_lon lt 0 then seq_src_lon let/unit=degrees_E lon3=xcat(lon2,lonbad) let lat2=xcat(seq_src_lat,seq_dst_lat) let/unit=degrees_N lat3=xcat(lat2,lonbad) ! example plot for amazon mouth shade/x=80w:50w/y=10s:10n if lpj_dcount ge 0 then lpj_dcount else 0 plot/vs/line/over routex,routey frame/file=dcount-flow-amazonmouth.gif ------- Am 7/6/20 um 10:21 AM schrieb Stefan Petri: > s.u. , ich hatte das auch im Cloud-Deck skizziert, und die technischen > Details ins Redmine geschrieben. > > Da gibts jetzt also ein Routing fuer die Antarktis, habe ich aber noch > nicht mit der Standard-DDM30 zusammengefuehrt. Und auch sonst noch > nichts weiter mit Kuestenlinien etc gemacht. ------- On 06.07.20 10:34, Sibyll Schaphoff wrote: > Fuer die Anpassung habe ich ein tool, ich habe die Kuestenlinie angepasst > und muss jetzt noch den Abfluss der grossen Fluesse rausleiten, mache das > aber auf Grundlage der Flowdirection map. > > Hast Du eine flowdirection Karte fuer die Antarktis, die wuerde ich gerne > mit der anderen zusammenfuehren, dass wir je nach Beduerfnis das routing > neu erstellen koennen, dazu muesste die Grundlage aber passen. On 06.07.20 18:33, Sibyll Schaphoff wrote: > so hab erstmal die beiden flowdirection maps zusammengefuehrt und werde > fuer die fehlenden Zellen an den Kuestenraendern auch die direction map > deiner Karte nehmen, die allerdings ansonsten ganz andere Richtungen > hat, was an den Kuestenraendern aber unerheblich ist, da kann man meiner > Meinung ruhig die benutzen, die Du erstellt hast, einige wenige Zellen > bleiben uebrig. Ich schaue dann mal, ob die ueberhaupt ein Hinterland > haben oder ob ich die dann einfach an Ort und Stelle entwaessern lasse. ------- On 09.07.20 10:28, Sibyll Schaphoff wrote: > Ich habe eine erste > Version der river routing map erstellt, wie im POEM meeting berichtet. > Ich habe diese Version 1 genannt, siehe Kartei - multi-core runoff > integration. Ich denke, dass man da noch einiges verbessern kann, was > ich dann auch so nach und nach machen werde. Das ist allerdings wirklich > Handarbeit. Die bereitgestellte drainage map wird aber erst mal so > funktionieren. > Ich bin mir nicht sicher wieviel Aufwand wir mit der Antarktis/Groenland > treiben sollen, da den Part ja bald PISM uebernehmen wird. Hier waere sehr > viel Handarbeit noetig, um die Fliessrichtungen zu korrigieren. Wenn wir > eine Version haben wollen, die immer ohne PISM laufen soll, dann muss > ich weiter nach einem guten Hoehenmodell suchen, was ich bisher noch > nicht auftreiben konnte. > > Es waere schoen, wenn Stefan die erste Version testen koennte, dann koennten > wir schauen, ob diese schon mal funktioniert. Ich werde in der > Zwischenzeit, die flowdirection weiter per Hand korrigieren, dass wir so > bald wie moeglich eine zuverlaessige Variante haben. This can be found on: /p/projects/open/sibyll/POEM/exp/CM2M_coarse_BLING_LPJ_05/Data-For-LPJ/Rivers/ drainage_DDM30_v1.0.clm . The corresponding netcdf is called drainage_DDM30_v1.0.nc. -rw-rw-r-- 1 sibylls open 739528 Jul 9 09:18 DDM30_lpj_flowdir_3.asc -rw-r--r-- 1 sibylls open 727099 Jul 9 09:51 drainage_DDM30_v1.0.clm -rw-r--r-- 1 sibylls open 2009732 Jul 9 09:51 drainage_DDM30_v1.0.nc -> OK, lets configure that into POEM36/ def sym greenland= X=-93:-17/Y=60:85 def sym northamerica= X=-168:-54/Y=22:80 def sym southamerica= X=-85:-35/Y=-60:15 def sym mideurope= X=-10:30/Y=36:60 def sym scandinavia= X=4:40/Y=55:72 def sym europe= X=-10:40/Y=36:72 def sym mediteran= X=-10:40/Y=30:45 def sym antarctica= X=0:360/Y=-90:-60 def sym africa= X=-20:65/Y=-40:35 def sym china= X=60:150/Y=20:70 def sym arabia= X=30:65/Y=10:35 def sym amazon= x=80w:40w/y=10s:12n def sym siberia= X=60:192/Y=60:80 can d/all use 00010103.lpj_static.nc let lpj_runoff_src_lon=0*LPJ_RUNOFF_DEST_lon[d=1]+x[d=1,g=LPJ_RUNOFF_DEST_lon] let lpj_runoff_src_lat=0*LPJ_RUNOFF_DEST_lat[d=1]+y[d=1,g=LPJ_RUNOFF_DEST_LAT] let seq_src_lon=ysequence(lpj_runoff_src_lon) let seq_src_lat=ysequence(lpj_runoff_src_lat) let seq_dst_lon=ysequence(LPJ_RUNOFF_DEST_lon[d=1]) let seq_dst_lat=ysequence(LPJ_RUNOFF_DEST_LAT[d=1]) let lon2=xcat(seq_src_lon,seq_dst_lon) let lonbad=if seq_src_lon lt 0 then seq_src_lon let/unit=degrees_E lon3=xcat(lon2,lonbad) let lat2=xcat(seq_src_lat,seq_dst_lat) let/unit=degrees_N lat3=xcat(lat2,lonbad) plot/vs/line/nolabel lon3,lat3 let landmask=if LPJ_LAND_MASK[d=1] gt 0 then 1 else 0 contour/over/nolabel/nokey/levels=2/size=0.00001/color=blue landmask ------- On 22.07.20 18:26, Stefan Petri wrote: > a quick note in the late afternoon: > following our discussion in the POEm coffee, I looked deeper into the > runoff issue. > There is one cell in which the runoff value grows continously, at > X=237.25E Y=47.25N (i=474,j=274). I have not yet checked the runoff > routing in that area . maybe that is connected to a routing loop? stay > tuned ... On 22.07.20 18:58, Sibyll Schaphoff wrote: > it is no problem if we have routing loops, but if the inflow is higher > than the PET the amount of water will increase continuously. Especially > in lakes it is implemented that rivers flow through the lake and > sometimes it ends there. > > I need to think about how to handle this case in LPJ. It is not only a > problem of the routing scheme. ------- On 23.07.20 13:48, Sibyll Schaphoff wrote: > hab ne neue Version vom river routing. Wenn du weitere so extreme > Zellen faendest ware das der wichtigste Hinweis, um das river routing > anzupassen. > > die neueste Version ist: > > /p/projects/open/sibyll/POEM/exp/CM2M_coarse_BLING_LPJ_05/Data-For-LPJ/ > Rivers/drainage_DDM30_v1.03.clm On 23.07.20 15:36, Sibyll Schaphoff wrote: > die Kuestenzellen die nur sich selbst als Einzugsgebiet haben sind nicht > so kritisch, aber auch die bin ich dabei rauszuschmeissen. > > Hab auch ein tool gebastelt und schau mal wie das weiter geht das > Kaspische Meer routet auch in sich selbst, was erstmal richtig und gut > ist aber es koennte sein, dass wir hier auch zu viel Wasser bekommen ueber > die Jahre. Das ist echt bloede Handarbeit das routing scheme anzupassen.