clawpack / apps

Repository of applications of Clawpack and related codes

Please see the documentation for Clawpack at http://www.clawpack.org.

If you are cloning this repository, the following pages may be of particular interest:

• Installation instructions for Developers' (or more generally from this repository),
• Other installation options,
• Which Clawpack solver should I use?
• Developers' Guide, including guidelines for contributing to the project,
• Regression testing,
• Keeping track of repository versions with git,
• Clawpack Community, with links to Google groups, issue trackers, Developers' workshops, etc.

apps's Issues

Fix fvmbook examples that have local Riemann solvers

Many Makefiles should point to the clawpack/riemann repository instead of having local rp routines.

Other examples will need to be updated for clawpack/riemann#57.

Beach example has buggy initial data

In this notebook

https://github.com/clawpack/apps/blob/master/notebooks/pyclaw/beach.ipynb

default value of

ambient_surface_height  = 1.

leads to negative values of initial water height, so code will not run.

E.g., set

ambient_surface_height  = 1.2

to get good results.

Switch to using `data` rather than `clawdata`

Add shock-bubble Euler problem

Add this example as it seems to be one that every package has done. May provide a basis for a gallery of the different packages and their advantages and disadvantages.

add fvmbook directory with all examples from red book

The following can be adapted from the 4.6 versions at http://depts.washington.edu/clawpack/users-4.6/claw/doc/gallery/gallery_book.html

• chap3/acousimple
• chap6/compareadv
• chap6/wavepacket/
• chap7/acouinflow/ (scott)
• chap7/advinflow/
• chap7/standing/
• chap9/acoustics/interface
• chap9/acoustics/layered
• chap10/tvb/ (niket)
• chap11/burgers/ (jihwan)
• chap11/greenlight/
• chap11/redlight/
• chap12/efix/ (niket)
• chap12/llf/
• chap12/nonconservative/
• chap13/collide/
• chap16/vctraffic/ (Brisa)
• chap17/advdiff/
• chap17/onramp/
• chap20/burgers/
• chap20/rotate/
• chap21/corner/ (brisa)
• chap21/radialdam/
• chap22/corner/ (scott)
• chap22/rp/
• chap23/acoustics/

The following can be found in the 4.3 book site http://depts.washington.edu/clawpack/clawpack-4.3/book.html

• chap8/modeqn/
• chap8/wavepacket/
• chap9/color/
• chap9/traffic/
• chap11/congestion/
• chap13/dambreak/
• chap13/slosh/
• chap13/swhump1/
• chap13/tworaref/
• chap13/twoshock/
• chap15/slowshock/
• chap15/startup/
• chap15/wcblast/
• chap16/bucklev/
• chap16/fsin/
• chap17/advreact/
• chap17/nocommute/
• chap17/stiffburgers/
• chap21/acoustics/
• chap21/radialdamabc/
• chap22/inclusion/
• chap22/plate/
• chap23/advection/
• chap23/euler/
• chap23/shallow/

Access rights for multilayer-examples

Cloning the apps repository using --recursive was not successful for multilayer examples. Also, the surge-examples folder cloned is empty.

Trying again with git submodule init did not resolve it either.

Add better tracking of version compatibility to each app

At the very least keep a README in each app that mentions compatibility and gets updated when a new version is released (see #54).

Store executed versions of notebooks

Currently we are storing notebooks with all output removed. I think we should instead store fully-executed notebooks.

Advantages:

• Anyone viewing the notebook on github will see the output (including images and JSAnimations) without having to download and run the notebook
• Currently we keep a second copy of most notebooks, executed, as a gist. Duplication is evil! Even moreso for notebooks, since they are harder to diff. This will avoid it.
• We could include a watermark cell in each notebook, showing the version of Clawpack (and other libraries) that it was last executed with. This would be a nice solution to #55.

Disadvantages:

• Bigger files. But I don't think they'll be huge, and I think it's okay for an 'apps' repository to be fairly heavy.
• Output like images and animations may change and can't reasonably be diffed. Again, I think this is okay. Its only effect is to create large sections of unparseable stuff in the diffs, and I believe that's worth it.

Problems when running dtopotools_examples.ipynb locally

I tried to run the dtopotools_examples notebook locally with clawpack 5.3.1 and ran into some problems:

from clawpack.geoclaw.util import get_remote_file results in an error stating that get_remote_file cannot be imported. This function does not exist in clawpack.geoclaw.util. Instead I could use from clawpack.clawutil.data import get_remote_file.

Under the heading "Create a fault using the NOAA SIFT database directly" the file info_sz.dat.txt is supposed to be loaded by the command f2 = dtopotools.SiftFault(sift_slips). The file is supposed to be in the dirrectory '/usr/lib64/python2.7/site-packages/clawpack/geoclaw/data/info_sz.dat.txt'. However, it seems that this file is not installed during the installation of clawpack, although it is in the source directory.

I hope that helps.

Best regards, Stefan

Duplication of notebooks between doc and apps

Some notebooks -- like the 3 in the notebooks/geoclaw folder -- exist both in clawpack/doc and clawpack/apps. This duplication is problematic since it means twice the work in maintaining them, if we remember to maintain them at all. Note that at least one of these notebooks is currently broken (see #60).

I suggest that any given notebook be kept either in doc (if it serves primarily as documentation) or in apps (if it does not), but not both.