[Users] ReflectionSymmetry, tensor tags, ML_BSSN, etc.

Erik Schnetter schnetter at cct.lsu.edu
Tue Nov 23 15:52:00 CST 2010


John

Yes, you are correct (and so are the rumours), to use any of the
advanced symmetries you need to declare the tensor types of your grid
functions. The tensor types are defined in CoreDoc, and the
"tensortypealias" (whever this name may come from...) is the most
important setting. Note that this setting applies to a group of
variables, and the order of the variables in the group does matter.

Most symmetries are rigid rotations, and tensortypealias is the only
tag you need to declare. The other tags are for general coordinate
transformations such as applied e.g. in our multiblock infrastructure
to interpolate between patches. In our counting, a tensor density of
weight 1 is a regular tensor, so the definition of K should be fine --
but as you note, most symmetry conditions ignore the tensor weight
since it does not influence rigid rotations. The McLachlan arrangement
(see <http://einsteintoolkit.org>) is a good example since it declares
tensor properties and is used in production runs, so is likely to be
correct.

The tensor parity may be useful for magnetic fields, depending on how
you declare them -- I hope this tag is taken into account as well.

-erik

PS: If there is documentation missing, feel free to help us out, since
you are now in the unique position to judge what information would be
helpful for a first-time user of these symmetries. Alternatively, open
a ticket at <https://trac.einsteintoolkit.org/>.

On Tue, Nov 23, 2010 at 4:29 PM, John Baker <john.g.baker at nasa.gov> wrote:
> Hi,
>     We've run into some problems recently with our evolution
> code, which boil done to the fact that we'd developed the
> code to support the sort of reflection symmetry defined
> in cartgrid3d, but recently started working with other thorns
> which are expecting the use of ReflectionSymmetry to define
> reflection symmetries.
>      I assume that the motivation for this transition was to
> support more general grids, multipatch codes, etc, but I
> haven't found any documentation for the ReflectionSymmetry
> thorn, or any explanation of its use.
>     One likely problem we are having is that we haven't applied
> any tensor-related tags in our interface.ccl, and rumor has it
> around here that ReflectionSymmetry relies on these tags.
> Presumably there are other EinsteinToolkit thorns which rely on
> tensor tags as well.
>     I did find one document giving some explanation of tensor
> tags
>
> http://cactuscode.org/documentation/CoreDoc.pdf
>
> (thanks Erik).  Erik outlines a number of potential tags there, but
> I would like to know which of these are required to support
> interaction which the various thorns in the toolkit?
>
> Looking at various other interface.ccl files, there didn't seem to be
> a high degree of consistency about which tags are set.  Some
> also naively appear to be set incorrectly, in ML_BSSN.  For instance:
>
> CCTK_REAL ML_trace_curv type=GF timelevels=3
> tags='tensortypealias="Scalar" tensorweight=1.0000000000000000000'
> {
>   trK
> } "ML_trace_curv"
>
> Which seems to declare the trK to be a tensor density.  If this is
> indeed wrong,
> and no one has noticed, then I infer that tensorweight may not really be
> used
> by anything important.
>
> If anyone can clarify these issues for me I would appreciate it.
> Thanks,
> John.
>
> _______________________________________________
> Users mailing list
> Users at einsteintoolkit.org
> http://lists.einsteintoolkit.org/mailman/listinfo/users
>



-- 
Erik Schnetter <schnetter at cct.lsu.edu>   http://www.cct.lsu.edu/~eschnett/


More information about the Users mailing list