[Paraview] Stream Tracer in eigenvector field

Sat Aug 24 15:27:36 EDT 2013

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 [bloring at lbl.gov]
> *Sent:* Friday, August 23, 2013 4:31 PM
> *To:* Andy Bauer; pwhiteho
> *Cc:* paraview at paraview.org
> *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 <pwhiteho at masonlive.gmu.edu 
>> <mailto:pwhiteho at masonlive.gmu.edu>> 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
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.paraview.org/pipermail/paraview/attachments/20130824/d16a9811/attachment.htm>