Roland
It seems that these lines pertain to dimensions that are larger than the dimension of the respective grid variable. That is, this would e.g. set the extent of the z (sic!) boundary to 1 for 2d variables that don't have a z direction. Is this intended?
-erik
On Apr 29, 2014, at 2:57 , rhaas@tapir.caltech.edu wrote:
User: rhaas Date: 2014/04/28 07:57 PM
Modified: /trunk/src/ CopyBoundary.c, FlatBoundary.c, ScalarBoundary.c, StaticBoundary.c
Log: correct 1d, 2d boundary handling
since rev 309 1d and 2d evolutions would not apply the boundary condition
File Changes:
Directory: /trunk/src/
File [modified]: CopyBoundary.c Delta lines: +2 -2 =================================================================== --- trunk/src/CopyBoundary.c 2014-03-23 02:13:34 UTC (rev 326) +++ trunk/src/CopyBoundary.c 2014-04-29 00:57:01 UTC (rev 327) @@ -1149,8 +1149,8 @@ so that we can use the INDEX_3D macro later on */ for (i = gdim; i < MAXDIM; i++) {
- ash[i] = 0;
- lsh[i] = 0;
ash[i] = 1;
lsh[i] = 1; }
/* get the current timelevel */
File [modified]: FlatBoundary.c Delta lines: +2 -2 =================================================================== --- trunk/src/FlatBoundary.c 2014-03-23 02:13:34 UTC (rev 326) +++ trunk/src/FlatBoundary.c 2014-04-29 00:57:01 UTC (rev 327) @@ -975,8 +975,8 @@ so that we can use the INDEX_3D macro later on */ for (i = gdim; i < MAXDIM; i++) {
- ash[i] = 0;
- lsh[i] = 0;
ash[i] = 1;
lsh[i] = 1; }
/* get the current timelevel */
File [modified]: ScalarBoundary.c Delta lines: +2 -2 =================================================================== --- trunk/src/ScalarBoundary.c 2014-03-23 02:13:34 UTC (rev 326) +++ trunk/src/ScalarBoundary.c 2014-04-29 00:57:01 UTC (rev 327) @@ -1114,8 +1114,8 @@ so that we can use the INDEX_3D macro later on */ for (i = gdim; i < MAXDIM; i++) {
- ash[i] = 0;
- lsh[i] = 0;
ash[i] = 1;
lsh[i] = 1; }
/* get the current timelevel */
File [modified]: StaticBoundary.c Delta lines: +2 -2 =================================================================== --- trunk/src/StaticBoundary.c 2014-03-23 02:13:34 UTC (rev 326) +++ trunk/src/StaticBoundary.c 2014-04-29 00:57:01 UTC (rev 327) @@ -994,8 +994,8 @@ so that we can use the INDEX_3D macro later on */ for (i = gdim; i < MAXDIM; i++) {
- ash[i] = 0;
- lsh[i] = 0;
ash[i] = 1;
lsh[i] = 1; }
/* get the current timelevel */
Commits mailing list Commits@cactuscode.org http://cactuscode.org/mailman/listinfo/commits
Hello Erik, all,
It seems that these lines pertain to dimensions that are larger than the dimension of the respective grid variable. That is, this would e.g. set the extent of the z (sic!) boundary to 1 for 2d variables that don't have a z direction. Is this intended?
Yes, it treats a 2d grid variable as a 3d grid variable with 1 point in the z direction. This should be fine as far as I know.
Before revision 309 (which introduced ash and removed lssh) the code actually read: --8<-- for (i = gdim; i < MAXDIM; i++) { lssh[i] = 1; lsh[i] = 0; + lsh[i] = 0; } --8<-- which 309 changed to --8<-- for (i = gdim; i < MAXDIM; i++) { lsh[i] = 0; } --8<-- which is actually wrong since it will mean eg the kk loop in SCALAR_BOUNDARY_TYPED (in the scalar boundary code) will never execute its loop body and the b/c will not be applied anywhere.
Instead of setting ash to 1 one could also set it to 0 but that leads to the situation that ash < lsh which is no the case for regular grid variables.
Yours, Roland
users@lists.einsteintoolkit.org