clawpack / amrclaw Goto Github PK

when out of nodal size, or out of boundary space, suggest auto-resizing the way the alloc array is done.

Working in GeoClaw version of rjleveque but needs to be incorporated into amrclaw 2d.
Extension to 3d?

Hi I found a bug in line 158 of stepgrid.f when calling src2 subroutine.
It says:
call src2(mx,my,nvar,mbc,mx,my,xlowmbc,ylowmbc,dx,dy,
& q,maux,aux,time,dt)

and it should be
call src2(nvar,mbc,mx,my,xlowmbc,ylowmbc,dx,dy,
& q,maux,aux,time,dt)

Cheers,
Mauricio

Kyle and Randy started moving code, starting with 2d amrclaw and the swirl example (in tests/swirl).

Things still to be done:

• Convert call.i to a module
• Modify Makefile to use new version that list modules separately
• Make sure paths work with new repository structure
• Put scripts such as runclaw.py in clawutil repository
• Update input/output parameters

we allow maxgr of 15000 grids. The size of the field that outputs the grid number should match this, but is currently only set to i4, not i5, in the format statement.

See clawpack/riemann/issues/29

Fix common blocks that and then confirm this example works.

First pass at an example is in #132, which was closed in favor of #133, so example was not merged. Needs better documentation.

To be compatible with 3d classic (done by Grady Lemoine) and all the 1d, 2d codes.

Gauge output is currently printed to an ascii file in a way that requires a critical block, since all gauges are written to the same file.

We might consider an option in which an array is allocated for each gauge and values are inserted in this rather than being written each timestep. Then write at the end of the run.

Advantages:

• Would not need critical block
• Should be faster than writing every time step for long runs with many gauges, particularly in binary
• Could also write in HDF or NetCDF form, perhaps useful.

Disadvantages:

• Don't know at start how many timesteps will be printed, and this can vary between gauges depending on where then are relative to refinement and what time interval is specified for printing. So we would need some reallocation strategy or else a way to dump partial results.
• Cannot view partial gauge outputs while run is still going, often quite useful in GeoClaw.

Note: could also write every time step but to a different file for each gauge, so wouldn't need the critical block. This might be advantageous for other reasons in general, but it might lead to a huge number of files in some cases. (Usually there are a few gauges at most, but might want to put down e.g. a 100 by 100 grid of gauges for some application?)

See also #94 and consider adding precision option.

amrclaw/examples/acoustics_2d_radial/1drad
was copied from 4.x and needs to be updated to 5.0 form.

Narrowed issue down to call to qad in advance.f. Commenting out lines 217-220 in advance.f avoids the problem for now.

And modify declarations accordingly.

setgrd.f and regrid.f both set

verbosity_regrid = method(4)

which is not correct. It is a separate variable in amr_module

Hi,

I am trying to plot data from clawpack in Paraview. I wrote a python code based on pyclaw to convert clawpack output data to VTK format (vtkOverlappingAMR), which can be read by Paraview. The prototype works well except for that sometimes Paraview will crash with "segmentation fault" occasionally. One reason for this might be because I didn't specify whether a cell has finer grid on top of it.

Does anybody know how I can tell, from clawpack output data, whether a cell (or a region) is covered by a patch with a grid of higher levels (Perhaps from pyclaw)?

Thanks!

Dimensional splitting is currently not implemented in amrclaw. This requires modification to the stepgrid function.

multi-threaded fluxes should be stack based rather than coming out of alloc array

The call to ceiling to set new_size in line 74 returns a 32 bit integer. With a large number of grid cells, new_size is assigned a negative value as the 32 bit integer is overflowed. For my particular code, I've been able to get around this by using "ceiling(..., 8)" to denote a 64-bit integer (and adding "kind=8" to integer declarations where appropriate).

xlower refers to the position whose x value is less than the cell centers of all ghost cells. I believe a simply change to the calling function spest will fix this, but wanted to post this before a PR in case I'm missing something.

geoclaw contains routines to monitor the maximum of specified velocities over the full simulation at points on a specified "fixed grid" (which can be an unstructured set of points), as described at
http://www.clawpack.org/fgmax.html.

This could be useful for other applications beyond geophysical flows, so eventually we should port this to amrclaw.

Need to be re-ordered and tested.
Removed old versions in commit b0fc0b9

After doing a restart, fort.gauge only has the gauge output since the restart time, output from the original run is lost.

Should we append to the old fort.gauge, or is it better to keep current behavior but document it so users know to save fort.gauge elsewhere before restarting?

Appending might not always be the right thing to do, e.g. if the user restarts several times from the same checkpoint file.

setrun.py now has
clawdata.fwave = False
by default, but if True it should use fwaves rather than q waves.

This is not yet implemented in amrclaw/src/2d/flux2.f

The code in amrclaw/src/2d/flux2fw.f is partially reordered, not working.
This file should be deleted once flux2.f is fixed.

setgrd should not need to call advanc unless Richardson estimation is done. Doing so currently leaves time set to the wrong value when used in allow_flag.

Maybe Kirsten has this somewhere?

A bug apparently introduced when filpatch was made fully recursive, but hasn't shown up on our standard test suite. It shows up e.g. with inflow boundary conditions for 2d advection. The problem is that filpatch needs to fill small patches of ghost cells but the entire grid is passed in to bc2amr.

