Support writing gauge binary output

[rjleveque]

Note: This is based on the branch in #536, so there are some replicated commits until that's merged in.

This adds the previously NotImplemented option of binary output for gauges, indicated in setrun.py by setting

      rundata.gaugedata.file_format = 'binary'

to take effect for all gauges, or selectively by setting this to a dictionary, see http://www.clawpack.org/gauges.html

For binary gauges, an output file of the form gauge00000N.txt is still created with the header, containing the gauge location, description of the columns, and indication for Lagrangian gauges. But the gauge data itself is written to the corresponding file gauge00000N.bin (analogous to fort.q and fort.b files for the time frames).

I will do a PR on pyclaw for a modified gauges.py that can read in the binary files.

I modified the unit test in tests/dtopo1 to write one ascii gauge and one binary gauge (at the same location).

I tested that restarts still work, it will append new data to the binary file created in the initial run. (Although if you try to change the gauge's file_format from one run to the next, confusion will result. Maybe we should add a test for that.)

This capability should eventually be added to amrclaw in 1d, 2d, 3d as well.

[rjleveque]

Update: I modified the regression test so that the gauge 2 files are not saved, and the gauge 2 binary data is compared against the gauge 1 ascii data saved in regression_data. As I noted in the conversation at clawpack/pyclaw#682, this is a better way to do it since binary file formats may vary, so the archived .bin file might not be portable.

This required a modified check_gauge function in tests/dtopo1/regression_tests.py taking two gauge id's as input. We might want to move this to clawutil eventually.

[mandli]

Looks good and works for me. This looks like it does not include the serialization of gauge writing (#536), correct?

[rjleveque]

@mandli: it does contain those commits in this PR (until we merge #536, if we do).

[rjleveque]

If we decide not to merge #536 then this PR needs some work.

[rjleveque]

I reverted the code from #536, we are still considering on the best way to write out the gauges when using OpenMP.

I also added capability to choose either 8-byte or 4-byte format for the binary output (i.e. float64 or float32 when reading into Python). This can be specified in setrun.py via:

    rundata.gaugedata.file_format[gaugeno] = 'binary32'

while either binary or binary64 implies standard 8-byte output. Using binary32 reduces the file size by a factor of two, useful especially for PTHA or machine learning applications where thousands of runs are done with many gauges.

There's a new line in the gauge header file to indicate the format, needed in order to load it properly.

In the binary output case a file like gauge00202.txt contains only a header, e.g.:

# gauge_id=   202 location=( -0.8600000000E+02 -0.3800000000E+02 ) num_var=  2
# Stationary gauge
# level, time, q[  1], eta, aux[]
# file format binary32, time series in .bin file

and the data is in gauge00202.bin.

In the ascii case it contains the header followed by the data, as before:

# gauge_id=   102 location=( -0.8600000000E+02 -0.3800000000E+02 ) num_var=  2
# Stationary gauge
# level, time, q[  1], eta, aux[]
# file format ascii, time series follow in this file
   02  0.1818584E+03  0.3898904E+04  0.0000000E+00
   02  0.3625168E+03  0.3898904E+04  0.0000000E+00
   etc.

This is ready for others to test.