Gauge filenames

[rjleveque]

Same changes as in clawpack/geoclaw#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).

[mandli]

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?

[rjleveque]

@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?

[rjleveque]

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...

[mandli]

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?

[rjleveque]

@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.

[mandli]

@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.

[rjleveque]

I'm going to merge this and then will do a separate PR for the euler_3d_radial example.