Leo Setting up the grid size can sometimes be confusing, as it is very easy to make "off-by-one" errors. To check this, I recommend producing 1D output in the x, y, and z directions, and then looking at the coordinates of the grid points that are output. You can then immediately see whether the number of grid points is as expected, and whether the coordinates is as expected. Note that the option IOASCII::output_symmetry_points = no means that the 3 boundary points that exist in each direction are not output -- for testing, you may want to disable this option.
The gowdy.par file that I see uses "round" numbers for resolution and domain boundaries. Is there a particular reason that you are using less "round" numbers? Looking at gowdy,par, I think there is an error. With periodic boundaries, and if you place a grid point right onto the boundary (which this parameter file does), then one boundary (e.g. the left) is closed, while the other (the right) is then open. That is, of the two grid points right on the boundary, one should be part of the domain and should be evolved, while the other should be outside of the domain and should be defined via the periodicity condition to be just a copy of the other point. This is not the case here. To remedy this, I would change the three parameters for the lower boundary to CoordBase::boundary_shiftout_x_lower = 1 CoordBase::boundary_shiftout_y_lower = 1 CoordBase::boundary_shiftout_z_lower = 1 Instead of checking for periodicity graphically, I recommend producing 1D ASCII output and comparing numbers. Periodicity must be exact, i.e. all available digits of the boundary points must agree with the respective points from the interior of the other side of the domain. Since this parameter file uses three boundary points, e.g. points 1,2,3 at the lower boundary must agree with point 6,5,4 at the upper boundary (counting from the upper boundary), and vice versa. The situation must be completely symmetric -- the first three grid points at the lower boundary must agree with the "second" set of three grid points at the upper boundary. HOWEVER: The domain itself must be slightly asymmetric. At the lower boundary, there must be three additional grid points below -0.51, i.e. at coordinates -0.57, -0.55, and -0.53. At the upper boundary, there must be only two additional grid points, since the upper boundary point is already outside the domain, i.e. a boundary point (see closed vs. open above). That is, at the upper boundary, the last three grid points must have the coordinates +0.51, +0.53, +0.55. Thorn CactusBase/CoordBase should have some documentation including graphs that explain this in more detail. Changing the domain size e.g. to CoordBase::xmin = -0.11 CoordBase::ymin = -0.11 CoordBase::zmin = -0.51 CoordBase::xmax = +0.11 CoordBase::ymax = +0.11 CoordBase::zmax = +0.51 should then lead to a consistent, periodic evolution. -erik On 2013-09-06, at 20:31 , Leo Brewin <[email protected]> wrote: > Hi, > > My apologies if this is a dumb question. > > I'm playing with the gowdy.par file provided in the Einstein toolkit > (Cactus/par/arXiv:1111.3344/cosmology) and I'm having trouble enforcing the > periodic boundary conditions. The original gowdy.par file sets up a grid like > this > > INFO (CartGrid3D): Grid Spacings: > INFO (CartGrid3D): dx=>2.0000000e-02 dy=>2.0000000e-02 dz=>2.0000000e-02 > INFO (CartGrid3D): Computational Coordinates: > INFO (CartGrid3D): x=>[-0.550, 0.550] y=>[-0.550, 0.550] z=>[-0.550, 0.550] > INFO (CartGrid3D): Indices of Physical Coordinates: > INFO (CartGrid3D): x=>[0,55] y=>[0,55] z=>[0,55] > > But that is a huge overkill -- the gowdy metric has symmetries in the x,y > directions. So I modified gowdy.par to use > > CoordBase::xmin = -0.0390625 > CoordBase::ymin = -0.0390625 > > CoordBase::xmax = 0.0390625 > CoordBase::ymax = 0.0390625 > > CoordBase::dx = 0.0078125 > CoordBase::dy = 0.0078125 > > CoordBase::zmin = -0.5078125 > CoordBase::zmax = +0.5078125 > CoordBase::dz = 0.0078125 > > and this created the following grid > > INFO (CartGrid3D): Grid Spacings: > INFO (CartGrid3D): dx=>7.8125000e-03 dy=>7.8125000e-03 dz=>7.8125000e-03 > INFO (CartGrid3D): Computational Coordinates: > INFO (CartGrid3D): x=>[-0.055, 0.055] y=>[-0.055, 0.055] z=>[-0.523, 0.523] > INFO (CartGrid3D): Indices of Physical Coordinates: > INFO (CartGrid3D): x=>[0,14] y=>[0,14] z=>[0,134] > > The problem now is that after just one time step the extrinsic curvatures are > not periodic -- there are sharp jumps in Kzz at z=+/-0.5. The original gowdy > file does not *appear* to have this problem (though with 56 grid points the > jumps in Kzz will, if they exist, be much smaller than for just 15 points in > my case). > > Am I doing something silly here? I've made no other changes to the gowdy.par > file (other than to comment out the HDF5 stuff). I'm running this through the > Einstein Toolkit/McLachlan on a single processor Mac. > > Any suggestions would be most welcome, thanks > > Cheers, > Leo > > _______________________________________________ > Users mailing list > [email protected] > http://cactuscode.org/mailman/listinfo/users -- Erik Schnetter <[email protected]> http://www.perimeterinstitute.ca/personal/eschnetter/ My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://pgp.mit.edu/.
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Users mailing list [email protected] http://cactuscode.org/mailman/listinfo/users
