On 19 Jul 2012, at 16:02, Erik Schnetter wrote:
On Thursday, July 19, 2012, Ian Hinder wrote:
On 19 Jul 2012, at 13:02, Erik Schnetter wrote:
On Thu, Jul 19, 2012 at 11:21 AM, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 19 Jul 2012, at 11:19, Erik Schnetter wrote:
Comer
Do you intend to use existing thorns to evolve e.g. the Einstein equations, or do you plan to write your own thorns?
If you use existing thorns: As written, they will not be able to handle the coordinate singularities on the axes. Instead, we use multi-block methods.
If you write your own thorns: Since you will be implementing your own differencing methods, the Cactus coordinates are basically only needed to label grid point. CartGrid3D can handle this; e.g. spherical or cylindrical coordinate systems are orthogonal. You will only need to correctly specify the respective coordinate ranges (e.g. using [0,rmax] for r and [0,2pi] for phi) in your parameter file. The unification of f(phi=0) and f(phi=2pi) would be handled via a periodicity condition, which is provided e.g. by thorn Periodic.
What remains is that Cactus labels the coordinates x,y,z instead of r,z,phi... but this is mainly a small inconvenience. Altogether, it is straightforward to use spherical or cylindrical coordinates with existing thorns, and we therefore never bothered to implement any new coordinate systems for this.
I think that CoordBase does not support anything other than CartGrid3D, so you won't be able to use any thorn which uses CoordBase.
What I describe above uses CartGrid3D...
Aha. Yes. So what does CartGrid3D actually do when you ask for spherical coordinates? x, y and z are mapped to r, theta and phi, but since you set the ranges yourself anyway, what more is needed?
CartGrid3D sets the coordinate fields for each grid point, which is typically needed to set up initial conditions. CartGrid3D does nothing else. In many codes, the coordinate system also influences how derivatives are defined (e.g. Laplace looks different in Cartesian and in spherical coordinates), but since one has to define Laplace oneself when implementing finite differencing a routine, this is not an issue here.
So the grid::x, y and z coordinate grid functions will be filled with the Cartesian coordinate values, computed as if the underlying grid is r, theta, phi?