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

[Erik Schnetter]

Bernard

I am taking back what I said before, and admit my ignorance. It has
been a long time since Jonathan Thornburg implemented his first
multiblock system in Cactus.

- yes, the default for the tensor weight is 0 (I checked Jonathan's code);
- yes, a regular tensor should have weight 1;
- no, I don't know how I got confused.

It is apparent that we haven't used McLachlan with a multiblock code
that stores patch-local tensor components. If one stores global tensor
components, then no transformation needs to be applied, and the tensor
weight (again) plays no role.

-erik

On Tue, Nov 23, 2010 at 5:09 PM, Kelly, Bernard J.
(GSFC-660.0)[UNIVERSITY OF MARYLAND BALTIMORE COUNTY]
<bernard.j.kelly at nasa.gov> wrote:
> Hi Erik.
>
> The following statement seemed strange to me:
>
> "In our counting, a tensor density of weight 1 is a regular tensor,
> so the definition of K should be fine."
>
> The only density-weight convention I've seen has w = 0 for
> (non-densitized) tensors. Is the Cactus convention just a uniform shift of
> 1 from what I'm used to, or something more complicated? And where did it
> come from?
>
> Also, looking at the CoreDoc PDFJohn linked to, the "tensorweight"
> description states:
>
> "If omitted, most code will use a default weight of 0."
>
> Presumably this statement is incorrect now, as you'd want the default
> behaviour to be that of a normal (non-densitized) tensor, right?
>
> Bernard
>
> On 11/23/10 4:52 PM, "Erik Schnetter" <schnetter at cct.lsu.edu> wrote:
>
>>John
>>
>>
>>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/
>>_______________________________________________
>>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/