search

ianhinder / Kranc

A Mathematica package for generating code for solving time dependent partial differential equations
http://kranccode.org
GNU General Public License v2.0
29 stars 10 forks source link

Boundary condition registration errors should be fatal #32

Open eschnett opened 14 years ago

eschnett commented 14 years ago

An error in registering boundary conditions should be fatal. I believe it used to be fatal, and has now become a warning. An error in applying boundary conditions usually indicates a severe inconsistency either in variable declarations and scheduling, and should abort the code.

ianhinder commented 14 years ago

Can you be more specific? Are you referring to the code generated in Boundaries.c which "selects" boundary conditions for variables? In the generated code for SimpleWave, all the error conditions are reported with CCTK_WARN(0, ...) which is fatal.

eschnett commented 14 years ago

I saw the line

    "  CCTK_WARN(1, " <> Quote["Failed to register flat BC for "<>g<>"."] <> ");\n" }];

as one of the changes that were recently introduced. This is line 65 in CalculationBoundaries.m. Maybe the actual code is generated in a different path and not via this function?

ianhinder commented 14 years ago

There are two separate pieces of code for selecting boundary conditions for variables. One is the old code for evolved variables in Boundaries.m, and the other is new code for "pseudo-evolution" calculations in CalculationBoundaries.m. It might make sense to refactor this.

The line you quote is generated on (current) line 65 of CalculationBoundaries.m. This will only be used for "pseudo-evolution" calculations. git annotate reveals that this line was changed in:

commit 3d6cc02c4fc79e7969adeeeaf3a2a044462e440c
Author: Ian Hinder <ian.hinder@aei.mpg.de>
Date:   Wed Aug 4 16:47:04 2010 +0200

    CalculationBoundaries.m: Change severity of warning (from 0 to 1) when BCs cannot be registered.

    At the moment, we register all faces, even though some of them might have been registered already as interpatch boundaries.

So this is to work around a problem with multipatch where some of the boundary faces will have been registered as interpatch boundaries, and Kranc then wants to register the "flat" boundary condition to everything else (i.e. outer boundaries for analysis quantities). Maybe the best approach is to add a check to see if the boundary has already been registered? Do you know of example code where this is done? Another thing that this throws up: what stops Kranc from registering the boundaries first, before the multipatch thorn?

eschnett commented 14 years ago

It's been a time since I looked at symmetries and boundary conditions.

Symmetry conditions register the faces on which they apply at or shortly after startup. These are fixed during evolution, and they apply to all variables. Regular boundary conditions are selected (not registered) during evolution, mostly at MoL_Poststep, and are then applied. This selection happens once per application, and is per variable.

Thus it seems that registering symmetries and selecting boundary conditions can't conflict, because they happen at different times. It would also assume that selecting a boundary condition for a registered symmetry face is a no-op, since the symmetry condition presumably takes precedence. (If you select a boundary condition without choosing faces, it is selected on all faces.) That is, it is possible (and presumably does not even lead to a warning) to select a boundary condition for a symmetry face.