Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gauge interp #148

Merged
merged 2 commits into from
May 3, 2015
Merged

Gauge interp #148

merged 2 commits into from
May 3, 2015

Conversation

rjleveque
Copy link
Member

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

@mandli
Copy link
Member

mandli commented Mar 8, 2015

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
Copy link
Member Author

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

@mandli
Copy link
Member

mandli commented Mar 9, 2015

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
Copy link
Member

ketch commented Mar 10, 2015

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
Copy link
Member

mandli commented Mar 10, 2015

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
Copy link
Member

ketch commented Mar 10, 2015

That sounds good to me.

@rjleveque
Copy link
Member Author

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
Copy link

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
Copy link
Member

ketch commented Mar 10, 2015

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

rjleveque added a commit that referenced this pull request May 3, 2015
@rjleveque rjleveque merged commit 8ecbaeb into clawpack:master May 3, 2015
@rjleveque rjleveque deleted the gauge_interp branch May 3, 2015 16:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants