GeoClaw: Simulation with Two Grids with Different Resolutions

109 views
Skip to first unread message

Wilfredo Robinson

unread,
Nov 10, 2021, 10:13:30 AM11/10/21
to claw-users
Hi everyone, 

My name is Wilfredo Robinson, and I am a Research Engineer at EURECOM, France. I am currently working with GeoClaw for Tsunami simulations and analysis of potential inundations in the French Riviera and other European coastal areas.

I am using GeoClaw v 5.8.x in Ubuntu 20.04. I have successfully worked with grids downloaded from GEBCO, EMODNet, and NOAA. However, I currently have an issue when using grids from these different sources in the same simulation. I'll give a detailed example to describe my problem: 

I want to simulate an inundation in Monaco. GEBCO has a 15 arc-second resolution, so I want to use it for deep water areas and any other parts of the French Riviera that are NOT Monaco. However, once the tsunami is close to Monaco's shore, I want to use the EMODNet grids, which can offer up to 3.75 arc-second resolution for the Monaco area. Both grid files overlap in Monaco, just with different resolutions. All grid files are topo_type = 3. 

When I'm using only ONE of the two grid files, I can easily set up "regions" where only very high AMR levels are allowed for Monaco, but very low levels for the rest of the computational domain. I thought the same would apply if I used two grid files (.asc) in the same simulation. Unfortunately, I have not gotten it to work properly. If I add both GEBCO (large area, low-res) and EMODNet (Monaco only, high-ish res) files to the same simulation, I can only get ONE of them to be plotted, but not both. Usually, the lowest resolution GEBCO grid is the one used for the simulation, and makes inundation modelling in Monaco not viable. 

For this process, I appended both grid files by using topo_data.topofiles.append([3, topo_path_X]) in setrun.py, where different values of X point to different grid (.asc) files. My dtopo was made by telling maketopo.py the path to the large-area GEBCO file, as I don't want to make the dtopo too close to shore. 

However, when running the simulation with both grid files, GeoClaw plots Monaco in a very low resolution, as if it was using the GEBCO grid file only. But when I remove the GEBCO file and only use the EMODnet file, it's in my desired high resolution.

I know both grids work fine individually. I can successfully simulate in both individually. The only issue comes when using both in the same simulation. I tried using "regions" to fix the low-res AMR levels to the GEBCO tiles, and very high AMR levels to the EMODnet (Monaco-only) tiles. These regions work fine and show my desired resolution when working with ONE grid file in setrun.py, but not when using more than one grid file. 

I've checked the computational domain limits in setrun.py, the topo types, the x and y limits in setplot.py, the proper coordinates for my regions, and the proper factors for the different AMR levels. What could I be missing that makes GeoClaw only use ONE of the grids, but not both? Am I missing anything when using two grid files in the same simulation? Is it possible that, because the resolutions between files are so different, GeoClaw does an "average" of both topo values in the overlapping regions and uses that instead of the most detailed grid?

Thanks in advance for your time. I'll gladly share any files from my side if need be. 

I await your reply. Best regards, 

Wilfredo J. Robinson M. 

Kyle Mandli

unread,
Nov 30, 2021, 11:53:10 AM11/30/21
to claw-users
Hi Wilfredo,

I am not sure if you answered this question yet but GeoClaw should use the best data it has available, so GEBCO where ever the EMODnet file does not cover.  The more likely cause of this are level limits that are not allowing the simulation to get to your desired resolution.  If you are still having issues with this if you want to post the setrun.py you are using we can take a look.

Kyle

Wilfredo Robinson

unread,
Dec 2, 2021, 4:40:33 AM12/2/21
to claw-users
Hi Kyle, 

Thanks for the reply. I did manage to solve the issue after additional tests I conducted after I posted the question. It was a problem with a very simple solution, which I did not get to quickly because of a misunderstanding I had considering the AMR ratios. I'll post my problem and solution here in case anyone else finds themselves stuck in something similar: 

Firstly, AMR factors should be calculated based on the area specified by your computational domain in setrun.py. If the computational domain size changes, but you still want some smaller regions to maintain a fixed resolution, your AMR factors should adapt accordingly.  In my case, I had a small (geographically speaking) grid file for the high-resolution region, and a big low-resolution grid file for the rest of the geographical zone I wanted to model. When working with only the small high-res file, I had set my computational domain size to that grid file's limits, and calculated my AMR ratios based only on that geographically small grid file. So, at this point I have a small computational domain, with a set of AMR ratios I'll call X

However, when I added the bigger low-resolution area and increased the computational domain size, I forgot to also adapt my AMR ratios to reflect this change. As such, now I had a much bigger computational domain, with the same X AMR ratios. Of course my high-res grid was going to look low-res: I was not using AMR factors that would allow it to look high-res. After noticing this, I just adapted my AMR ratios accordingly and the problem was solved. 

IN SUMMARY: 
AMR ratios should be set according to your computational domain size. If this computational domain increases in size, and you want some specific smaller regions to remain high-res, don't forget to adapt your AMR ratios accordingly. 

It sounds very trivial writing it here like this, but if it can help anyone else stuck in a similar trivial problem, then it's worth it. 

Thanks again Kyle for replying. I wish all claw-pack users a great day.

Cheers, 

Wilfredo

Kyle Mandli

unread,
Dec 7, 2021, 12:45:29 PM12/7/21
to claw-users
Thanks Wilfredo!

Kyle
--
You received this message because you are subscribed to a topic in the Google Groups "claw-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/claw-users/3dRqtKYZtv0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to claw-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/claw-users/18eb2508-2786-42ac-b5ed-91c040c44200n%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages