[Users] coordinate systems

[Erik Schnetter]

On Thu, Jul 19, 2012 at 3:29 PM, Ian Hinder <ian.hinder at aei.mpg.de> wrote:
>
> 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 at 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?

No.

In your mind, you rename the coordinates x,y,z to r,z,phi. You then
use CartGrid3D to define the ranges you want to simulate, i.e.
[0,2pi] for phi. You also set up periodic boundary conditions in the
phi direction. These are then cylindrical coordinates.

Cylindrical (and spherical) coordinates have equidistant grid points
in the r,z,theta,phi direction, and their grid lines are orthogonal;
this is the same as for Cartesian coordinates. This is the only thing
relevant here.

What one usually means by "coordinate system" includes also the
respective metric terms when calculating derivatives. However, as this
is not handled by CartGrid3D, this is not relevant here.

-erik

-- 
Erik Schnetter <schnetter at cct.lsu.edu>
http://www.perimeterinstitute.ca/personal/eschnetter/