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@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@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 (seehttp://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 athttps://trac.einsteintoolkit.org/.
On Tue, Nov 23, 2010 at 4:29 PM, John Bakerjohn.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 Schnetterschnetter@cct.lsu.edu http://www.cct.lsu.edu/~eschnett/ _______________________________________________ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users