clawpack / riemann Goto Github PK

Most of the Euler Riemann solvers still have common blocks, which are not thread safe with OpenMP.

This showed up when testing amrclaw/tests/quadrants.

Some other Riemann solvers also have common blocks. Need to clean all of these up.

I think this file is completely outdated and should be deleted:

https://github.com/clawpack/riemann/blob/master/src/TODO.txt

But correct me if I'm wrong.

Description

I am planning to use clawpack/pyclaw library to solve a transport equation with a source term where a vector quantity will be transported.

$\vec q_t +\vec u(\vec x,t).\nabla \vec q = \psi(\vec q) $

I have a analytical solver for solving

$\vec q_t= \psi(\vec q)$

time array is pre-determined.

primarily, I need to set-up the solver for transport equation of a vector quantity. Is there any readily available solver for that? or would any one please help me to set-up this step by step?

I need it urgently.

Thank you in advance.

Regards,

Arijit Hazra

Grady Lemoine got the following error:

I tried the pip install instructions using a clawpack clone from github, and I guess it's functional, though it's misbehaving a bit. I can import pyclaw, but when I try to import petclaw (the point of this exercise), I get the message

Warning: Some Riemannn solvers were not able to be imported.
Did you run make in RIEMANN/src/python/riemann.
Traceback (most recent call last):
File "/home/grady/claw-git2/clawpack/clawpack/riemann/init.py", line 29, in
import rp1_layered_shallow_water
ImportError: /home/grady/claw-git2/clawpack/clawpack/riemann/rp1_layered_shallow_water.so: undefined symbol: dgeev_

I don't understand why this message is appearing -- I have LAPACK installed, and I even went to the trouble of installing the LAPACK PIC library in case it's supposed to get linked into a dynamic library, then re-running the install process. Getting this message is going to be a real nuisance; is there anything I can do about it?

Hello clawpackers.
I have a question concerning the Roe solver for ideal gas law.
The fortran file i'm talking about is
https://github.com/clawpack/riemann/blob/master/src/rpn3_euler.f90
In lines 171 to 176 the wave amplitudes alpha(...) are calculated from the deltas (differences of the conservative left and right state vectors) and some Roe-averaged variables.
I made the effort to compare the alphas in the code to the alphas in the book of Toro (Riemann Solvers and Numerical Methods for Fluid Dynamics, 3rd ed, page 357, formulae (11.68/69).
The alphas in the clawpack code seem to agree with Toro's alphas, except for alpha(5) in the code (which in Toro's book is named alpha_1, because the eigenvectors are numbered in a different order than in clawpack).
clawpack:
alpha(5) = ( delta(rho u) + (a-u)delta(rho) - a alpha(4) ) / (2 a)

Toro:
alpha_1 = (-delta(rho u) + (a+u)delta(rho) - a alpha_2 ) / (2 a)
where Toro's alpha_2 is identical to clawpack's alpha(4) (i checked that). The rest of the alphas also agree (except for the numbering).
Numbering:
clawpack: alpha(1),alpha(2),alpha(3),alpha(4),alpha(5) correspond to respectively
Toro: alpha_5, alpha_3 ,alpha_4 ,alpha_2 ,alpha_1
Except for the numbering, the eigenvectors seem to be the same in clawpack and Toro's book (i.e. there is no different scaling involved in the two sources). One can see this by comparing the factors after the alphas in the code lines 182-200 to Toro's formula (11.59) on page 356.
I checked Toro's formulae for the alphas (by elimination and so on ...), and i arrived exactly at Toro's results, so they seem right.
So i wonder if there's a bug in the clawpack code? Why does clawpack's alpha(5) not agree with Toros alpha_1 ? Did i get something wrong?
Thanks for your answers and comments.

Doing

pip install --user clawpack

on wakari.io leads to the following error:

/usr/bin/gfortran -Wall -Wall -shared build/temp.linux-x86_64-2.7/build/src.linux-x86_64-2.7/clawpack/riemann/acoustics_1Dmodule.o build/temp.linux-x86_64-2.7/build/src.linux-x86_64-2.7/fortranobject.o build/temp.linux-x86_64-2.7/clawpack/riemann/src/rp1_acoustics.o build/temp.linux-x86_64-2.7/build/src.linux-x86_64-2.7/clawpack/riemann/acoustics_1D-f2pywrappers.o -L/opt/anaconda/envs/np17py27-1.8/lib -L/opt/anaconda/envs/np17py27-1.8/lib -llapack -lf77blas -lcblas -latlas -lpython2.7 -lgfortran -o build/lib.linux-x86_64-2.7/clawpack/riemann/acoustics_1D.so

/usr/bin/ld: cannot find -llapack

collect2: ld returned 1 exit status

Checking numpy.config.blas_opt_info gives

In [3]: numpy.__config__.blas_opt_info
Out[3]: 
{'define_macros': [('ATLAS_INFO', '"\\"3.8.4\\""')],
 'language': 'c',
 'libraries': ['f77blas', 'cblas', 'atlas'],
 'library_dirs': ['/opt/anaconda/envs/np17py27-1.8/lib']}

Some of the solvers have outdated comments stating copyright and listing versions. The latter is dealt with by git, and all code here falls under the license for Clawpack. So it would be nice to remove these comments in order to avoid maintaining them.

Suggested by @mandli in #121.

Dynamic loading really kills performance on distributed file systems, we should avoid doing this unnecessarily.

Per the instructions at

https://github.com/clawpack/riemann

This may not be completely straight forward due to parameter locations and the use of modules but we should look into it.

On line 199 of rpn3_euler.f90, the index variable 'iws' is used as an index of s(m,iws). The variable iws is implicitly declared, but never initialized. This causes the solution to blow up, almost immediately, since iws could be any integer, and is completely unpredictable.

