Units in catalogue files

[t00fri]

Well, it is Friday night / Sat morning here...

vive de largo la revoluci?n !!!

Oha! Since here it's just Friday afternoon, you must be located in the EAST of me!! Sorry I always placed you to the WEST of me (US) because of your native pleasure with your English mother tongue .

Hence, do I have to locate you to Australia, perhaps??

Fridger

[ajtribick]

It always adds to transparency, if the property's name uniquely suggests the basic dimension

Pity that spherical coordinates are so useful...

That the CoreRadius property of a globular cluster is in fact an angular unit strikes me as a bit odd. Obviously this keeps close ties to the source catalogue but goes against the use of "Radius" everywhere else as a length quantity. Nevertheless, allowing angular radii for stars might be interesting in the context of CHARM2... but that's another project.

One of the arguments for not allowing specification of dimensions per component of a vector is that there are several examples of vectors which are only used for direction - magnitude is irrelevant. Units can thus be conveniently skipped for these vectors, unless you allow units per component.

[t00fri]

It always adds to transparency, if the property's name uniquely suggests the basic dimension

Pity that spherical coordinates are so useful...

Yes they are VERY useful and NO physicist would ever have the idea to define a vector like so

Code: Select all

xvec = [r, theta, phi]


but rather

Code: Select all

xvec=[r * sin(phi) * sin(theta), r * cos(phi) * sin(theta),r * cos(theta)]


with all three components of xvec being of dimension [length]. Please note that physical quantities with components of mixed dimensions represent a "dead sin" .

That the CoreRadius property of a globular cluster is in fact an angular unit strikes me as a bit odd.

It is not odd of course, since this is a speciality of astronomers and their measurement constraints... Well trained physicists would certainly want to rebaptize the CoreRadius into CoreAngularRadius or similar.
I am sure you know this but just wanted to provoke me a bit . Sure enough, I decided to use their construct in order not to cut the link to the scientific literature in this field...

Fridger

PS: among physicists: the very reason why scalar, vector, tensor quantities in physics should have a well-defined dimension is to warrant "covariance" under conversion transformations of units.
Imagine a gauge theory (like for example General Relativity), where the field components carry different dimensions

[Cham]

Imagine a gauge theory (like for example General Relativity), where the field components carry different dimensions

Well, the metric tensor in General Relativity can indeed have components with different dimensions. Example : the well known Schwarzschild metric in the usual Schwarzschild spherical coordinates :

[tex]ds^2 = (1 - \frac{2 G M}{r c^2}) (dx^0)^2 - \frac{dr^2}{1 - \frac{2 G M}{r c^2}} - r^2 d\theta^2 - r^2 \sin^2 \theta d \phi^2[/tex]

Here, the time-time component [tex]g_{00}[/tex] and radial component [tex]g_{rr}[/tex] are dimensionless, while the [tex]g_{\theta \theta}[/tex] and [tex]g_{\phi \phi}[/tex] components have the dimension of a squared-lenght.

The components of any physical object (vector, tensor, etc) actually depend on the base (or coordinates) used. Of course, the vector/tensor itself is independant of the coordinates used and has a very definite dimension (squared-lenght for the metric tensor). But the components can have any dimensions we want and this has nothing to do with the field itself. It's simply a matter of convenience related to the coordinates used.

By the way, the LaTeX capabilities of the forum appear to be gone

[ajtribick]

Question for people who have more experience with using meshes than I do: how does the MeshCenter property work? Is this a dimensional quantity (and should therefore support units) or does it work in the internal coordinate units of the mesh?

[t00fri]

Imagine a gauge theory (like for example General Relativity), where the field components carry different dimensions

Well, the metric tensor in General Relativity can indeed have components with different dimensions. Example : the well known Schwarzschild metric in the usual Schwarzschild spherical coordinates :

[tex]ds^2 = (1 - \frac{2 G M}{r c^2}) dx^0 ^2 - \frac{dr^2}{(1 - \frac{2 G M}{r c^2})} - r^2 d\theta^2 - r^2 \sin \theta^2 d \phi^2[/tex]

Here, the time-time component [tex]g_00[/tex] and radial component [tex]g_rr[/tex] are dimensionless, while the [tex]g_{\theta \theta}[/tex] and [tex]g_{\phi \phi}[/tex] components have the dimension of a squared-length.

Martin,

this is of course formally correct, due to the use of a polar coordinate base with mixed dimension (t, r, theta, phi) in the Schwarzschild case and the fact that in GR coordinates have no "physical meaning", unlike other regimes in physics. All GR observables are coordinate-independent. Therefore, this GR counter example is not what is relevant for my above discussion that is concerned with vectors (lists) and tensors, the components of which are to represent also physical quantities. Hence e.g. in Classical Mechanics (instead of GR), mixed dimensions cannot occur in vectors and tensors, e.g. like position and momentum vectors, or the inertia and angular momentum tensors of rigid bodies. This also holds in more advanced regimes in physics, e.g. with the stress-energy-momentum tensor T^{mu nu} or the (generalized) electromagnetic tensor F^{mu nu}.

In special relativity (->particle physics), the (non-gravitational) stress-energy tensor is a Noether current associated with spacetime translations and thus is componentwise conserved: d_nu T^{mu nu} = 0. In GR, however, when general coordinate systems are used, one needs to use the covariant derivative instead of the normal one to retain conservation of the (non-gravitational) stress-energy tensor. This then invokes the Christoffel symbols, of course.

As you sure know, GR can be recast in form of a local gauge field theory with "fields" related to the vierbeins. My above remark (in passing) was related to that fact, but it would lead too far discussing this further in the present context.

Fridger

PS: mathematically, in GR (i.e. curved spacetimes), the contravariant form of a tensor t: t^{mu nu} and the covariant form: t_{mu nu} tend to be entirely different and also transform differently, such the observable "square" of the tensor t^2 = t_{mu nu} t^{nu mu} has a well defined dimension, while the tensor itself may well have a mixed one.

Example: Schwarzshild metric tensor:
----------------------------------------------

Code: Select all

g_{mu nu} = diag(m(r),?n(r),?r^2,?r^2 * sin^2(theta)) ,
g^{mu nu} = diag(1/m(r), -1/n(r), -1/r^2, -1/(r^2 * sin^2(theta))),

with
m(r) = c^2 * (1 - r_s/ r); n(r) = c^2/m(r);   
r_s = 2 * G * M / c^2 (Schwarzschild radius)
M   = mass of gravitating object.

hence
g_{mu nu} g^{nu mu'} = diag(1,1,1,1)  dimensionless
g_{mu nu} g^{nu mu} = 4
g = c^2 * r^4 * sin^2(theta)  (determinant). 


In flat spacetimes the metric tensor is essentially "trivial" and that sort of thing cannot happen.

As to LaTeX, my guess is our Administrators have forgotten to switch it on after the recent update!

[Cham]

Fridger,

as you surely know, ANY tensor in ANY theory (not just GR), can have components with ANY dimensions. It simply depends on the coordinates basis used. Even in classical mechanics, or classical flat-space electrodynamics, the momentum vector for example can have components with mixed dimensions.

Dimensions of components are totally arbitrary. It is the tensor itself, which is independant of the coordinates basis, that should have some very definite dimensions :

[tex]\vec{\bold{p}} = p_{i} \bold{d}x^i[/tex]

While [tex]\vec{\bold{p}}[/tex] has some very definite dimensions, the three components [tex]p_{i}[/tex] can have any mixed dimensions, which is just a reflexion of the coordinates basis [tex]\bold{d}x^i[/tex]. The dimensions of any component are really totally arbitrary.

Administrators : please, turn back ON the LaTeX capabilities on the forum.

[selden]

MeshCenter displaces the displayed Mesh relative to the model's internal coordinate system.
The units that it uses for the displacement are the units used within the model, scaled by its Radius.

In an Addon intended for use with Celesita V1.6, it's more convenient to tell Celestia to use a mesh's coordinate system to begin with. Then you don't have to fight with MeshCenter, Radius values, invisible mesh components and other tricks to position the object correctly.

In other words, use the SSC directives NormalizeMesh and MeshScale.
See viewtopic.php?f=10&t=12520

[selden]

Administrators : please, turn back ON the LaTeX capabilities on the forum.

That's something Chris will have to do. It requires access to the host computer, which us phpbb admins don't have. Apparently it didn't get enabled when he upgraded phpbb from 3.01 to 3.06. I suspect a new version of the "Mod" will be needed.

[ajtribick]

Code update

Patch against SVN 4920. Units support is now enabled throughout the .ssc, .stc and .dsc files. Main exception is the property CloudSpeed, which is given in units of km/h so doesn't fit with the system.

Units are still prefix - it's more important to make sure the underlying units handling is working correctly, syntax is an easy change.

I haven't implemented mass units, probably this can wait until some functionality taking advantage of it can be incorporated into Celestia.

edited to make this post stand out a bit more

[t00fri]

Martin,

I think I understand what you are saying, but this is NOT really a "physical" approach. So let me rephrase first your above statements my way and then put the finger where I think we are differing.

Let (g_1, g_2, g_3) be an arbitrary linear independent set of coordinate basis vectors in 3d-Euclidean space. At this point, these basis vectors need neither be orthogonal, nor unit vectors. Hence, polar coordinates or any other 3d curvilinear coordinates are included in my considerations.

Then, an arbitrary vector V may be written as

V = V^i g_i,

in terms of the socalled contravariant components V^i of V.

A reciprocal basis (g^1, g^2, g^3) is then defined by the requirement

g^i . g_j = \delta^i_j (Kronecker delta)

The vector V then can also be expressed as

V = V_i g^i,

with V_i now being the covariant components of V.

Next we can define the metric tensor in terms of our general curvilinear basis as follows

g_{i j} = g_i . g_j = g_{j i}
g^{i j} = g^i . g^j = g^{j i}

and obviously from the above,

V^i = g^{i j} V_j etc.

as it should be...
Similarly, one gets for (2nd-order) tensor components

T^{i j} = g^{i k} T_k ^j = g^{i k} g^{i l} T_{k l}

++++++++++++++++++++++++
So far so good and I guess you will agree up to here?
++++++++++++++++++++++++

The point you are correctly making is that considering e.g. the covariant components of our vector V above,

V = V_i g^i,

that V_i can have arbitrary (mixed) dimensions, depending on the dimensions of the chosen coordinate basis vectors g^i.

++++++++++++++++++++++++

At this point, however, I insist that a physically sensible approach needs to come up with the proper dimensions of the components by means of a physical component decomposition Vhat_i of V, defined with respect to normalized basis vectors

ghat^i = g^i / sqrt(g^{i i}) (no summation)

as

V = Vhat_i ghat^i,

where the physical components Vhat_i = sqrt(g^{i i}) V_i will ALL have the same dimension as the vector v!
+++++++++++++++++++++++++

Similarly, the physical components of a second-order tensor field T can be obtained by using a normalized contravariant basis,

T = That_{i j} ghat^i \Otimes ghat^j,

where the physical tensor components with proper dimensions are analogously to the vector case

That_{i j} = T_{i j} / sqrt (g^{i i} g^{j j}) (no summation)

Again the physical components That_{i j} will ALL have the same dimension as the Tensor T!

and so on...

Throughout my (long) scientific life, I have always worked with these "physical" components (at least outside GR) ...

+++++++++++++++++++
It is really a pain without LaTeX!!!
+++++++++++++++++++

Fridger

[t00fri]

Addendum:

Martin,

I just found a paper that discusses physical components of vectors, tensors in arbitrary curvilinear coordinate systems in great detail, and agrees perfectly with my above approach...

Physical Components, Coordinate Components, and the Speed of Light
http://arxiv.org/pdf/gr-qc/0105071v1

Enjoy,
Fridger

[ajtribick]

Right, so let's call the thing that follows the word LongLat (or Planetocentric/Planetographic) a tuple and be done with it (Hence my choice of the name of the function in parser.cpp that retrieves this quantity and associated units)

One more vote for LaTeX here. (Actually my vote would be to serve the forums as application/xhtml+xml and output the formulae as MathML rather than low-quality raster images, but that would be mean for people who don't know better than to use antiquated browsers that aren't up to handling a standard dating back to 1999... mentioning no names here...)

[t00fri]

Right, so let's call the thing that follows the word LongLat (or Planetocentric/Planetographic) a tuple and be done with it

Sorry, Andrew,
if my discussion with Martin bothers you. But I think it has widened to become quite interesting BEYOND your specific needs in the context of Celestia's new unit conversion facility

Fridger

[ajtribick]

Hehe no bother at all... good to have some Physics & Astronomy related discussion on the shatters.net forums from time to time Though as you say it is getting somewhat off-topic for this thread.

[t00fri]

Code update. Patch against SVN 4920. Units support is now enabled throughout the .ssc, .stc and .dsc files. Main exception is the property CloudSpeed, which is given in units of km/h so doesn't fit with the system.

Units are still prefix - it's more important to make sure the underlying units handling is working correctly, syntax is an easy change.

I haven't implemented mass units, probably this can wait until some functionality taking advantage of it can be incorporated into Celestia.

Andrew,

which kind of tests of your code did you do already? Since it's plenty of new stuff, I expect it was a huge amount of tests ? . Did you make sure at least that with the solarsys.ssc etc default data the old input is precisely reproduced for all celestial objects?


Fridger

[ajtribick]

Regarding the processing of default units in catalogue files, I have done checks using HORIZONS data for the positions of objects in custom and elliptical orbits (Mercury from Earth, Pallas from Earth, Titan from Rhea). For stars I have checked that extrasolar.stc stars are located in the correct positions and distances as viewed from Earth, same for some examples of globular clusters and galaxies, including Omega Centauri, M 31, M 4, M 87. In these tests I have not found a case where the new code is breaking the existing data files.

For quantities with units, the code uses the same set of functions (getLength, getAngle, getTime, getLengthVector, getSphericalTuple). Testing length, angle and time scaling I created the following .ssc file

Code: Select all

# Object without specified units for reference
"TestDefault" "Alf Men"
{
    Radius 70000
    Texture "exo-class3.*"
   
    EllipticalOrbit {
        Period 1
        SemiMajorAxis 1
        MeanAnomaly 0
    }
}

# TestUnits1 should be located 10 degrees ahead of TestDefault
"TestUnits1" "Alf Men"
{
    Radius 70000
    Texture "exo-class3.*"
   
    EllipticalOrbit {
        Period<d> 365.25
        SemiMajorAxis<km> 149597870.7
        MeanAnomaly<deg> 10
    }
}

# TestUnits2 should be located 20 degrees ahead of TestDefault
"TestUnits2" "Alf Men"
{
    Radius 70000
    Texture "exo-class3.*"
   
    EllipticalOrbit {
        Period<d> 365.25
        SemiMajorAxis<m> 149597870700
        MeanAnomaly<arcsec> 72000
    }
}

# TestUnits3 should be located 30 degrees ahead of TestDefault
"TestUnits3" "Alf Men"
{
    Radius 70000
    Texture "exo-class3.*"
   
    EllipticalOrbit {
        Period<s> 31557600
        SemiMajorAxis<rE> 23454.780029915
        MeanAnomaly<mas> 108000000
    }
}

# TestUnits4 should be located 40 degrees ahead of TestDefault
"TestUnits4" "Alf Men"
{
    Radius 70000
    Texture "exo-class3.*"
   
    EllipticalOrbit {
        Period<min> 525960
        SemiMajorAxis<rJ> 2092.512039109
        MeanAnomaly<arcmin> 2400
    }
}

# TestUnits5 should be located 50 degrees ahead of TestDefault
"TestUnits5" "Alf Men"
{
    Radius 70000
    Texture "exo-class3.*"
   
    EllipticalOrbit {
        Period<h> 8766
        SemiMajorAxis<rS> 214.939469397
        MeanAnomaly<rad> 0.872664626
    }
}


# TestUnits6 should be located 60 degrees ahead of TestDefault
"TestUnits6" "Alf Men"
{
    Radius 70000
    Texture "exo-class3.*"
   
    EllipticalOrbit {
        Period<d> 365.25
        SemiMajorAxis<AU> 1
        MeanAnomaly<hRA> 4
    }
}


# TestUnits7 should be located 70 degrees ahead of TestDefault
"TestUnits7" "Alf Men"
{
    Radius 70000
    Texture "exo-class3.*"
   
    EllipticalOrbit {
        Period<y> 1
        SemiMajorAxis<ly> 0.000015813
        MeanAnomaly 70
    }
}


# cube of moons around TestDefault...

"TestVector1" "Alf Men/TestDefault"
{
    Radius 10
    Texture "asteroid.*"
   
    FixedPosition<m> [ -70000000 -70000000 -70000000 ]
}


"TestVector2" "Alf Men/TestDefault"
{
    Radius 10
    Texture "asteroid.*"
   
    FixedPosition<km> [ 70000 -70000 -70000 ]
}


"TestVector3" "Alf Men/TestDefault"
{
    Radius 10
    Texture "asteroid.*"
    FixedPosition [ -70000 70000 -70000 ]
}


"TestVector4" "Alf Men/TestDefault"
{
    Radius 10
    Texture "asteroid.*"
    FixedPosition {
        Planetographic<m deg> [ 45 -45 51243556.529821 ]
    }
}


"TestVector5" "Alf Men/TestDefault"
{
    Radius 10
    Texture "asteroid.*"
    FixedPosition {
        Planetographic<km hRA> [ -3 3 51243.556529821 ]
    }
}


"TestVector6" "Alf Men/TestDefault"
{
    Radius 10
    Texture "asteroid.*"
    FixedPosition {
        Planetographic [ 135 45 51243.556529821 ]
    }
}


"TestVector7" "Alf Men/TestDefault"
{
    Radius 10
    Texture "asteroid.*"
    FixedPosition {
        Planetographic<hRA> [ -9 3 51243.556529821 ]
    }
}


"TestVector8" "Alf Men/TestDefault"
{
    Radius 10
    Texture "asteroid.*"
    FixedPosition {
        Planetographic<m> [ 45 45 51243556.529821 ]
    }
}

This covers the parser for angle, length and time units, and cases for length vectors (FixedPosition) and spherical tuples (Planetographic). It does not test the length units parsecs, kiloparsecs or megaparsecs but I used .stc files to test the parsing of these.

[t00fri]

Thanks for the details, Andrew!

That sounds quite comforting, indeed...

Fridger

[duds26]

1. VALUE-scope
-- Applied to individual values
-- Units specified either before or after each individual value
2. PROPERTY-scope
-- Applied to all values of a given value-domain for a single property. (which may extend over 1 or more lines)
-- Units specified either before or after the Property Name
3. FILE-scope
-- Applied to all values of a given value-domain in a file.
-- Would require named-pairs comprising value-domain and unit specification at beginning of the file
4. CELESTIA-scope
-- Applied to alll values of a given value-domain in all files.
-- Would require named-pairs comprising value-domain and unit specification in celestia.cfg

Now who's making the parser's life difficult!?!
Now serious, that property scope isn't going to help.

Please don't add such a PROPERTY-scope thing.
If it, and it will someday, mess up stuff. Debugging will be very difficult, hard due to how addons are made.
When addon-writers are writing, they are writing files.
Don't forget their workflow.

In this respect, what if there are two conflicting PROPERTY-scope in different files?
Doing file-specific scope is going to be much more robust.
It may be more difficult to do, but it's going to be worth it.
The idea of either (pre/post)style was too much for the parser, I admit that.
But trying to do the PROPERTY-scope way is going to have major debugging issues for addon writers.
Please don't do 2 but 1, 3 and 4.

The file-scope thing would be excellent.
Remember, the parser is parsing files, not addons.


About values, with or without units.
There are actually two kind of stuff you can find in a file: values with units and values without.
This is something that should be taking into consideration.
Difference for all scopes. Celestia's default would be to not overwrite only fill in values without units.
As a default, already specified units shouldn't be overwritten.
But in some situations it would be desirable. (e.g. Artistic addons come to my mind, such as the solar system with the really big planets , collision danger .)
Something to say: overwrite everything, also units that are already specified, would be handy to have.
With something extra that's easy recognisable of what it does:

Code: Select all

Planet{

   Color [ 0.85<r overwrite> 0.85<g overwrite> 1.0<b overwrite> ]
   ...
}


Or

Code: Select all

Planet{

   Color [ 0.85<r> <overwrite> 0.85<g> <overwrite> 1.0<b> <overwrite> ]
   ...
}


Thus for all Planets declarated in that file.


Better flexible in the beginning than patchy all way through.

Why not let addon-makers specify addon parameters?
Something like this:
new addon unit parameter = m
phys quantity = length
calculateTokm = 0.001





I very much like the idea of unit-inheritance and it could be a big time saver for addon developers.
And please don't do the thing quoted under this:

The tricky part with this scheme is determining which sub-properties inherit which units of the parent. ie. Imagine the implications of the following:

Code: Select all
Atmosphere <rgb> <km> {
...
}

This may be a show-stopper for the idea of unit-inheritance, because it will require prior knowledge of the valid value-domains of each of the sub-properties. ie. Some are distances (km, m, etc), others are colors (rgb or ratio), yet others relate to degree of absorption/reflectance.

If the file scope isn't enough.
e.g. an addon maker wants to have one unit file for his whole addon with the specifications in.
Why not allow directories to play a role.
Starting with some definitions in a directory and some stuff in a sub-directory.
Then with some special keyword, the definitions could cover the things in the subdirectory' s.
e.g.: a subdirectory parameter: <subdirectory>
If two are conflicting, use Celestia's default units.
This allows also for hierarchical addons.
Since the parameters don't go up in the tree, but only overwrite down.
Reasonably easy for a parser to follow because it is actually parsing files, addon after addon.

[ajtribick]

Regarding this scope business, I'm only going to support per-property definitions. Something like

Code: Select all

EllipticalOrbit<km rad y>
{
    Period 0.3
    SemiMajorAxis 42402000
    MeanAnomaly 1
}

would require redesigning the system by which Celestia reads in files. Bear in mind that the tokenizer operates on files and converts them to hashes, the parser operates on these hashes. The code to create an elliptical orbit does not see the outer context, all it gets is a hash containing the following key-value pairs

("Period",0.3)
("SemiMajorAxis",42402000)
("MeanAnomaly",1)

The tokenizer has no idea what any of these properties represent, there is no way for it to associate years with Period, km with SemiMajorAxis, radians with MeanAnomaly. Associating all unit types with every property is not a good idea - even though this is allowed (unused unit types are ignored), it may perhaps be the case in future that we want to do things like, say, allowing angular radii to be specified by using an angle unit on the Radius property.

-------------------

I wonder who the 1 person who has downloaded the latest version of the code is...