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

[John Baker]

Hi,
     Not to belabor the point, but, did you mean to say,
"yes, a regular tensor should have weight 0."
John.

  On 11/23/10 6:20 PM, Erik Schnetter wrote:
> 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
>>
>
>