anuga-user — Discussions about the usage of ANUGA

Re: [Anuga-user] Create a mesh-file

[Stephen R. <ste...@an...>]

Hi Stefan,

The info needed by anuga to create a domain is simply an array vertex coordinates (vertices), an array of triangles (vertex ids) (triangles) and a dictionary of boundary tags (the key to the dictionary a tuple of triangle id and edge id).

I seem to recall that the boundary dictionary is fairly easily created from the segments and segment_markers arrays.

Have a look at the code to rectangular_cross to see the format.

Cheers
Steve

[cid:3a1e6496-b4f0-4fce-b3ec-dfd9abaec161]

==============================
Emeritus Prof Stephen Roberts (he/him)
Mathematical Sciences Institute
Hanna Neumann Building #145
The Australian National University
Canberra, ACT 2600 AUSTRALIA
T: +61 2 61254445 | E: ste...@an...

CRICOS Provider: 00120C

________________________________
From: S.Kummer via Anuga-user <anu...@li...>
Sent: Thursday, 30 May 2024 7:45 PM
To: anu...@li... <anu...@li...>
Subject: [Anuga-user] Create a mesh-file

Hi,
what is the shortest way to create a mesh-file (*.msh; netcdf) from a
triangulation done with the python module triangle
(https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdrufat%2Ftriangle&data=05%7C02%7Cstephen.roberts%40anu.edu.au%7C9e90c1ce198c46d8ce5308dc808d68ad%7Ce37d725cab5c46249ae5f0533e486437%7C0%7C0%7C638526592042907048%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=8lQ9scvfw9Z2IrhZNcxURvFrjS7MhZuCejSrCo%2BLBGk%3D&reserved=0<https://github.com/drufat/triangle>).

The result of the triangulation, which is also used by anuga
(mesh_engine -> mesh_engine.py -> generate_mesh), is a dictionary with
the keys
"vertices, vertex_attributes, vertex_markers, triangles,
triangle_max_area, triangle_attributes, segments, segment_markers,
holes, regions, neighbors, edges, edge_markers".

How can I use this returned dictionary to directly create an anuga
netcdf-meshfile (*.msh) without using the modules
mesh_engine.py, loadASCII.py or mesh.py?


Cheers
Stefan


_______________________________________________
Anuga-user mailing list
Anu...@li...
https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fanuga-user&data=05%7C02%7Cstephen.roberts%40anu.edu.au%7C9e90c1ce198c46d8ce5308dc808d68ad%7Ce37d725cab5c46249ae5f0533e486437%7C0%7C0%7C638526592042918278%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=n9j8PJ9JBU0YIH1DvAF0ufqTPv8VzoMpDajtMPehQ%2Bo%3D&reserved=0<https://lists.sourceforge.net/lists/listinfo/anuga-user>

[Anuga-user] Create a mesh-file

[S.Kummer <ste...@we...>]

Hi,
what is the shortest way to create a mesh-file (*.msh; netcdf) from a
triangulation done with the python module triangle
(https://github.com/drufat/triangle).

The result of the triangulation, which is also used by anuga
(mesh_engine -> mesh_engine.py -> generate_mesh), is a dictionary with
the keys
"vertices, vertex_attributes, vertex_markers, triangles,
triangle_max_area, triangle_attributes, segments, segment_markers,
holes, regions, neighbors, edges, edge_markers".

How can I use this returned dictionary to directly create an anuga
netcdf-meshfile (*.msh) without using the modules
mesh_engine.py, loadASCII.py or mesh.py?


Cheers
Stefan

[Anuga-user] anuga has a read grid coding error while running on linux

[<287...@qq...>]

Hello, I am a newbie to using anuga.
I'm running it fine in windows, but running it in Ubuntu gives me read grid file encoding error and can't open grid file on behalf of the grid file.
This is my problem：
UnicodeDecodeError: 'utf-8' codec can't decode byte 0x88 in position 0: invalid start byte


During handling of the above exception, another exception occurred:




I've tried other coding methods to solve the problem, but with no success.

[Anuga-user] test email

[Nisha A. <itl...@gm...>]

Ignore

Re: [Anuga-user] Creating a Transmissive boundary condition in parallel

[Nelson T. <nt...@ut...>]

Hi Steve and Gareth:

Thank you both for your help. I realize after looking more closely at the
available boundary conditions that it is easy to pull the boundary stage
and modify it dynamically through the boundary condition itself, as you
described above. So I have created a new boundary condition that requires a
stage difference to subtract from the boundary, while keeping momentum at
zero to avoid instabilities. And indeed, it is working in parallel.

Cheers!
Nelson

On Fri, Nov 10, 2023 at 12:22 AM Stephen Roberts <ste...@an...>
wrote:

> Hi Nelson.
>
> Regarding your first issue. Within the evolve loop, we now have the option
> of outputstep in addition to yieldstep. Checkout
> https://anuga.readthedocs.io/en/latest/evolve.html
>
> This would allow you to have a small yieldstep to do your update, and a
> large outputstep to save your simulation into the sww file.
>
> Regarding both of your issues, it might be best to just implement a new
> boundary condition.
>
> There are a range of boundary conditions defined in the file boundary.py
> in the anuga_core/anuga/shallow_water directory.
>
> Boundary conditions have available the interior stage, xmom, ymom, and bed
> of the flow on the boundary edge, and calculates the appropriate stage,
> xmom and ymom (assuming the same bed value) on the exterior of the boundary
> edge.
>
> So it would be easy to set stage to the interior stage minus some small
> amount. By the way this works locally and so would work in parallel.
>
> The standard transmissive boundary condition tends to become unstable if
> the flow changes from outflow to inflow (and then tends to produce a
> positive feedback).
>
> So your new boundary condition should probably also set the xmom and ymom
> to zero if an an inflow situation arises. It is possible to calculate the
> normal component of interior (xmom, ymom) and if negative zero the exterior
> normal component of  (xmom, ymom).
>
> I am a little busy at the moment to code and test this myself (working on
> a gpu version of anuga) but would be happy to provide advice if you wanted
> to give it a go yourself.
>
> Cheers
> Steve
>
>
>
>
>
> ==============================
> Emeritus Prof Stephen Roberts (he/him)
> Mathematical Sciences Institute
> Hanna Neumann Building #145
> The Australian National University
> Canberra, ACT 2600 AUSTRALIA
> T: +61 2 61254445 | E: ste...@an...
>
> CRICOS Provider: 00120C
>
> ------------------------------
> *From:* Nelson Tull <nt...@ut...>
> *Sent:* Friday, 10 November 2023 6:58 AM
> *To:* anu...@li... <anu...@li...>
> *Subject:* [Anuga-user] Creating a Transmissive boundary condition in
> parallel
>
> Hello all,
>
> I would like to be able to create a transmissive boundary condition at the
> outlet of my domain, so that water flowing into the boundary elements flows
> out of the domain through the boundary. However, ANUGA's built-in
> transmissive boundary has always been unstable for me, as the ANUGA manual
> suggests.
>
> In the manual, there is a suggested workaround to create a Dirichlet BC
> with a value just below the model stage along the boundary. Considering
> that the need for a transmissive BC likely pertains to a system where the
> stage is not constant along the boundary, I would think to query the model
> stage along the boundary, and apply a new Dirichlet BC with a stage just
> below my model stage. To do this, I might use the
> get_triangle_containing_point() function to identify an element along the
> boundary, get its stage value, and then overwrite the boundary definitions
> with a new Dirichlet water level, using domain.set_boundary(), all within
> the domain evolution loop.
>
> I am stuck with two issues related to this approach:
>
> (1) This dynamic Dirichlet BC would only be updated at every yield step,
> rather than every model time step. I can imagine issues arising in
> situations where the stage changes quite a bit within one yield step.
>
> (2) For a parallel domain, there is a further complication related to
> identifying the subdomain that contains the boundary element we are
> querying. In the past, I have worked around this using "try-except"
> statements and the "send" and "receive" functions in ANUGA to (a) find the
> subdomain containing the triangle, (b) pass that value to each
> processor, and (c) have all processors run the domain_set_boundary()
> function with the new value. However, this approach seems overly
> complicated.
>
> Has anyone found a simpler way to apply a quasi-transmissive boundary
> condition in ANUGA? And how could this be implemented for a parallel
> simulation?
>
> Thanks!
>
> Nelson Tull
> The University of Texas at Austin
>

Re: [Anuga-user] Creating a Transmissive boundary condition in parallel

[Stephen R. <ste...@an...>]

Hi Nelson.

Regarding your first issue. Within the evolve loop, we now have the option of outputstep in addition to yieldstep. Checkout https://anuga.readthedocs.io/en/latest/evolve.html

This would allow you to have a small yieldstep to do your update, and a large outputstep to save your simulation into the sww file.

Regarding both of your issues, it might be best to just implement a new boundary condition.

There are a range of boundary conditions defined in the file boundary.py in the anuga_core/anuga/shallow_water directory.

Boundary conditions have available the interior stage, xmom, ymom, and bed of the flow on the boundary edge, and calculates the appropriate stage, xmom and ymom (assuming the same bed value) on the exterior of the boundary edge.

So it would be easy to set stage to the interior stage minus some small amount. By the way this works locally and so would work in parallel.

The standard transmissive boundary condition tends to become unstable if the flow changes from outflow to inflow (and then tends to produce a positive feedback).

So your new boundary condition should probably also set the xmom and ymom to zero if an an inflow situation arises. It is possible to calculate the normal component of interior (xmom, ymom) and if negative zero the exterior normal component of  (xmom, ymom).

I am a little busy at the moment to code and test this myself (working on a gpu version of anuga) but would be happy to provide advice if you wanted to give it a go yourself.

Cheers
Steve




[cid:eca5ab75-b061-44c3-a3fe-c89c78d5f4b2]

==============================
Emeritus Prof Stephen Roberts (he/him)
Mathematical Sciences Institute
Hanna Neumann Building #145
The Australian National University
Canberra, ACT 2600 AUSTRALIA
T: +61 2 61254445 | E: ste...@an...

CRICOS Provider: 00120C

________________________________
From: Nelson Tull <nt...@ut...>
Sent: Friday, 10 November 2023 6:58 AM
To: anu...@li... <anu...@li...>
Subject: [Anuga-user] Creating a Transmissive boundary condition in parallel

Hello all,

I would like to be able to create a transmissive boundary condition at the outlet of my domain, so that water flowing into the boundary elements flows out of the domain through the boundary. However, ANUGA's built-in transmissive boundary has always been unstable for me, as the ANUGA manual suggests.

In the manual, there is a suggested workaround to create a Dirichlet BC with a value just below the model stage along the boundary. Considering that the need for a transmissive BC likely pertains to a system where the stage is not constant along the boundary, I would think to query the model stage along the boundary, and apply a new Dirichlet BC with a stage just below my model stage. To do this, I might use the get_triangle_containing_point() function to identify an element along the boundary, get its stage value, and then overwrite the boundary definitions with a new Dirichlet water level, using domain.set_boundary(), all within the domain evolution loop.

I am stuck with two issues related to this approach:

(1) This dynamic Dirichlet BC would only be updated at every yield step, rather than every model time step. I can imagine issues arising in situations where the stage changes quite a bit within one yield step.

(2) For a parallel domain, there is a further complication related to identifying the subdomain that contains the boundary element we are querying. In the past, I have worked around this using "try-except" statements and the "send" and "receive" functions in ANUGA to (a) find the subdomain containing the triangle, (b) pass that value to each processor, and (c) have all processors run the domain_set_boundary() function with the new value. However, this approach seems overly complicated.

Has anyone found a simpler way to apply a quasi-transmissive boundary condition in ANUGA? And how could this be implemented for a parallel simulation?

Thanks!

Nelson Tull
The University of Texas at Austin

Re: [Anuga-user] Creating a Transmissive boundary condition in parallel

[Gareth D. <gar...@gm...>]

Hi Nelson,

I don't know the answer to your question, but wanted to note that in 
principle, the Transmissive boundary condition is only appropriate for 
supercritical outflow (outgoing speed > sqrt(gravity * depth)).

With supercritical outflow, the flow state at the boundary cannot 
influence the interior of your model. It's fairly rare to model 
situations like this. More often some kind of radiation boundary is 
needed, which combines information from inside the model with some kind 
of exterior forcing. There are a bunch of approaches in general, but I 
forget the options in ANUGA.

All the best,
Gareth

On 10/11/23 07:28, Nelson Tull wrote:
> Hello all,
>
> I would like to be able to create a transmissive boundary condition at 
> the outlet of my domain, so that water flowing into the boundary 
> elements flows out of the domain through the boundary. However, 
> ANUGA's built-in transmissive boundary has always been unstable for 
> me, as the ANUGA manual suggests.
>
> In the manual, there is a suggested workaround to create a Dirichlet 
> BC with a value just below the model stage along the boundary. 
> Considering that the need for a transmissive BC likely pertains to a 
> system where the stage is not constant along the boundary, I would 
> think to query the model stage along the boundary, and apply a new 
> Dirichlet BC with a stage just below my model stage. To do this, I 
> might use the get_triangle_containing_point() function to identify an 
> element along the boundary, get its stage value, and then overwrite 
> the boundary definitions with a new Dirichlet water level, using 
> domain.set_boundary(), all within the domain evolution loop.
>
> I am stuck with two issues related to this approach:
>
> (1) This dynamic Dirichlet BC would only be updated at every yield 
> step, rather than every model time step. I can imagine issues arising 
> in situations where the stage changes quite a bit within one yield step.
>
> (2) For a parallel domain, there is a further complication related to 
> identifying the subdomain that contains the boundary element we are 
> querying. In the past, I have worked around this using "try-except" 
> statements and the "send" and "receive" functions in ANUGA to (a) find 
> the subdomain containing the triangle, (b) pass that value to each 
> processor, and (c) have all processors run the domain_set_boundary() 
> function with the new value. However, this approach seems overly 
> complicated.
>
> Has anyone found a simpler way to apply a quasi-transmissive boundary 
> condition in ANUGA? And how could this be implemented for a parallel 
> simulation?
>
> Thanks!
>
> Nelson Tull
> The University of Texas at Austin
>
>
> _______________________________________________
> Anuga-user mailing list
> Anu...@li...
> https://lists.sourceforge.net/lists/listinfo/anuga-user

[Anuga-user] Creating a Transmissive boundary condition in parallel

[Nelson T. <nt...@ut...>]

Hello all,

I would like to be able to create a transmissive boundary condition at the
outlet of my domain, so that water flowing into the boundary elements flows
out of the domain through the boundary. However, ANUGA's built-in
transmissive boundary has always been unstable for me, as the ANUGA manual
suggests.

In the manual, there is a suggested workaround to create a Dirichlet BC
with a value just below the model stage along the boundary. Considering
that the need for a transmissive BC likely pertains to a system where the
stage is not constant along the boundary, I would think to query the model
stage along the boundary, and apply a new Dirichlet BC with a stage just
below my model stage. To do this, I might use the
get_triangle_containing_point() function to identify an element along the
boundary, get its stage value, and then overwrite the boundary definitions
with a new Dirichlet water level, using domain.set_boundary(), all within
the domain evolution loop.

I am stuck with two issues related to this approach:

(1) This dynamic Dirichlet BC would only be updated at every yield step,
rather than every model time step. I can imagine issues arising in
situations where the stage changes quite a bit within one yield step.

(2) For a parallel domain, there is a further complication related to
identifying the subdomain that contains the boundary element we are
querying. In the past, I have worked around this using "try-except"
statements and the "send" and "receive" functions in ANUGA to (a) find the
subdomain containing the triangle, (b) pass that value to each
processor, and (c) have all processors run the domain_set_boundary()
function with the new value. However, this approach seems overly
complicated.

Has anyone found a simpler way to apply a quasi-transmissive boundary
condition in ANUGA? And how could this be implemented for a parallel
simulation?

Thanks!

Nelson Tull
The University of Texas at Austin

Re: [Anuga-user] Code snippet for GIS-based polygon file format (GPKG, GeoJSON etc.) conversion

[Stephen R. <ste...@an...>]

Hi Sebastian,

Looks like the geopandas library can read gpkg files.

Perhaps you can provide a small example gpkg file for us to work on.

We could then at least put your request in as an issue on the GitHub anuga-community/anuga_core site.

Cheers Steve


Get Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
From: Sebastian Schoeller <seb...@gm...>
Sent: Thursday, July 20, 2023 2:10:41 AM
To: anu...@li... <anu...@li...>
Subject: [Anuga-user] Code snippet for GIS-based polygon file format (GPKG, GeoJSON etc.) conversion

[You don't often get email from seb...@gm.... Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

Dear all,


I have seen that the Patong example uses subfolders for fetching polygon
information.

In my case polygons are stored in a GPKG file and managed through QGIS.
Exporting thousands of geometries into a subfolder may only be done
programmatically. Is anyone willing to share a python snippet for doing
so using GeoJSON / GPKG or other common file formats?


Best regards


Sebastian



_______________________________________________
Anuga-user mailing list
Anu...@li...
https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fanuga-user&data=05%7C01%7Cstephen.roberts%40anu.edu.au%7C0ac7277da089465d69fb08db8872d69c%7Ce37d725cab5c46249ae5f0533e486437%7C0%7C0%7C638253799041626628%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=DaFv0njuEGAcnFLUzDDQSbyyC6TYYoP1bMI95XzMSu8%3D&reserved=0<https://lists.sourceforge.net/lists/listinfo/anuga-user>

[Anuga-user] Code snippet for GIS-based polygon file format (GPKG, GeoJSON etc.) conversion

[Sebastian S. <seb...@gm...>]

Dear all,


I have seen that the Patong example uses subfolders for fetching polygon 
information.

In my case polygons are stored in a GPKG file and managed through QGIS. 
Exporting thousands of geometries into a subfolder may only be done 
programmatically. Is anyone willing to share a python snippet for doing 
so using GeoJSON / GPKG or other common file formats?


Best regards


Sebastian

Re: [Anuga-user] Searching example for urban drainage model (~25km2)

[Stephen R. <ste...@an...>]

Hi Sebastian,

1 # parallelize merewhether case

You need to first create your domain on one processor and then distribute to all the active processors.

The examples in anuga_core/examples/parallel and in particular https://github.com/anuga-community/anuga_core/blob/main/examples/parallel/run_parallel_merimbula.py

should help here.

2 # alter input method to precipitation

To add rain you can use a rate operator.

The examples in anuga_core/examples/operators and in particular https://github.com/anuga-community/anuga_core/blob/main/examples/operators/run_rate_spatial_operator.py

should help.

I have been working on using xarray to provide time varying rain data from a file. The code is there in the develop branch but I haven't had time to add unittest or example scripts as yet.

Cheers
Steve



==============================
Emeritus Prof Stephen Roberts (he/him)
Mathematical Sciences Institute
Hanna Neumann Building #145
The Australian National University
Canberra, ACT 2600 AUSTRALIA
T: +61 2 61254445 | E: ste...@an...

CRICOS Provider: 00120C

________________________________
From: Sebastian Schoeller <seb...@gm...>
Sent: Monday, 17 July 2023 10:16 PM
To: anu...@li... <anu...@li...>
Subject: [Anuga-user] Searching example for urban drainage model (~25km2)

[You don't often get email from seb...@gm.... Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

Dear all,


thanks for Anuga. I am looking for a parallelized example case for urban
flooding model with precipitation input. Currently I am testing the
mereweather cast study. Assistance on how achieve the following steps
are kindly appreciated

1#parallelize mereweather case

2#alter input method to precipitation


Kind regards


Sebastian



_______________________________________________
Anuga-user mailing list
Anu...@li...
https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fanuga-user&data=05%7C01%7Cstephen.roberts%40anu.edu.au%7C0dbc28d21f0844fbca9b08db86c3f08a%7Ce37d725cab5c46249ae5f0533e486437%7C0%7C0%7C638251948340047539%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=I4d%2Bz5GS31ymcOI0JImFRo2mrQFbeUEnKdRxrBrnwkU%3D&reserved=0<https://lists.sourceforge.net/lists/listinfo/anuga-user>

[Anuga-user] Searching example for urban drainage model (~25km2)

[Sebastian S. <seb...@gm...>]

Dear all,


thanks for Anuga. I am looking for a parallelized example case for urban 
flooding model with precipitation input. Currently I am testing the 
mereweather cast study. Assistance on how achieve the following steps 
are kindly appreciated

1#parallelize mereweather case

2#alter input method to precipitation


Kind regards


Sebastian

Re: [Anuga-user] Issues importing an external mesh into a model

[Soloy, A. (US 334F) <ant...@jp...>]

Hi Steve,

Thank you for your answer, it was helpful.
The problem was indeed coming from an incorrect definition of the boundary tags. I was using the nodes located at the boundary instead of the ones on the opposite vertex to the triangles edges forming the boundary.
This being fixed, the model now runs correctly.

Thanks again
Antoine

From: Stephen Roberts <ste...@an...>
Date: Saturday, December 10, 2022 at 3:27 AM
To: anu...@li... <anu...@li...>, Soloy, Antoine (US 334F) <ant...@jp...>
Subject: [EXTERNAL] Re: Issues importing an external mesh into a model
Hi Antoine,

Nice meshing. I will have to checkout OceanMesh2D.

You need to create a dictionary of boundary segments with keys of the form  (tri_id, vertex_id)   (where tri_id is the id of a triangle on the boundary, and vertex_id being 0,1 or 2 corresponding to the edge opposite the associated vertex), and the value being a boundary tag (a string like 'exterior' or 'ocean' etc).

>From the first figure, I assume the yellow are associated with very thin channels.

The second figure seem to show that you have not set up the boundary tags correctly. Indeed the tide boundary segments are strangely offset by a layer.

Happy to help you get the boundary dictionary correct. We should be able to create a function which takes the boundary definition from OceanMesh2D and produce a dictionary appropriate for anuga.

Cheers
Steve



==============================

Emeritus Prof Stephen Roberts (he/his)

Mathematical Sciences Institute

Hanna Neumann Building #145

The Australian National University

Canberra, ACT 2600 AUSTRALIA

T: +61 2 61254445 | E: ste...@an...



CRICOS Provider: 00120C

________________________________
From: Soloy, Antoine (US 334F) via Anuga-user <anu...@li...>
Sent: Saturday, 10 December 2022 12:46 PM
To: anu...@li... <anu...@li...>
Subject: [Anuga-user] Issues importing an external mesh into a model


Hi all,



I am having a bit of difficulty importing an externally designed mesh into Anuga, and I was hoping to find some help here.



The situation is the following:



The studied domain covers a quite large coastal region (~ 80 x 120 km) that includes a few hundreds of islands and a complex network of wetland channels. These channels are the main object of interest here, and need to be resolved with a high resolution. However, optimizing a mesh for such a large and heterogeneous area can be tedious even with the help of built-in tools provided by Anuga.

Some external programs such as OceanMesh2D (see https://github.com/CHLNDDEV/OceanMesh2D) offer to do this job externally, taking into account the level of complexity that we need for this region. I was able use the tool to produce an optimized mesh and to import its vertices, triangles and external boundaries (as indices of triangles, going counterclockwise) in a “Domain” class from “anuga.shallow_water.shallow_water_domain”. Two classes of boundaries are defined, as shown on the figure here bellow: tide (red) and walls (yellow)

[cid:image003.png@01D90BFA.55AA1640]



There is no error returned at this point, and the model is able to evolve.

However, despite being provided with the list of boundary nodes, the Domain class returns an object with additional boundary nodes automatically labeled as “exterior”, most of which are mispositioned (in general, 1 edge away towards the domain center). The figure just below shows the boundary resulting after calling Domain() without providing the boundary argument, for comparison.

[cid:image002.png@01D90BF9.0AB7F310]



As a result, the tidal input is only applied on a few sparse nodes instead of the whole boundary line.

To solve this issue, I tried overwriting the boundary tag dictionary and remove the extra nodes, but it looks like there are more parameters affected by the described misidentification of boundaries, and this action only made it worse.



I would be grateful if anybody had ideas and suggestions on how I could solve this problem, or if there is another way to import an external mesh into Anuga.



Thanks!



Regards,



Antoine Soloy



Post-doctoral researcher

Caltech - Jet Propulsion Laboratory

4800 Oak Grove Drive

Pasadena, CA, USA  91109-8099

Tel: +1 (818) 354-1463

Re: [Anuga-user] Issues importing an external mesh into a model

[Stephen R. <ste...@an...>]

Hi Antoine,

Nice meshing. I will have to checkout OceanMesh2D.

You need to create a dictionary of boundary segments with keys of the form  (tri_id, vertex_id)   (where tri_id is the id of a triangle on the boundary, and vertex_id being 0,1 or 2 corresponding to the edge opposite the associated vertex), and the value being a boundary tag (a string like 'exterior' or 'ocean' etc).

>From the first figure, I assume the yellow are associated with very thin channels.

The second figure seem to show that you have not set up the boundary tags correctly. Indeed the tide boundary segments are strangely offset by a layer.

Happy to help you get the boundary dictionary correct. We should be able to create a function which takes the boundary definition from OceanMesh2D and produce a dictionary appropriate for anuga.

Cheers
Steve



==============================
Emeritus Prof Stephen Roberts (he/his)
Mathematical Sciences Institute
Hanna Neumann Building #145
The Australian National University
Canberra, ACT 2600 AUSTRALIA
T: +61 2 61254445 | E: ste...@an...

CRICOS Provider: 00120C

________________________________
From: Soloy, Antoine (US 334F) via Anuga-user <anu...@li...>
Sent: Saturday, 10 December 2022 12:46 PM
To: anu...@li... <anu...@li...>
Subject: [Anuga-user] Issues importing an external mesh into a model


Hi all,



I am having a bit of difficulty importing an externally designed mesh into Anuga, and I was hoping to find some help here.



The situation is the following:



The studied domain covers a quite large coastal region (~ 80 x 120 km) that includes a few hundreds of islands and a complex network of wetland channels. These channels are the main object of interest here, and need to be resolved with a high resolution. However, optimizing a mesh for such a large and heterogeneous area can be tedious even with the help of built-in tools provided by Anuga.

Some external programs such as OceanMesh2D (see https://github.com/CHLNDDEV/OceanMesh2D) offer to do this job externally, taking into account the level of complexity that we need for this region. I was able use the tool to produce an optimized mesh and to import its vertices, triangles and external boundaries (as indices of triangles, going counterclockwise) in a “Domain” class from “anuga.shallow_water.shallow_water_domain”. Two classes of boundaries are defined, as shown on the figure here bellow: tide (red) and walls (yellow)

[cid:image003.png@01D90BFA.55AA1640]



There is no error returned at this point, and the model is able to evolve.

However, despite being provided with the list of boundary nodes, the Domain class returns an object with additional boundary nodes automatically labeled as “exterior”, most of which are mispositioned (in general, 1 edge away towards the domain center). The figure just below shows the boundary resulting after calling Domain() without providing the boundary argument, for comparison.

[cid:image002.png@01D90BF9.0AB7F310]



As a result, the tidal input is only applied on a few sparse nodes instead of the whole boundary line.

To solve this issue, I tried overwriting the boundary tag dictionary and remove the extra nodes, but it looks like there are more parameters affected by the described misidentification of boundaries, and this action only made it worse.



I would be grateful if anybody had ideas and suggestions on how I could solve this problem, or if there is another way to import an external mesh into Anuga.



Thanks!



Regards,



Antoine Soloy



Post-doctoral researcher

Caltech - Jet Propulsion Laboratory

4800 Oak Grove Drive

Pasadena, CA, USA  91109-8099

Tel: +1 (818) 354-1463

[Anuga-user] Issues importing an external mesh into a model

[Soloy, A. (US 334F) <ant...@jp...>]

Hi all,

I am having a bit of difficulty importing an externally designed mesh into Anuga, and I was hoping to find some help here.

The situation is the following:

The studied domain covers a quite large coastal region (~ 80 x 120 km) that includes a few hundreds of islands and a complex network of wetland channels. These channels are the main object of interest here, and need to be resolved with a high resolution. However, optimizing a mesh for such a large and heterogeneous area can be tedious even with the help of built-in tools provided by Anuga.
Some external programs such as OceanMesh2D (see https://github.com/CHLNDDEV/OceanMesh2D) offer to do this job externally, taking into account the level of complexity that we need for this region. I was able use the tool to produce an optimized mesh and to import its vertices, triangles and external boundaries (as indices of triangles, going counterclockwise) in a “Domain” class from “anuga.shallow_water.shallow_water_domain”. Two classes of boundaries are defined, as shown on the figure here bellow: tide (red) and walls (yellow)
[cid:image003.png@01D90BFA.55AA1640]

There is no error returned at this point, and the model is able to evolve.
However, despite being provided with the list of boundary nodes, the Domain class returns an object with additional boundary nodes automatically labeled as “exterior”, most of which are mispositioned (in general, 1 edge away towards the domain center). The figure just below shows the boundary resulting after calling Domain() without providing the boundary argument, for comparison.
[cid:image002.png@01D90BF9.0AB7F310]

As a result, the tidal input is only applied on a few sparse nodes instead of the whole boundary line.
To solve this issue, I tried overwriting the boundary tag dictionary and remove the extra nodes, but it looks like there are more parameters affected by the described misidentification of boundaries, and this action only made it worse.

I would be grateful if anybody had ideas and suggestions on how I could solve this problem, or if there is another way to import an external mesh into Anuga.

Thanks!

Regards,

Antoine Soloy

Post-doctoral researcher
Caltech - Jet Propulsion Laboratory
4800 Oak Grove Drive
Pasadena, CA, USA  91109-8099
Tel: +1 (818) 354-1463

Re: [Anuga-user] ANUGA

[Stephen R. <ste...@an...>]

Hi Rishabh,

The latest version of anuga is 3.1.9 which is available via PyPi and conda-forge.

Of course the very most recent version is available by cloning from github https://github.com/anuga-community/anuga_core/  (this is mirrored at https://github.com/GeoscienceAustralia/anuga_core)

ANUGA uses MPI for most of its parallelism.

The initial setup of the domain is usually done sequentially (on processes 0). There are some procedures which use OpemMP in this part of the simulation.

Usually, the most time-consuming part of the simulation is the evolve loop. Here MPI provides parallelism.

MPI can allow you to use all the CPU cores available on your system. But as a rough guide, I would restrict the number of cores to something like

np = (number of triangles of the sequential domain)/2000.

Cheers
Steve

==============================
Emeritus Prof Stephen Roberts
Mathematical Sciences Institute
Hanna Neumann Building #145
The Australian National University
Canberra, ACT 2600 AUSTRALIA
T: +61 2 61254445 | E: ste...@an...

CRICOS Provider: 00120C

________________________________
From: Rishabh <ris...@gm...>
Sent: Saturday, 30 July 2022 2:07 AM
To: anu...@li... <anu...@li...>
Subject: [Anuga-user] ANUGA

Hey,
I'm Rishabh, currently interning at NVIDIA and working on parallelizing ANUGA to work on the GPU. I wanted to know the current version of CPU ANUGA and the number of cores it uses. As far as I could find it was multicore.

Thank you,
Rishabh

[Anuga-user] ANUGA

[Rishabh <ris...@gm...>]

Hey,
I'm Rishabh, currently interning at NVIDIA and working on parallelizing
ANUGA to work on the GPU. I wanted to know the current version of CPU ANUGA
and the number of cores it uses. As far as I could find it was multicore.

Thank you,
Rishabh

Re: [Anuga-user] ANUGA model time step and flow through cross section

[Nelson T. <nt...@ut...>]

Steve, Gareth:

Thank you both for your explanations, super helpful and will go a long way
for me.

Two follow-up thought on the time step:
-- I recall testing the CFL value for some prior simulations/domains and
running into issues around 1.4 or so, and per your suggestion I might go
back to that to get some speed up. I'll do some more testing with that to
see what I can get away with, and verify that my solutions are the same.
-- Thank you for providing me with some clarification on how the time step
is calculated. It is important for me to be able to identify the
dt-limiting elements in my mesh, because quick local fixes can increase the
time step significantly without sacrificing accuracy.

On the flow through cross sections:
Your explanations make sense. I would like to avoid a convergence analysis
for this, because my mesh elements can't get much smaller in my river
without having prohibitively large depth/length ratios. I will look at
boundary_flux_integral to get a better sense of how something
mass-conservative could be implemented.

Cheers!
Nelson

Nelson Tull, EIT
The University of Texas at Austin
nt...@ut...


On Wed, Jul 20, 2022 at 6:17 AM Stephen Roberts <ste...@an...>
wrote:

> Hi Nelson,
>
> I think Gareth has essentially provided a good answer to your first
> question.
>
> The condition is  min_over_edges {Radius_T_E/  ( u_E + sqrt(g H_E) }
>
> where the Radius_T is the "radius" of a triangle. Now there are quite a
> few ways to calculate the area. I recall it is the min of the distance from
> centroid to edge midpoint.
>
> The u_E + sqrt(g H_E) are calculated quantities at the midpoint of the
> edge. This would be hard to reproduce exactly just from the data from the
> sww file.
>
> So your difference might be a combination of working with different radii
> and working with U+sqrt(gH) instead of max(U, sqrt(gH)).
>
> Also, there might be a factor of 2 between using diameter or radii.
>
> By the way you can probably get away with using
>
> domain.set_CFL(2.0)
>
> and still maintain stability and accuracy. And the advantage would be the
> simulation will be twice as fast.
>
> As regards the flow through a cross section. Again as Gareth mentions, an
> exact calculation would involve measuring the exact flow across triangle
> edges, which hasn't been implemented. Good idea though, should be added in
> the issues on github.
>
> The current cross section calculation is an approximation, maybe only
> first order accurate. So the error could easily be proportional to the
> triangle edge length. To test this you could run your simulation for a
> sequence of meshes with progressively smaller mesh resolution and see if
> the flow converges to your 350 m^3/s value as the mesh gets refined. By the
> way, you would only need to refine the region around the cross section.
>
> On the other hand you can be confident that the volume balance is
> accurate, which can be check using the command
>
> domain.print_volumetric_balance_statistics()
>
> Cheers
> Steve
>
> ==============================
> Emeritus Prof Stephen Roberts
> Mathematical Sciences Institute
> Hanna Neumann Building #145
> The Australian National University
> Canberra, ACT 2600 AUSTRALIA
> T: +61 2 61254445 | E: ste...@an...
>
> CRICOS Provider: 00120C
>
> ------------------------------
> *From:* Gareth Davies <gar...@gm...>
> *Sent:* Wednesday, 20 July 2022 10:59 AM
> *To:* anu...@li... <anu...@li...>;
> nt...@ut... <nt...@ut...>
> *Subject:* Re: [Anuga-user] ANUGA model time step and flow through cross
> section
>
> Hi Nelson,
>
> A couple of thoughts below, but no clean solutions.
>
> # Regarding the model time step
>
> Theoretically it depends on the sum of the speed and sqrt(gh), not just
> the maxima of the two. It also depends on the CFL number, which varies
> depending on the timestepping method.
>
> The details of the calculation also depend on speeds at edges that are
> not so easy to reconstruct from the python side. I think some of the
> important details are in the C routine _compute_fluxes_central.
>
> # Regarding the discharge through a cross-section:
>
> To 'properly' track fluxes through the cross-section one would have to
> sum the time-integrate the edge mass fluxes.
>
> Something like this is done in the boundary_flux_integral operator:
>
> https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FGeoscienceAustralia%2Fanuga_core%2Fblob%2Fmain%2Fanuga%2Foperators%2Fboundary_flux_integral_operator.py&amp;data=05%7C01%7Cstephen.roberts%40anu.edu.au%7C0ce89d4bb487456a942108da69ef7183%7Ce37d725cab5c46249ae5f0533e486437%7C0%7C0%7C637938774375651977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=%2F1z2LQaLK3kyeuUwwZoylDQulBOZ2clsk27Z%2FQXJumY%3D&amp;reserved=0,
>
> although that only treats the boundaries.
>
> Such a  time-integrated edge-flux sum is not done in the routine
> get_flow_through_cross_section. The latter is based on the instantaneous
> uh/vh values, which will not correspond to the edge fluxes over time
> (not even for steady flow, because of how the flux calculations work).
>
> AFAIK there is currently no ANUGA routine to do the mass conservative
> version of the calculation over a specified cross-section.
>
> But it's a long time since I used ANUGA, possibly something has been
> implemented since.
>
> Cheers,
> Gareth
>
>
> _______________________________________________
> Anuga-user mailing list
> Anu...@li...
>
> https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fanuga-user&amp;data=05%7C01%7Cstephen.roberts%40anu.edu.au%7C0ce89d4bb487456a942108da69ef7183%7Ce37d725cab5c46249ae5f0533e486437%7C0%7C0%7C637938774375651977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=4FixkiRxbYIcrSuX%2FXaMcjIlSXsVDm0nK6zkQBSG28Y%3D&amp;reserved=0
>

Re: [Anuga-user] ANUGA model time step and flow through cross section

[Stephen R. <ste...@an...>]

Hi Nelson,

I think Gareth has essentially provided a good answer to your first question.

The condition is  min_over_edges {Radius_T_E/  ( u_E + sqrt(g H_E) }

where the Radius_T is the "radius" of a triangle. Now there are quite a few ways to calculate the area. I recall it is the min of the distance from centroid to edge midpoint.

The u_E + sqrt(g H_E) are calculated quantities at the midpoint of the edge. This would be hard to reproduce exactly just from the data from the sww file.

So your difference might be a combination of working with different radii and working with U+sqrt(gH) instead of max(U, sqrt(gH)).

Also, there might be a factor of 2 between using diameter or radii.

By the way you can probably get away with using

domain.set_CFL(2.0)

and still maintain stability and accuracy. And the advantage would be the simulation will be twice as fast.

As regards the flow through a cross section. Again as Gareth mentions, an exact calculation would involve measuring the exact flow across triangle edges, which hasn't been implemented. Good idea though, should be added in the issues on github.

The current cross section calculation is an approximation, maybe only first order accurate. So the error could easily be proportional to the triangle edge length. To test this you could run your simulation for a sequence of meshes with progressively smaller mesh resolution and see if the flow converges to your 350 m^3/s value as the mesh gets refined. By the way, you would only need to refine the region around the cross section.

On the other hand you can be confident that the volume balance is accurate, which can be check using the command

domain.print_volumetric_balance_statistics()

Cheers
Steve


==============================
Emeritus Prof Stephen Roberts
Mathematical Sciences Institute
Hanna Neumann Building #145
The Australian National University
Canberra, ACT 2600 AUSTRALIA
T: +61 2 61254445 | E: ste...@an...

CRICOS Provider: 00120C

________________________________
From: Gareth Davies <gar...@gm...>
Sent: Wednesday, 20 July 2022 10:59 AM
To: anu...@li... <anu...@li...>; nt...@ut... <nt...@ut...>
Subject: Re: [Anuga-user] ANUGA model time step and flow through cross section

Hi Nelson,

A couple of thoughts below, but no clean solutions.

# Regarding the model time step

Theoretically it depends on the sum of the speed and sqrt(gh), not just
the maxima of the two. It also depends on the CFL number, which varies
depending on the timestepping method.

The details of the calculation also depend on speeds at edges that are
not so easy to reconstruct from the python side. I think some of the
important details are in the C routine _compute_fluxes_central.

# Regarding the discharge through a cross-section:

To 'properly' track fluxes through the cross-section one would have to
sum the time-integrate the edge mass fluxes.

Something like this is done in the boundary_flux_integral operator:
https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FGeoscienceAustralia%2Fanuga_core%2Fblob%2Fmain%2Fanuga%2Foperators%2Fboundary_flux_integral_operator.py&amp;data=05%7C01%7Cstephen.roberts%40anu.edu.au%7C0ce89d4bb487456a942108da69ef7183%7Ce37d725cab5c46249ae5f0533e486437%7C0%7C0%7C637938774375651977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=%2F1z2LQaLK3kyeuUwwZoylDQulBOZ2clsk27Z%2FQXJumY%3D&amp;reserved=0,
although that only treats the boundaries.

Such a  time-integrated edge-flux sum is not done in the routine
get_flow_through_cross_section. The latter is based on the instantaneous
uh/vh values, which will not correspond to the edge fluxes over time
(not even for steady flow, because of how the flux calculations work).

AFAIK there is currently no ANUGA routine to do the mass conservative
version of the calculation over a specified cross-section.

But it's a long time since I used ANUGA, possibly something has been
implemented since.

Cheers,
Gareth


_______________________________________________
Anuga-user mailing list
Anu...@li...
https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fanuga-user&amp;data=05%7C01%7Cstephen.roberts%40anu.edu.au%7C0ce89d4bb487456a942108da69ef7183%7Ce37d725cab5c46249ae5f0533e486437%7C0%7C0%7C637938774375651977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=4FixkiRxbYIcrSuX%2FXaMcjIlSXsVDm0nK6zkQBSG28Y%3D&amp;reserved=0

Re: [Anuga-user] ANUGA model time step and flow through cross section

[Gareth D. <gar...@gm...>]

Hi Nelson,

A couple of thoughts below, but no clean solutions.

# Regarding the model time step

Theoretically it depends on the sum of the speed and sqrt(gh), not just 
the maxima of the two. It also depends on the CFL number, which varies 
depending on the timestepping method.

The details of the calculation also depend on speeds at edges that are 
not so easy to reconstruct from the python side. I think some of the 
important details are in the C routine _compute_fluxes_central.

# Regarding the discharge through a cross-section:

To 'properly' track fluxes through the cross-section one would have to 
sum the time-integrate the edge mass fluxes.

Something like this is done in the boundary_flux_integral operator: 
https://github.com/GeoscienceAustralia/anuga_core/blob/main/anuga/operators/boundary_flux_integral_operator.py, 
although that only treats the boundaries.

Such a  time-integrated edge-flux sum is not done in the routine 
get_flow_through_cross_section. The latter is based on the instantaneous 
uh/vh values, which will not correspond to the edge fluxes over time 
(not even for steady flow, because of how the flux calculations work).

AFAIK there is currently no ANUGA routine to do the mass conservative 
version of the calculation over a specified cross-section.

But it's a long time since I used ANUGA, possibly something has been 
implemented since.

Cheers,
Gareth

[Anuga-user] ANUGA model time step and flow through cross section

[Nelson T. <nt...@ut...>]

Hello,

I have two ANUGA questions that I have been grappling with for some time,
and it would be great to get some help. Thank you in advance!

*Question about the model time step:*
I have done some calculations on my mesh and simulation outputs. In my
domain, sqrt(gh) is always faster than the fluid speed, and would thus be
the limiting factor for the time step. For CFL number of 1, the smallest
time step in my domain based on element size (radius of circumscribed
circle) would be 0.17 seconds. In reality, my model time step is at 0.037
seconds.

Is there something I am calculating wrong or anything that would cause such
a small time step? My code for calculating a theoretical time step is below:

# get anuga output
sww_p = anuga.plot_utils.get_output(swwFile)
areas = anuga.plot_utils.triangle_areas(sww_p)

# get mesh coordinates
x0 = sww_p.x[sww_p.vols[:,0]]
x1 = sww_p.x[sww_p.vols[:,1]]
x2 = sww_p.x[sww_p.vols[:,2]]
y0 = sww_p.y[sww_p.vols[:,0]]
y1 = sww_p.y[sww_p.vols[:,1]]
y2 = sww_p.y[sww_p.vols[:,2]]

# compute edge lengths
d0 = ((x1-x0)**2 + (y1-y0)**2) **0.5
d1 = ((x2-x1)**2 + (y2-y1)**2) **0.5
d2 = ((x0-x2)**2 + (y0-y2)**2)**0.5

# compute length scale (radius of circumscribed circle)
r_tri = d0*d1*d2/(4*areas)

# Calculate theoretical time step for each triangle corresponding to CFL=1
ts_wave = r_tri/(9.81*mesh_h[-1])**0.5  # mesh_h[-1] is array of depths at
final step

*Question about the get_flow_through_cross_section function:*
I have been using this function to calculate discharge in a river at
various locations, drawing simple transects from dry bank to dry bank  (two
points). When I draw a transect, say 100-200 meters downstream of my
Inlet_operator line, I would expect the discharge to be similar to the
amount I am applying at the inlet. However, the
get_flow_through_cross_section function typically yields higher discharge
values than what I am applying to my domain (e.g., Q_in = 350 and
Q_transect = 355-370), and there is no water coming in from elsewhere.

I believe the function is working as intended, and the issue is with the
complicated interpolation across triangular elements of various
sizes/orientations. But I am surprised that it is consistently higher. I
even drew 10 transects in the same general area, each spaced about 5 m
apart (my elements in the river here are ~12 m in length), and all yielded
higher discharges.

Am I using the function correctly, and/or is there anything you might
recommend to improve my discharge estimates? It does not need to be exact,
but it would be nice to get discharges that don't skew low or high.

Thank you so much!
-- Nelson

Nelson Tull
The University of Texas at Austin
nt...@ut...

Re: [Anuga-user] ANUGA on GPU

[Stephen R. <ste...@an...>]

Hi Risabh,

That's great that you are looking into a GPU version of anuga.

There have been a couple attempts to produce a GPU version of anuga.

Probably the code you found was https://github.com/abdulbudiaji/anuga-cuda (or https://github.com/stoiver/anuga-cuda).

The code was actually derived from a google code repository associated with a student (Zhe Weng) project supervised by Peter Strazdins (ANU Computer Science) and me back in 2013/2014.

I will send a copy of the thesis in a separate message ( to avoid sending the largest file to everyone on the mailing list).

Te hmain problem with maintaining the version was that Zhe of course moved on and keeping the GPU version up to date with the main version turned out to be difficult. In addition a number of peripheral components (the boundary condition and the operators like culverts) did not have GPU versions.

It would be great to have a version which would allow us to evolve to a GPU capable method. We use cython more now than back in 2013, so there might be  good hope to use cython to help manage the GPU version.

Cheers
Steve




==============================
Emeritus Prof Stephen Roberts
Mathematical Sciences Institute
Hanna Neumann Building #145
The Australian National University
Canberra, ACT 2600 AUSTRALIA
T: +61 2 61254445 | E: ste...@an...

CRICOS Provider: 00120C

________________________________
From: Rishabh <ris...@gm...>
Sent: Wednesday, 13 July 2022 10:42 PM
To: anu...@li... <anu...@li...>
Cc: mm...@nv... <mm...@nv...>; tan...@ya... <tan...@ya...>; tan...@nv... <tan...@nv...>
Subject: [Anuga-user] ANUGA on GPU


Hello,

I'm Rishabh, currently interning at NVIDIA and working on parallelizing ANUGA to work on the GPU. We surfed online for already existing code and found an old repository. Though it works well, we were interested in finding later versions of this. Unfortunately, the web displays only one such repository. We would like to know if you have a newer version of GPU-enabled ANUGA. It would be great if you could also include details of the repository.

Thank you,

Rishabh

[Anuga-user] ANUGA on GPU

[Rishabh <ris...@gm...>]

Hello,

I'm Rishabh, currently interning at NVIDIA and working on parallelizing
ANUGA to work on the GPU. We surfed online for already existing code and
found an old repository. Though it works well, we were interested in
finding later versions of this. Unfortunately, the web displays only one
such repository. We would like to know if you have a newer version of
GPU-enabled ANUGA. It would be great if you could also include details of
the repository.

Thank you,

Rishabh

[Anuga-user] ANUGA on GPU

[Rishabh R. <200...@ii...>]

Hello,

I'm Rishabh, currently interning at NVIDIA and working on parallelizing 
ANUGA to work on the GPU. We surfed online for already existing code and 
found an old repository. Though it works well, we were interested in 
finding later versions of this. Unfortunately, the web displays only one 
such repository. We would like to know if you have a newer version of 
GPU-enabled ANUGA. It would be great if you could also include details 
of the repository.

Thank you,

Rishabh

[Anuga-user] Outflow and maximum depth

[Michela V. <mic...@df...>]

Dear all,

I am new to Anuga and would appreciate some help. Iam currently following the Anuga clinic. I am looking at the Mereweather flood case study i.e. notebook2 https://colab.research.google.com/github/anuga-community/anuga-clinic/blob/master/notebooks/notebook2.ipynb <https://colab.research.google.com/github/anuga-community/anuga-clinic/blob/master/notebooks/notebook2.ipynb>. I wanted to add a simple computation of the maximum flood height per centroid of the grid, e.g. by adding to the evolution of the domain

for t in domain.evolve(yieldstep=5, duration=520):
  
    #dplotter.plot_depth_frame()
    dplotter.save_depth_frame(vmin=0.0, vmax=1.0)

    stage = domain.quantities['stage'].centroid_values
    print(np.mean(stage))
    stage_max= np.maximum(stage_max,stage)

    domain.print_timestepping_statistics()

This is supposed to yield the maximum depth (or stage) per grid centroid over the course of the flood event. However, I noticed that the water does not actually flow out even if the boundary conditions are set to 

Bt = anuga.Transmissive_boundary(domain)

The water seems to be stuck in places. This could be seen by comparing the max floodlevel at a point to the maxium water 
level at the same point. There is no difference between the last frame and the frame containing the maximum.

domain.stage=stage_max
maxplot=anuga.Domain_plotter(domain)
maxplot.plot_depth_frame(vmax=1.0).

Am I missing something? How can the example be modified to have an actual outflow?

Best wishes,
Michaela