[ET Trac] [Einstein Toolkit] #1261: Suspicious logic in NewRad thorn

[Einstein Toolkit]

#1261: Suspicious logic in NewRad thorn
------------------------------------------+---------------------------------
  Reporter:  wolfgang.kastaun@…           |       Owner:                 
      Type:  defect                       |      Status:  new            
  Priority:  minor                        |   Milestone:                 
 Component:  EinsteinToolkit thorn        |     Version:                 
Resolution:                               |    Keywords:  newrad boundary
------------------------------------------+---------------------------------

Comment (by knarf):

 I agree that this looks very much like a bug to me. Thanks for reporting
 it. Before fixing it I would however rather have someone else also looking
 at it.

 I am also unsure about how to actually fix it. "all_physbnd_or_ghostbnd"
 is commented to be "all boundary faces are either physical boundaries or
 ghost zones". However, in three cases it is calculated to true "if
 physical or not inter-processor" and only in one case "if physical or
 inter-processor". Later, this variable is used to do work only if it is
 true. This I understand as "only apply the boundary conditions (at a given
 point) when there are no symmetry boundaries in any of the three
 directions -- which makes sense.

 However, as I read the code (and apart from the inconsistency mentioned by
 Wolfgang), currently no boundary conditions are applied at points that
 happen to be at the outer boundary, but also at a inter-processor
 boundary.

 If this interpretation is correct, I believe the correct fix would be to
 remove the 'not' from the three offending lines:

 extrap.cc:153
 newrad.cc:329
 newrad.cc:342

 This would also mean that most simulations using NewRad on more than on
 processor didn't have the outer boundary applied at all necessary points,
 and that runs using symmetries might have had outer boundary conditions
 applied where instead symmetry should have been applied. Also, other wrong
 values might have been used because of the inconsistency in extrap.cc
 (which seems to be correct for lower boundaries). In any case, this should
 only influence values at the very outer boundary - not at mesh refinement
 boundaries.

-- 
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1261#comment:1>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit