mailRe: BMRB diffusion tensor saveframes.


Others Months | Index by Date | Thread Index
>>   [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Header


Content

Posted by Edward d'Auvergne on November 27, 2009 - 10:03:
2009/11/25 Eldon Ulrich <elu@xxxxxxxxxxxxx>:
Hi,

The tag _Tensor_list.Geometric_shape as in your second example would work
well as long as the values in the enumerated list are mutually exclusive. It
would not be good to have one entry with a value of 'sphere' and another
with the value of 'isotropic'.

Would this work:

_Tensor_list.Geometric_shape (sphere, spheroid, oblate spheroid,
        prolate spheroid, rhombic)
_Tensor_list.Shape_homogeneity (isotropic, anisotropic)

Then 'anisotropic' groups everything except 'sphere' so that they can all be
selected in a single query. Of course 'sphere' and 'isotropic' are a bit
redundant. I suggest 'rhombic' instead of 'ellipsoid' as this seems to be
the more defining term used by many people.

It would seem that having both items like 'spheroid' and 'axial symmetry' as
enumerations to the same tag since they are equivalent by the definition
below would be confusing.

Hi,

If mutually exclusive, then the 'spheroid' value should be removed.
Also rhombicity is more a tensor asymmetry descriptor
(http://en.wikipedia.org/wiki/Rhombicity) rather than the geometric
one (ellipsoid is the name of the shape, see the description at the
start of http://en.wikipedia.org/wiki/Ellipsoid).  What about the
following:

_Tensor_list.Geometric_shape (sphere, oblate spheroid, prolate
spheroid, ellipsoid)
_Tensor_list.Directional_homogeneity (isotropic, anisotropic)
_Tensor_list.Directional_asymmetry (axially symmetric, rhombic)

I think something along these lines is more in line with the field of
tensors in mathematics and physics.  Note that the information here is
redundant.  The Geometric_shape encompasses all information already,
but the other two tags could nevertheless be useful.  The
_Tensor_list.Directional_asymmetry tag could be useful for alignment
tensors as the isotropic part of the tensor (the probability tensor)
has been removed.  Anyway, the terminologies can be clustered into two
groups:

Geometric descriptor (the nouns):  sphere, spheroid, oblate spheroid,
prolate spheroid, ellipsoid, scalene ellipsoid.

Directional symmetry/asymmetry descriptor (the adjectives):
isotropic, anisotropic, axially symmetric, oblate axially symmetric,
prolate axially symmetric, rhombic.

I think it would be best to keep the two separate.  Maybe some outside
opinions from others who use different tensors would be useful?


Regarding the inclusion of coordinates, I would tend to favor including all
of the coordinates for the model used. Although not required, it provides
context for users when they download the file for their own calculations.

Ok, I will look into doing this.  Which saveframe are atomic
coordinates stored in?

Cheers,

Edward



Cheers,
Eldon

Edward d'Auvergne wrote:

Hi,

Having 2 tags to serve this purpose is a good idea.  I would suggest
then, to match the physics rather than anything else:

_Tensor_list.Geometric_shape (sphere, spheroid, oblate spheroid,
prolate spheroid, ellipsoid).
_Tensor_list.Isotropy (isotropic, anisotropic, axial symmetry, oblate
axial symmetry, prolate axial symmetry, rhombic).

What do you think?  Here:

sphere = isotropic,
spheroid = axial symmetry,
oblate spheroid = oblate axial symmetry,
prolate spheroid = prolate axial symmetry,
ellipsoid = rhombic.

Or maybe this would be best:

_Tensor_list.Geometric_shape (sphere, spheroid, oblate spheroid,
prolate spheroid, ellipsoid, isotropic, axial symmetry, oblate axial
symmetry, prolate axial symmetry, rhombic)
_Tensor_list.Tensor_shape_homogeneity (isotropic, anisotropic)

If these are closed enumerations, then automatic parsing by downstream
programs will be possible.

Cheers,

Edward


2009/11/23 Eldon Ulrich <elu@xxxxxxxxxxxxx>:

Hi,

The usefulness of having isotropic and anisotropic as main headings is
that
it allows one to query for all anisotropic tensors without the need to
know
the full list of possible anisotropic shapes. This could be solved using
two
tags in at least two ways:

1) _Tensor_list.Tensor_shape (isotropic or anisotropic)
 _Tensor_list.Tensor_sub_shape (rhombic, sphere, oblate spheroid, etc.)

2. _Tensor_list.Tensor_shape (rhombic, sphere, oblate spheroid, etc.)
 _Tensor_list.Tensor_shape_homogeneity (isotropic, anisotropic)

Other suggestions?

Eldon

Edward d'Auvergne wrote:

2009/11/19 Eldon Ulrich <elu@xxxxxxxxxxxxx>:

Hi,

The suggestions for the tensor saveframe overall look fine. Instead of
including the shape of the tensor in the '.Details' tag or the
'.Speroid_type' tag, I would suggest creating a tag
'_Tensor_list.Tensor_shape' tag with enumerations like 'isotropic,'
'anisotropic,' 'rhombic,' 'anisotropic prolate,' and others.

I would suggest a different list as the term anisotropic includes the
rhombic tensors.  This is what I've done in relax to remove ambiguity
- I've used the pure names from geometry:

sphere: http://en.wikipedia.org/wiki/Sphere
spheroid:  http://en.wikipedia.org/wiki/Spheroid
oblate spheroid: http://en.wikipedia.org/wiki/Oblate_spheroid
prolate spheroid:  http://en.wikipedia.org/wiki/Prolate_spheroid
ellipsoid:  http://en.wikipedia.org/wiki/Ellipsoid

This is totally unambiguous and independent of the numerous
(inconsistent) definitions used for tensors throughout NMR.  Of course
the ellipsoid shape includes the spheroid and sphere, and the spheroid
includes the sphere.  But generally sphere = 3 equal eigenvalues,
spheroid = 2 equal eigenvalues, and ellipsoid = all 3 eigenvalues
different, therefore an ellipsoid with 3 equal eigenvalues is called a
sphere.  Note that the terms 'isotropic' and 'rhombic' are unambiguous
though.  I would strongly recommend against allowing 'anisotropic'
because some people think of this as a spheroid, while others think of
it as anything non-isotropic - the correct definition.


A full list of
tags for the saveframe is given below. I hope I have them all in there.
I
think having one general saveframe for tensors is fine and then in one
file
using separate tensor saveframes where appropriate would work. The list
of
tags in the loop has become quite long, but only those relevant to the
specific type of tensor need to be used.

This makes it quite powerful then!  I'll keep you informed if new tags
are needed to store all relevant information.


The tensor saveframe would go in supercategory 8 for structure and the
Shielding_tensor saveframe will be obsoleted.

Ok, I will code bmrblib accordingly.

Cheers,

Edward




Related Messages


Powered by MHonArc, Updated Fri Nov 27 18:40:30 2009