Shallow water solvers with bathymetry #126
Conversation
* master: (62 commits) Use simple average of wavespeeds for 2nd-order term in traffic solvers. Avoid artificially small CFL numbers in traffic_vc solver. Make q-wave traffic solvers the default. Replace variable-speed traffic solver with more accurate q-wave version. Correctly compute fluctuations for transonic shocks in vc traffic solver. Use underscore instead of space in 'stress_relation' key. Cosmetic changes to nonlinear_elasticity Python solver. Switch back to using f-waves in variable-speed traffic solvers. Add quadratic stress-strain relation as option in Python nonlinear elasticity solver. Update LWR traffic solvers. Revert "Improvements to and new solvers for LWR traffic model." Improvements to and new solvers for LWR traffic model. Don't import different solvers under the same name. Don't import different solvers under the same name. Run python-modernize on all files. cleaned up indentation of comments only in rpn2_shallow_roe_with_efix.f90 the common block containing grav is needed in rpn2_shallow_roe_with_efix.f90 Make sonic check more efficient modify fw(3,:) in riemann_aug_JCP geoclaw solver to put transverse velocity jump into fw(3,1) or fw(3,3) depending on interface velocity rather than into fw(3,2), as suggested by Wenwen Li. change sonic test to use different criticaltol as proposed by Wenwen Li ...
This requires a Riemann solver in clawpack/riemann#126. docathon
|
The augmented solver here is used in https://github.com/clawpack/apps/blob/master/notebooks/pyclaw/beach.ipynb. The 1D f-wave solver is tested in clawpack/pyclaw#564. |
|
Is the Python version and Fortran version consistent? I vaguely recall that there may be a discrepancy that should be fixed. |
* master: Turn on entropy fix. Cleanup of Roe shallow water solver. Add new Roe shallow water solver with tracer.
|
Also thanks for resurrecting this. My dream of refactoring the solver was too ambitious clearly. |
|
The Python and Fortran 1D f-wave solvers do give slightly different answers, so they must be doing something different. Let me take a look. |
|
I ran a quick test and they are pretty close: https://gist.github.com/ketch/8adf1ba9eb6e11ca8dfa996e7e1193a5 They are a bit different but both seem "correct" to me. |
|
I can take a look, I may remember what I thought might have been wrong. |
|
so the big difference between the two is that Python uses HLL like speeds and the Fortran uses the Roe speeds. We should probably both change to using the Einfeldt speeds. I can make the changes to both if you want. |
|
That would be great. After you make the changes just issue a PR against my shallow_fwave branch. |
Also corrected some bugs that were found and added more problem parameters to the Python version.
Reconcile differences between python and fortran RP for swe
… shallow_fwave * 'shallow_fwave' of https://github.com/ketch/riemann: Add sea_level to common block Reconcile differences between python and fortran RP for swe
|
I reran the comparison and now things match up to roundoff (check the gist linked above; updated). I guess we should make the same changes to the 2D fwave solver... |
|
Ah sorry, should have checked that. I can do that as well. |
|
So I have something done but I was not sure if there was a test for the 2d solver. From your previous comments it does not appear so but I wanted to make sure. I am not confident right now that what I have is going to work as it required some significant reworking of what @ketch wrote. |
|
You're right about the lack of a test. I'll write one and try both versions. |
Add Einfeldt speeds to 2D fwave solver
|
I think we should go ahead and merge this so that clawpack/pyclaw#564 will pass tests. Neither one will pass without the other but I think we can be confident now that together they will pass (and every solver has a test or an app now). |
|
Oh, but it's probably worth deleting the commented-out code first? Sorry, I should have thought about that before I merged the secondary PR. |
… shallow_fwave * 'shallow_fwave' of https://github.com/ketch/riemann: remove sea_level comparison Initial attempt at incorporation of Einfeldt speeds
|
Okay, I've been checking more carefully and I was wrong. Commit d765c00 broke the 2D Riemann solver (it quickly generates NaNs for the test case). It's not obvious to me what is wrong with those changes. The older version gives results that look reasonable. |
|
At the very least the determination of beta is not consistent. I am hoping to get back to this soon so I can try and take a look again. |
|
I think the 1 and 0 arguments to merge are backwards, too. But I switched them and still got NaNs. |
Currently requires clawpack/riemann#126. docathon
|
I fixed some things and switched methods for dealing with the normal and transverse components. There were some issues with the test case that I have corrected but things are still not working with bathymetry. I will continue to look into it. |
Riemann solver corrections for 2D SWE equations
|
I believe this is ready to merge now. |
This PR adds 3 solvers:
This is a replacement for #86, which has been waiting for over 2 years. I know the long-term dream is to do a major overhaul of the Geoclaw solvers, but I don't want to wait on that before merging this.