[vtkusers] Rows versus columns bug in vtkTensorGlyph?

[Ashok Kumar]

Thanks.  Yes, if the documentation says that vtkTensorGlyph class is meant
for symmetric 3x3 tensors and rows of normalized eigenvectors scaled by
eigenvalues, then probably no change in code would be required.

Regards,

Ashok Kumar

P.S.  I mentioned in my first post that the matrix of scaled eigenvectors
was det(T)*S which is not really correct.  It will be the case only if all
three eigenvalues multiplied all the eigenvectors.  Sorry about that.


-----Original Message-----
From: Jose Paulo Moitinho de Almeida [mailto:moitinho at civil.ist.utl.pt]
Sent: Monday, May 12, 2003 6:04 AM
To: Ashok Kumar; vtkusers at public.kitware.com
Subject: Re: [vtkusers] Rows versus columns bug in vtkTensorGlyph?


On Friday 09 May 2003 21:29, Ashok Kumar wrote:
> As given in the the VTK File Formats section of the User guide, 3x3
tensors
> are entered as:
>
> T00 T01 T02
> T10 T11 T12
> T20 T21 T22
>
> But in the piece of code quoted below from vtkTensorGlyph.cxx, the rows of
> above matrix are being called columns.  The "m" matrix below is actually
> the transpose of the tensor being read.  Also the code following "//use
> tensor columns as eigenvectors" is actually using the "rows" of the tensor
> data.
>
> This doesn't cause problems if one is inputing symmetric tensors (as most
> physical 3x3 tensors of interest are symmetrical).  But with the option
> ExtractEigenvaluesOff, I started getting sheared looking cuboids when I
> actually gave the eigenvectors scaled by eigenvalues as the "columns" of
> the tensor.  But when I gave them as "rows" the problem vanished.
>

I "played a bit" with that code, to add the orientation stuff and I remember
that had some doubts regarding your question, but as I was working with
stresses I always had symmetry, so I never investigated it in depth.

The code is there for a long time, but perhaps it is time to set things
consistent. It is possible that some programs have been "adapted" to make it
work (i.e. the rows/columns have been changed until the right result was
obtained), so my suggestion is that is is better to change the man page and
the comments (when it is 100% sure that what is written is not consistent).

> Another point:  When ExtractEigenvalues is set On, then it makes sense to
> call the input data as the "tensor".  But when "ExtractEigenvalues" is
> turned "off", then the input matrix consisting of eigenvectors scaled by
> their eigenvalues arranged in columns, is not a tensor anymore.  It is
> actually the Determinant of the tensor multiplied by the similarity
> transformation (det(T)*S) required for diagonalization (I=STS^).  So may
be
> a different term than "tensor" will be more appropriate in that respect.
> May be the input should just be called a "matrix", which could be the
> actual tensor in one case and the matrix of eigenvectors multiplied by
> their eigenvalues in the second case (with ExtractEigenvaluesOff).
>

You are right, but what we are doing anyway is to represent something that
comes (or may come) from a tensor, so rather than changing everything I
would
suggest a more rigorous spelling in the man page and eventually a
clarification comment in the code. Instead of

"...If this boolean is false, then eigenvalues/eigenvectors are not
extracted,
and the columns of the tensor are taken as the eigenvectors (the norm of
column, always positive, is the eigenvalue). "

something like

"...If this boolean is false, then eigenvalues/eigenvectors are not
extracted,
and the columns of the input matrix are taken as the eigenvectors of the
tensor (the norm of column, always positive, is the eigenvalue). "


Regards

Ze Paulo