Allow aux boundary conditions that don't vary in time

[m-ender]

In cases, where the auxiliary variables are fixed (e.g. for unchanging mapped grids), recomputing the ghost cell values at each time step is a somewhat unnecessary (if small) overhead. In addition, it's slightly annoying that you currently have to write a custom BC in such a case, because none of the built-in BCs may correctly reconstruct the values in those cells. Hence it would be neat if a built-in BC could be provided which simply restored the aux values which were given in those cells when the solver started (or if they weren't even dropped in the first place).

(This came up here: https://groups.google.com/d/msg/claw-users/NW3kiPzMS_w/6BXnykEyUXcJ)

[ketch]

You need to write code that sets the ghost cell values. Whether it is inside a custom BC function or not doesn't make much difference does it? So I think the main issue is that you'd like a way to specify that the aux ghost cells don't need to be updated at later times. That's a good idea, and related to #43. I will put something simple together tonight if I find time.

[ketch]

On second thought, it doesn't make sense to do this until #452 is merged. But here's what I propose. One can set, e.g.

solver.bc_lower[0] = pyclaw.BC.fixed
solver.user_bc_lower = set_aux_ghost_values

Of course, the function set_aux_ghost_values could have any name. The solver would then behave just as if the user had specified a custom BC, except that the aux BC function would only be called once, at the first time step.

In fact, the fixed BC type could be specified for q also, with the same effect.

[mandli]

My one thought about this was that we would have to ensure that the qbc and auxbc persist. I am not sure why this would actually happen though right now. Would this effect the parallel code at all?

[m-ender]

@ketch, yes of course, I need to write the initialiser anyway. But currently I also need to write two ~10 line BC functions (which call that initialiser again to reset the ghost cells), for a case which actually seems more trivial than the built-in BCs. Basically, I need to write code in order that nothing happens. That's not a lot of trouble, but a slightly weird inconvenience.

The fact that PyClaw is also executing unnecessary code if aux wouldn't ever change at all is probably even an independent issue.

[ketch]

@mbuettner If we allowed the ghost cells to be initialized before the run starts, we would lose other flexibilities that were designed into PyClaw from the start. For instance, you wouldn't be able to adjust the order of WENO reconstruction after instantiating the solver, since that would change the size of the ghost cell arrays! It's a tradeoff that I spent a lot of time considering. I believe that your use case is the only one that is (in some sense) more difficult in PyClaw than in earlier versions of Clawpack. It's certainly something we thought should have a nicer solution, but nobody had a pressing need for it until now.

@mandli In the serial case at least, nothing will happen to the ghost cell values between steps. I think this holds in the parallel case too, but I'll have to check.

[ketch]

@mandli An alternative approach would be to have a separate flag to indicate boundary conditions that only need to be set once, at the beginning of the run. Then this flag could be set regardless of which type of boundary condition is used. Let's call this "option B" and the option I outlined above "option A". I'm not sure which is better; do you have an opinion?

[ketch]

Option C would be a radical change to the PyClaw architecture in which we give the BC arrays to the State object, require knowledge of the number of ghost cells when the State is instantiated, and allow the ghost cell values to be filled in the setup script. Then the BCs could be set to "fixed" and no BC routine would ever be called.

Finally (I think), option D would be to keep the BC arrays in the solver, but allocate them when the solver is instantiated. This would again allow initialization of the ghost cells within the user script. When the simulation run starts, we could check whether the number of ghost cells needed has changed, and throw an error in the corner case that it has AND the BCs are set to "fixed".

These are both options I've toyed around with previously. My main objection is that they either lose flexibility or break the abstraction "only the solver knows about the boundary conditions", but that's already broken in the periodic case by PETSc, and maybe it's not important anyway.

[rjleveque]

Just a side note -- in the Fortran versions classic and amrclaw, the bc routine only sets the q values and it is up to setaux to fill in ghost cells for the aux arrays (each time new grids are created in the case of amrclaw, or just once at the start of the computation in classic).