diff options
| author | jthorn <jthorn@f88db872-0e4f-0410-b76b-b9085cfa78c5> | 2002-10-28 16:10:15 +0000 |
|---|---|---|
| committer | jthorn <jthorn@f88db872-0e4f-0410-b76b-b9085cfa78c5> | 2002-10-28 16:10:15 +0000 |
| commit | 9e9a76fe8675a45396fcb07f3fb8e65a19b48ed4 (patch) | |
| tree | 4c607d7d9349d3776b61216ae136467817e3ae91 /src | |
| parent | 173443467ee6bd59f78e1c8e413e9ffe2aaac55d (diff) | |
expand/clarify comments about how we handle a corner between two
symmetry ghost zones
git-svn-id: http://svn.einsteintoolkit.org/cactus/EinsteinAnalysis/AHFinderDirect/trunk@866 f88db872-0e4f-0410-b76b-b9085cfa78c5
Diffstat (limited to 'src')
| -rw-r--r-- | src/patch/ghost_zone.hh | 4 |
1 files changed, 3 insertions, 1 deletions
diff --git a/src/patch/ghost_zone.hh b/src/patch/ghost_zone.hh index c548145..2946837 100644 --- a/src/patch/ghost_zone.hh +++ b/src/patch/ghost_zone.hh @@ -61,7 +61,9 @@ // symmetry operations to get gridfn data in the corner from the // nominal grid. Symmetry operations commute, so at each point we'll // always get the same results independently of in which order we do -// the symmetry operations. +// the symmetry operations. Computationally, we actually do the operations +// in both orders, one order's results overwriting the other's, but +// this doesn't matter (because the results are the same). // * A corner between two interpatch ghost zones, for example the +x/+y // corner in the example below. In this case we could get the gridfn // data by either of two distinct interpolation operations (presumably |