River outlet locations in GETM

15 views
Skip to first unread message

Bjarne Büchmann

unread,
Dec 21, 2022, 4:53:35 AM12/21/22
to getm-...@googlegroups.com

Mostly to Adolf:

 

On the recent getm-devel meeting, there were some concern about the increasing number of freshwater outlets in modelling.

Firstly – we (GEOMETOC) also encounter this issue. Even a fairly small model area may contain O(1000) river points.

Obviously, this means that manually handling the river-data and creating “rivers.dat” for GETM becomes impractical.

 

Presently, I am updating our routine for locating river outlets relative to GETM bathy/grid, so that we do not have to go over the manual process.

 

Adolf: Do you have concerns about the numerics and/or computational efficiency of the present way rivers are handled in (legacy) GETM. Or are your concern mostly with the practical handling/creation of the necessary setup files. If the latter, then maybe I can help you out.

 

I expect to update the tool (getm-utils, find_nearest_cpoint.py) to take a list of lines like eg “lon lat rivername # comments”, and write two files – one with indices of nearest point for each, and one for nearest *water* point. Both in GETM rivers.dat format. Also, I intend to add information on how far the located bathy point is from the input river position.

 

Would this be useful to you? And if so, would anything be missing (need-to-have / nice-to-have)?

 

Best,

 

Bjarne

 

Joint GEOMETOC Support Centre

 

Lautrupbjerg 1-5 - 2750 Ballerup
Danish Defence Acquisition and Logistics Organisation
MOBIL: +45 4078 7320
FIIN: FMI-MA-OPD04
http://WWW.FCOO.DK/

 


This email was scanned by Bitdefender

Jorn Bruggeman

unread,
Dec 23, 2022, 7:06:58 AM12/23/22
to getm-...@googlegroups.com

Hi Bjarne, Adolf,

 

Commenting on this from a pygetm angle (likely relevant for JRC in particular): pygetm does not require rivers.dat, although it can read it if already available. Typically, you’d instead take river information directly from whatever source dataset you have (most formats are easily opened/parsed with Python, incl. the proposed “lon lat rivername # comments”, but also xls, various database formats). You then add the individual rivers using either latitude,longitude (pygetm maps to the nearest active wet cell in the global grid), or alternatively, an i,j location. That is all online, though it would be straightforward to leverage the same APIs to do the lat,lon -> i,j  mapping in preprocessing.

 

Happy holidays,

 

Jorn

--

---
You received this message because you are subscribed to the Google Groups "GETM-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to getm-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/getm-users/3730d3abf9094311b6a202eeaf59f728%40fcoo.dk.

Adolf Stips

unread,
Dec 24, 2022, 8:50:06 AM12/24/22
to getm-...@googlegroups.com

Dear Bjarne and Jorn and All,

first I wish you a Merry Christmas and soon a Happy New Year.

Indeed our main concern was not related to the efficiency, that seemed always to be very fast accomplished, 
but rather to the preprocessing work when establishing the river file. (Admittingly trials with river numbers > 10000 did show some effect of slowing down,
but this was not rigorously investigated.

We have a Matlab script for this conversion, but that never worked to create all the river entries automatically, somehow some manual polishing was always left over. 

As said, one "solution" was to drop small outlets, typically with discharge < 5 m^3/s (or even 10), which gets rid of 90% of the outlets (and between 5-10% of the total discharge).

Best wishes, Adolf

 


Bjarne Büchmann

unread,
Dec 26, 2022, 1:41:34 AM12/26/22
to getm-...@googlegroups.com

Hi Adolf,

 

>first I wish you a Merry Christmas and soon a Happy New Year.

 

The same goes to you and your family.

 

If you have an example on your river metadata (position+name) input, then I will try to take that into account in my update of the script in getm-utils.

 

 

MED VENLIG HILSEN / BEST REGARDS
 
Bjarne Büchmann
Joint GEOMETOC Support Centre

MOBIL +45 40 78 73 20

Bjarne Büchmann

unread,
Jan 2, 2023, 3:49:15 AM1/2/23
to getm-...@googlegroups.com

Hi Jorn,

 

Thank you very much for your input.

 

> That is all online, though it would be straightforward to leverage the same

> APIs to do the lat,lon -> i,j  mapping in preprocessing.

 

After some consideration, I do not think that requiring pygetm in its entirety will be the right solution for pre- and post-processing for legacy GETM.

I still would very much like to collaborate, wherever it is possible, but – seen from this side – interfacing to methods/APIs “inside” pygetm does not seem like the best solution.

One path for collaboration, could be a common “utils” repo, where we could have py-tools/libs/modules, which pygetm could interface with in an on-line manner, and CLI-wrappers could be written for legacy GETM users.

For now, I will continue to maintain the “getm-utils” repo for pre- and postproc tools. I will be more than interested in a re-structuring of these tools – possibly moving to a new common repo as necessary.

 

MED VENLIG HILSEN / BEST REGARDS
 
Bjarne Büchmann
Joint GEOMETOC Support Centre

MOBIL +45 40 78 73 20

 

Bjarne Büchmann

unread,
Jan 2, 2023, 8:49:41 AM1/2/23
to getm-...@googlegroups.com

Hi Adolf,

 

I now have something, which can read a GETM bathy and a list of river positions (eg lon lat riverid) from file, and generate legacy getm rivers.dat.

In my test case with O(700) rivers on a (admittedly small) 330x400 bathy, the preproc time is about 6s: O(1-2s) for bathy/metadata setup and <0.01 s per river after that.

 

Code wil be shared on getm-utils, and I will be happy to discuss formats for input (and output).

 

MED VENLIG HILSEN / BEST REGARDS
 
Bjarne Büchmann
Joint GEOMETOC Support Centre

MOBIL +45 40 78 73 20

 

From: 'Bjarne Büchmann' via GETM-users [mailto:getm-...@googlegroups.com]

Sent: 26. december 2022 07:42
To: getm-...@googlegroups.com

Jorn Bruggeman

unread,
Jan 2, 2023, 10:13:10 AM1/2/23
to getm-...@googlegroups.com

Hi Bjarne,

 

Sure, I did not imply that pygetm should replace getm-utils. I flagged this primary for those that already are using pygetm, e.g., JRC and PML, as they have other options for river specification that are generally preferable. Thus, pygetm users can likely do without some of the functionality of getm-util. That also includes subdomain decomposition and output merging, which pygetm handles internally.

 

As this was the first time pygetm was mentioned on getm-users, I’d better introduce it: it is a complete rewrite of GETM in Python (mostly) and Fortran (performance-critical sections). It describes the same processes and uses the same numerical approaches as legacy GETM, but does not share the same code. https://github.com/BoldingBruggeman/getm-rewrite

 

Cheers,

Karsten Bolding

unread,
Jan 2, 2023, 10:21:24 AM1/2/23
to getm-...@googlegroups.com
And maybe to avoid clutter on this mailing list in the future - communication in relation to the GETM rewrite is NOT to be done on this mailing list.

When we are ready with a release we will provide information on communication.

Karsten



--
Reply all
Reply to author
Forward
0 new messages