River outlet locations in GETM
Bjarne Büchmann
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
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
To view this discussion on the web visit https://groups.google.com/d/msgid/getm-users/014801d916c7%240d1197a0%242734c6e0%24%40bolding-bruggeman.com.
Bjarne Büchmann
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
To view this discussion on the web visit https://groups.google.com/d/msgid/getm-users/CAEXw-aZc5rE-9K7M%3D_DZNZr6pEM23Tq%3DxkoybftcPwhYKHG%2Bug%40mail.gmail.com.
Bjarne Büchmann
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
To view this discussion on the web visit https://groups.google.com/d/msgid/getm-users/014801d916c7%240d1197a0%242734c6e0%24%40bolding-bruggeman.com.
Bjarne Büchmann
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
To view this discussion on the web visit https://groups.google.com/d/msgid/getm-users/adb2986c4fed46a4954c92225121baf2%40fcoo.dk.
Jorn Bruggeman
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,
To view this discussion on the web visit https://groups.google.com/d/msgid/getm-users/58aadb849613488992ada750c895e6b7%40fcoo.dk.
Karsten Bolding
To view this discussion on the web visit https://groups.google.com/d/msgid/getm-users/002101d91ebc%24b832c440%2428984cc0%24%40bolding-bruggeman.com.