Gauge interp

[rjleveque]

Utility module for reading gauge data and interpolating to arbitrary times.

[mandli]

Looks good to me although I am wondering if this would be better to have in AMRClaw or GeoClaw and separate out the plotting?

[rjleveque]

Or maybe in clawutil, since eventually we should add gauges to the classic code as well?

[mandli]

Yeah, that would be better perhaps. PyClaw also has some idea of gauges as well but I am not certain that these routines would be as useful.

[ketch]

Thinking long-term, it seems like plotdata.getgauge should live in some (reorganized) IO module.

I've been using Pandas more and more lately, and it might be nice to read gauges into a Pandas.Series (time series) object. Those have a built-in interpolate function, as well as many other niceties. Of course, depending on Pandas would be a major decision but it's becoming as widely used as numpy or matplotlib.

(No need to figure this out before merging the present PR, of course)

[mandli]

So leave this here with the intention of moving all the gauge IO somewhere else when we can separate out this type of functionality more broadly?

[ketch]

That sounds good to me.

[rjleveque]

Seems reasonable to me, and it would be nice to re-think all the I/O at some point.

I haven't used Pandas, but glancing at the tutorial, it looks very useful,
http://pandas.pydata.org/pandas-docs/dev/10min.html

[mjberger]

can I add a word of caution: most difficulty of people downloading clawpack is versionitis in python, or other rapidly changing packages. How stable is this - does it really add enough to complicate the system further?

On Mar 10, 2015, at 11:05 AM, Randall J. LeVeque notifications@github.com wrote:

Seems reasonable to me, and it would be nice to re-think all the I/O at some point.

I haven't used Pandas, but glancing at the tutorial, it looks very useful,
http://pandas.pydata.org/pandas-docs/dev/10min.html

—
Reply to this email directly or view it on GitHub.

[ketch]

@mjberger I strongly agree with your concerns. Pandas is still evolving and is version 0.x. But it is about as stable as scipy and I believe has a more robust installation procedure. Anyone with a scientific Python stack almost certainly has it already.

I also wonder whether introducing additional new data structures is a good idea -- it means one more thing people have to learn before using the code. But if we could replace our own custom data structures with others that are developed and maintained by a much larger community, as long as they still serve our purposes well then that might be really useful. Anyway, something to discuss next week.