Closed rjleveque closed 3 months ago
I tried modifying the euler_1d_wcblast
example to include a gauge with id = 2147483647
and id=2147483
. Unfortunately the code ran fine but the gauge file names were still truncated to 5 digits, gauge47483.txt
and gauge83647.txt
respectively. Then I realized that I was testing on a 1D example. Go figure.
The 2D and 3D works for me. Do you want to add the 1D and we can merge this?
@mandli, For some reason I thought we didn't have gauges implemented in 1d amrclaw, but I guess it does. I can go ahead and add this.
By the way, when testing 3d gauges I found that examples/euler_3d_radial
died immediately, but I haven't looked into that further. Could you try running that one?
I notice that src/1d/gauges_module.f90
looks very different from 2d and 3d, and also that the 2d version was improved over what's done in 3d. Some day maybe make these more coherent, perhaps...
I keep getting that *** a**2 <= 0 in x-sweep at 0
messages from the Riemann solver, which stops the run. Was this example changed in a previous commit?
@mandli: Yes, that's what I get too, also on the master branch and with v5.10.0. I haven't tried reverting to earlier versions, but I don't think that example or the Riemann solver has changed in years.
@rjleveque Looking at the history this was clearly my fault. There is a missing rho
for the energy in qinit.f90.
q(5, i, j, k) = rho
I am not sure what the correct solution is here though and the gauges are all unremarkable so I am not sure what we are supposed to see.
I'm going to merge this and then will do a separate PR for the euler_3d_radial
example.
Same changes as in https://github.com/clawpack/geoclaw/pull/615, and now allows gauge number up to 9 digits (actually up to
2**31 - 1 = 2147483647
since it is stored as an 4-byte integer).