@mjberger is working on it. We may need to change the calling sequence of bc2amr.

Need to have a test for source terms to avoid bugs like #102.

Particularly at time t=0.3. Any issue here that needs fixing?

It has come up for storm surge that we would like to output some of the aux array fields in the gauges. It would be nice to have a flexible input mechanism for outputting a subset of the aux array variables at the gauges.

The following works in amrclaw/src/lib:
gfortran -x f95-cpp-input -D MAX1D=200 -c amr_module.f90

Some of the regression tests in amrclaw/tests (and other repos) only check the gauge output and assert some scalar based on this (e.g. sum of all values) agrees with archived values to a tolerance of 1e-14.

But fort.gauge currently only has 7 digits of output, so this doesn't make sense.

Should fort.gauge have more digits in general?

Perhaps not since for some applications there's a lot of gauge output and more digits aren't really needed.

One the other hand the fort.q files now have 16 digits by default and these are often much bigger files.

Probably they should be consistent with each other and ideally set to some parameter that could be easily changed?

A related question is whether there are better ways to design regression tests.

See clawpack/classic#61, and comment there.

The example in examples/acoustics_3d_interface has initial data that is a plane wave. I introduced this as a first debugging test. Eventually we should replace this to match the old 4.3 example at
http://depts.washington.edu/clawpack/clawpack-4.3/applications/acoustics/3d/varying/interface/www/index.html
which had a wave coming from the top boundary.

This will also require changing qinit.f and adding a local bc3amr.f routine.

This change was made in the riemann repository and currently the Riemann solvers don't work in amrclaw.

I am not sure where this should be fixed but I was doing some modifications to step2 and flux2 recently and noticed that the calling sequences are not the same between GeoClaw and AMRClaw. At some point we started declaring space for the cqxx and other arrays inside of flux2 rather than further up the call stack and passing it as an argument into each routine. We should probably make this consistent between both GeoClaw and AMRClaw.

On the master branch @826b95c0df7, examples/burgers_3d_cubedata gives this error:

Reading data file: setprob.data
         first 5 lines are comments and will be skipped
 Storage allocated...
there are    1 grids with     8000 cells at level   1
  error in filrecur - level 1 not set
  should not need more recursion 
  to set patch boundaries
start at row:    1 col    1 file    1

@mjberger are you getting this error too?

I have written a shockbubble example in Clawpack 5.0, with the idea that I could compare the results to ForestCllaw. But along the way, I realized that the solutions between 4.x and 5.0 versions differ quite a bit for this problem. Forestclaw results compare quite nicely with the 4.3 version (not surprising, since I am using 4.x routines), but not at all with 5.0. I am hoping there is something simple that might have changed between versions that could explain the difference. I can update Forestclaw if needed.

Here are three pictures showing the differences :

I realize this problem is very susceptible to small perturbations, but in fact, this is exactly why it is a good test of AMR schemes. The AMR shouldn't be perturbing the solution in any significant way. The fact that forestclaw and 4.3 produce such similar,results using very different adaptive schemes suggests that the AMR isn't perturbing the solution too much. I think I've checked all the obvious sources of discrepency (limiters, order of accuracy, source terms, resolution, color axis, etc ...) I also tried turing off the entropy fix, in case that what appears to be a newer version in 5.0 was affecting things.

Any thoughts on what could be a possible source of difference would be very useful. I can issue a PR for the shock-bubble example, if that would be helpful, or provide more general info on how I've set up the problem.

Also need to change to new input parameters,
add new options for output_style, checkpt_style, etc. in tick.f

The routine allowflag is still used in 3d to allow the user to specify whether a cell is allowed to be flagged at a given level. But this is only checked when doing the initial flagging, not when buffering, and so the patches create may extend into the region where refinement to this level should not be allowed.

@cjvogl has a problem with an interface where there's a big jump in wave speed. We'd like to have the finest level grid up to the interface on one side but never extending into the other side (where the CFL would be >1 with the time step desired).

I suggest we check allowflag when buffering.

Also, we might want the restrictions imposed by regions to also apply when buffering, as a special case of the above.

In 2d I think we eliminated calls to allowflag when regions were introduced, but cases like this suggest it might also be nice to have an allowflag that the user could use to specify constraints like this that don't map to rectangles nicely?

And we should introduce regions in 3d to complement allowflag.

Application/example Makefiles should say:

FFLAGS ?=

and not mention FC.

Users should be encouraged to set environment variable FFLAG for the flags they generally want. (Add documentation page.)

Makefile.common will check if FC is set to f77 (which it is by default on some systems) and if so, reset to gfortran (since f77 won't work). Users who want to use ifort or another compiler can set environment variable FC.

Default Makefiles will not have -fopenmp

Remove all the commented out lines in various Makefiles, add documentation to list standard combinations of FC and FFLAGS that users might want to use.

This will clean up Makefiles and also avoid developers checking in modified Makefiles with flags that don't work for others.

amrclaw/tests/shockbubble/Makefile contains stuff that should be moved to clawutil/src/Makefile.common?

Need to check and understand OpenMP parallelism bottle-necks and where we may be able to increase performance by helping compilers with vectorization.