Paul,
Sorry to have given such an off target answer! Your idea about checking
the dot product as you progress makes sense. That's how VTK's a hyper
stream tracer handles the issue. I wonder if you can make use of it?
Bringing VTK classes into PV isn't too hard but parallelizing them can
be challenging.
Burlen
On 08/24/2013 12:27 PM, Burlen Loring wrote:
in the case of the glyphing algorithm it's the surface normals of the
transformed glyph that have the relation to the sign determinant of
the transform matrix. this transformation matrix is constructed from
the eigenvectors directly. at any rate, good luck.
On 08/23/2013 06:35 PM, pwhiteho wrote:
Burlen, you had me hoping, but alas ... there is no direct
correlation between the determinant ( a.k.a. the 3rd tensor invariant
) and the orientation of the computed eigenvectors. You did get me
thinking there may be other possibilities. I'm sure I can use the dot
product in a marching cube scheme to enforce a consistent orientation
progression and generate a "vector" field ParaView will handle well.
It'll just have to be robust enough to handle a true change near some
sharp topological feature.
Thanks,
Paul
------------------------------------------------------------------------
*From:* Burlen Loring [[email protected]]
*Sent:* Friday, August 23, 2013 4:31 PM
*To:* Andy Bauer; pwhiteho
*Cc:* [email protected]
*Subject:* Re: [Paraview] Stream Tracer in eigenvector field
Eigenvectors are unique up to a constantso if you took any
eigenvector and multiplied it by -1 it's still an eigenvector. You
could see it in the definition,
M x=\lambda x
eigenvector x appears in both sides of the eqn.
I had a similar problem with tensor glyphs in ParaView. In that case
I was able to solve by looking at the sign of the determinant of the
transformation matrix (see bug report, patch and mail list posts
below). I wonder if you could adapt/build on this solution there to
solve your issue here?
http://vtk.org/Bug/view.php?id=12179
http://vtk.1045678.n5.nabble.com/tensor-glyph-inward-pointing-surface-normals-td4388361.html
Burlen
On 08/23/2013 01:10 PM, Andy Bauer wrote:
Hi Paul,
Apologies as my math is a bit rusty but isn't the sign of the
eigenvector related to the sign of its corresponding eigenvalue? In
that case if you make sure that all of the eigenvalues are positive
then all of their corresponding eigenvectors should be aligned
properly. If that's the case and you have access to the eigenvalues
of the eigenvectors you could use the calculator or python
calculator to properly orient the eigenvectors.
In any case, if you can come up with an algorithm that properly
orients the eigenvectors you should be able to do that in the python
calculator or calculator filters. If not, then things could get a
bit hairy as far as computationally figuring out which is the
"proper" direction your eigenvalues should have.
Regards,
Andy
On Fri, Aug 23, 2013 at 3:38 PM, pwhiteho
<[email protected] <mailto:[email protected]>> wrote:
The term "eigenvector", used to describe the principal
directions of a tensor, is a bit of a misnomer since it's not a
"vector" as interpreted by the Stream Tracer filter - it's more
accurately bi-directional like tension/compression and could be
termed "eigenaxis/eigenaxes". When interpreted as a vector,
there is an inherent sign ambiguity in each eigenvector - the
sign is indeterminate and one is free to choose + or -, and that
is exactly what Mathematica does ( likely true for other
routines also ).
I've been using Mathematica to prototype computations for the
investigation of tensor topology which I then visualize in
ParaView. Eigen-decomposition of a tensor field at each grid
point returns an orthonormal set of eigenvectors, uncorrelated
with any neighbors. Taken separately, each eigenvector field
exhibits large regions of smoothly varying orientation, but
there are systematic and random reversals of orientation that
confound the Stream Tracer filter, sending streamlines wandering
around the field. What is needed is a true tangent curve (
tensor line ) integrator that would avoid "doubling back" as the
"streamline" propagates, similar to the scheme of Weinstein, et.
al., ( IEEE VIS'99 ) which computes the dot product of the
incoming propagation vector with the eigenvector; and if near
-1, negate the outgoing propagation vector. This can also be
fancied-up to accommodate noisy initial tensor data as in Weinstein.
I think I would be taking on too much at this point in learning
to write my own filter so have been exploring ways to
pre-process the eigenvector fields before visualizing in
Paraview, but I ask:
1. Have I missed something in existing filters that would handle
this?
2. Can the existing Stream Tracer be modified?
3. Does the eigenvector routine in ParaView yield the same sign
ambiguity among uncorrelated computations?
Thanks,
Paul W
_______________________________________________
Powered by www.kitware.com <http://www.kitware.com>
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
<http://www.kitware.com/opensource/opensource.html>
Please keep messages on-topic and check the ParaView Wiki at:
http://paraview.org/Wiki/ParaView
<http://paraview.org/Wiki/ParaView>
Follow this link to subscribe/unsubscribe:
http://www.paraview.org/mailman/listinfo/paraview
_______________________________________________
Powered bywww.kitware.com
Visit other Kitware open-source projects
athttp://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the ParaView Wiki
at:http://paraview.org/Wiki/ParaView
Follow this link to subscribe/unsubscribe:
http://www.paraview.org/mailman/listinfo/paraview
_______________________________________________
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the ParaView Wiki at:
http://paraview.org/Wiki/ParaView
Follow this link to subscribe/unsubscribe:
http://www.paraview.org/mailman/listinfo/paraview
