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@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@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@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
-- Erik Schnetter schnetter@cct.lsu.edu http://www.cct.lsu.edu/~eschnett/ _______________________________________________ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users