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

User Boundary Condition Should Accept dt as an Argument #507

Open
mandli opened this issue Feb 11, 2015 · 5 comments
Open

User Boundary Condition Should Accept dt as an Argument #507

mandli opened this issue Feb 11, 2015 · 5 comments

Comments

@mandli
Copy link
Member

mandli commented Feb 11, 2015

The Fortran versions of Clawpack accept dt as an argument to the boundary conditions which is useful for certain types of boundary conditions (paddle BCs in my case). We can simply add this to the calling signature but this will again break backwards compatibility.

@ketch
Copy link
Member

ketch commented Feb 11, 2015

Can you explain (for me) why a boundary condition could depend on dt? On the surface, that seems like just the kind of thing the abstraction should prohibit. I'd like to understand.

@mandli
Copy link
Member Author

mandli commented Feb 11, 2015

In the case I ran into an approximation of a time derivative is needed to calculate an incoming wave form while allowing an outgoing wave at the same time (not exactly a paddle but still in a idealized wave-tank). Randy wrote up a short IPython notebook at http://nbviewer.ipython.org/url/faculty.washington.edu/rjl/notebooks/Wavetank_BC.ipynb which describes what we were trying to do.

@ketch
Copy link
Member

ketch commented Feb 12, 2015

Thanks. I guess this would only ever be needed in the Classic solvers, and never in a method-of-lines-solver, right?

But it's probably best to keep the same BC API across all solvers.

@rjleveque
Copy link
Member

Thinking about this some more and looking at what I've done in other problems where an incoming wave is specified, I'm not sure what I suggested in that notebook is correct -- the ghost cell value should perhaps be based on spatial derivatives not temporal derivatives. I will think about this further.

Also, I just noticed that dt is an input argument in the classic code bc2.f, but is not an argument for the bc2amr.f subroutine in amrclaw. So apparently we've never needed it in past applications of the AMR code.

Before adding it to PyClaw, let's think further about whether we should instead delete it from classic.

@mandli
Copy link
Member Author

mandli commented Feb 12, 2015

I was under the impression that there might be BCs that may be dependent on time derivatives, for instance maybe a system that contains reactions would require the approximation of a time derivative. On the other hand I cannot say that I have ever needed this before the above application.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants