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

Tue Nov 23 17:48:19 CST 2010

Of course. Thanks...

-erik

On Tue, Nov 23, 2010 at 6:26 PM, John Baker <john.g.baker at nasa.gov> wrote:
> 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
>>>
>>
>>
>
>

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