I believe it should read s(mws,i) and iws should never be used. Using 'implicit none' would have allowed the compiler to catch this.

While trying to setup a quad grid examples, I noticed that the common blocks here

https://github.com/clawpack/riemann/blob/master/src/rpn2_euler_mapgrid.f90#L44
https://github.com/clawpack/riemann/blob/master/src/rpt2_euler_mapgrid.f90#L69

and here

https://github.com/clawpack/riemann/blob/master/src/euler_roe_solver_mapgrid.f90#L11

differ. The last one has gamma1 which is not present in the other two. I think these files will be used together.

Is this correct fortran ? The gamma1 need not have to be put in the common block.

Running nose tests on a new AWS EC2 instance revealed this issue in rpn2_layered_shallow_water.f90

lapack is required or at least the subroutine dgesv and any dependencies:

This was initially implemented the way it is in order to save flops. But nowadays it's actually more expensive to load gamma1 from memory than to compute it.

Riemann suggests you re-run make if it cannot import all kernels (related to Issue #10). This (as well as the try/catch) statement needs to be removed.

As discussed on claw-dev.

Probably not entirely surprising but I figured I would at least post this as I think at least we can start to gather intel here. Note that this should be only build errors specific to Riemann, not other packages in Clawpack.

Description

Need to not include the LAPACK linking flags when building Riemann solvers that do not need them and fail gracefully when a solver needs them.

Should the Roe averaging be within the IF statement on line 97 of rptt3_euler.f90?
if( icoor .eq. 2 )then
Wouldn't this mean in the ELSE block (when icoor /= 2), all the Roe averaged variables would be ill-defined? (i.e. pl,pr,u,v,w,u2v2w2,a2 etc.)

Some of the pure python Riemann solvers are not updated to work with the current version of the code. Notably the shallow water 1D solvers were not compatible (one was did not have the array indices permuted). The selection of Riemann solver by the set_riemann_solver function should also be changed.

In issue #24, @ketch noticed that when he incorrectly modified a setup.py file, the "top-level" install still worked.

@mandli suggests that this is due to the top-level setup.py file being "ignored", which is indeed correct.

Looking at the riemann directory, there is both a top-level setup.py file and a src/python/riemann/setup.py file with duplicate functionality. The top-level clawpack installer only uses the src/python/riemann/setup.py file, whereas the individual installer indeed uses the top-level setup.py as well.

I will go through and clean this up here and in the other repositories if needed.

Right now, Riemann's setup.py relies on the Fortran source being symbolically linked in to:

riemann/src/python/src

It seems that if I slightly modify the setup.py file (to look up one directory instead of down into the symbolic link), we can avoid this nasty symbolic link.

Somebody should look into this.

Probably related to #45 and #46. See the Travis log for details.

The compilation of this Riemann solver was disabled due to the issues outlined in #63 and PR #64.

Description

The setup.py is missing the write_version_py() function. Looking at the setup.py in pyclaw I am not sure exactly what the right thing to do here is.

There is currently a little documentation of some Riemann solvers in clawpack/doc/doc/pyclaw/rp.rst. It is woefully inadequate. We should document the organization of the Riemann solver repository and the set of available solvers.

As discussed in #49; we want to name the basic equations first and any specific version second such as these:

• rp1_layered_shallow_water.f90 to rp1_shallow_water_layered.f90
• rp1_nonlinear_elasticity_fwave.f90 to rp1_elasticity_nonlinear_fwave.f90
• rp1_reactive_euler_with_efix.f90 to rp1_euler_reactive_with_efix.f90

Changes to the Riemann solvers agreed on in May but not yet implemented...

On Thu, May 31, 2012 at 5:01 PM, Randall John LeVeque [email protected] wrote:

Aron and I just went through the Riemann solvers and are considering
the following changes...

For now stick with mx, etc. and use maux instead of num_aux.

Get rid of maxm in calling sequences: this is no longer needed since
the cell variable is the last index.

Reorder parameters to e.g:
subroutine rpn2(ixy,mx,meqn,mwaves,maux,mbc,ql,qr, &
auxl,auxr,wave,s,amdq,apdq)

Declare ql,qr,auxl,auxr as intent(in) (and convert dimension
statements to f90 more generally)

Change order of rpt2 parameters to
subroutine rpt2(ixy,imp,mx,meqn,mwaves,maux,mbc,ql,qr, &
aux1,aux2,aux3,imp,asdq,bmasdq,bpasdq)

to move imp up to position 2.

A couple related changes in 3d.

In, for instance, the 3D Euler solvers, there are some work arrays whose size is hard-coded. It would be cleaner to size them at run-time, but currently this incurs a performance penalty; see discussion in #75. It seems that in some tests the dynamic allocation leads to a 6-7% slowdown. Once we switch to modules for Riemann solvers, we can size these at run time but still only allocate them once, as module data.

Looking in setup.py, I've blindly added "blas/lapack" as library dependencies to Riemann. We should be doing a better job of querying numpy or scipy for the location of these libraries.

Also need to have GeoClaw point here for its solvers.

Description

riemann/rptest/1d/rp1_driver.f90 contains a wrapper for the vectorized solver to give a pointwise solver taking a single pair of states. Intended for testing solvers and for use in notebooks. See the Makefile to figure out how to run or use with f2py.

Improvements needed:

[ ] Add aux_l, aux_r, and problem_data as input parameters, so calling sequence is the same as pyclaw solvers such as riemann.acoustics_1D_py.acoustics_1D

[ ] Modify riemann/rptest/1d/rp1_driver_test.ipynb to test new version.

[ ] Extend to riemann/rptest/2d/rp2_driver.f90 for normal solver based on an rpn2 subroutine.

[ ] Extend to transverse solver.

[ ] Add travis tests.