[vtkusers] vtkStreamTracer
Berk Geveci
berk.geveci at kitware.com
Tue Apr 27 08:52:11 EDT 2004
> However, I go back to my point in the earlier e-mail. The vtk library is
> representing an abstraction (stream tracer). This abstraction has
> information associated with it (a polyline (which is the path along which a
> particle would flow), the velocity of the particle at a number of points
> along that path etc.). You are saying that the vtkStreamTracer is merely a
> filter that pulls this information out of the overall flow field. What is
> this output then?
>
> Maybe vtkStreamTracer should be called vtkStreamTracerFilter and its output
> should be vtkStreamTracer - an object consisting of the polyline and
> associated data that makes up the abstraction that I understand to be a
> stream tracer (a little like the output from a vtkUnstructuredGridReader is
> a vtkUnstructuredGrid). I am probably way off the mark here and I admit I
> still do not have enough time to dedicate to thinking this out properly.
I agree. However, since it is impractical to have a different output
type for each filter, we are stuck with the basic data types. Therefore,
we have to associate information about the source and type of a data
object some other way. Currently, this is done by creating data arrays
with certain known names. This is obviously not the optimal solution.
The new pipeline architecture will contain "information objects" that
should remedy this. I don't want to go too much into the details of that
since it is still being designed and developed.
-Berk
> -----Original Message-----
> From: Berk Geveci [mailto:berk.geveci at kitware.com]
> Sent: 26 April 2004 18:11
> To: j.robinson at kepler-systems.com
> Subject: RE: [vtkusers] vtkStreamTracer
>
> Hi Jim,
>
> I am writing this off the mailing list because I wanted to explain
> myself. I am not trying to be arrogant or negative, I am just trying to
> give insight to some VTK design details that do not normally show up in
> documentation. In VTK, filter classes encapsulate an operation whereas
> data objects encapsulate the output properties and the results of an
> operation. For example, when a reader obtains information about the data
> in a file (hopefully without reading the whole data), it stores this
> information in the output. This is done in the UpdateInformation()
> stage. Since this is general enough, there are special variables in
> vtkDataObject to represent the information the reader reads. However, as
> the number of the "output properties" grow, it becomes harder to add
> variables to vtkDataObject to represent them. Brad Kind is working on a
> new pipeline architecture that will allow doing this much more easily.
> As far as I know, there are no filters in VTK that modify their instance
> variables as part of Execute(). There is a good reason behind this: if
> they did, this information could not be obtained by another filter
> downstream unless the programmer passed it himself. I guess in this
> situation, the right thing to do would be to write a "streamline
> information" filter that would take the output of the streamline filter
> and produce some sort of "human readable" output (this can in terms of
> setting ivars). Note the important difference: this filter will be
> setting ivars based on the input not the output.
> Let me know what you think.
>
> Cheers,
> -Berk
>
> PS: If it's OK with you, I'll post part of this to the mailing list. I
> think this information might be useful to others.
>
>
>
> On Mon, 2004-04-26 at 11:40, James C. Robinson wrote:
> > Dear Berk,
> > You say (I think):
> >
> > I don't understand why it is so difficult to get the array from the
> output.
> > It belongs to the output after all. It is not a "property" of the filter.
> >
> > I would suggest that the reason for termination is a property of the
> filter
> > (assuming by filter you are referring to the vtkStreamTracer). The output
> is
> > just a set of points etc. It is the vtkStreamTracer that gives this data
> > context. Otherwise, it is reason for termination of what? The answer is
> > "reason for termination of the stream tracer", so as a developer I want to
> > know why the generation of this object terminated. That is why I suggest
> > writing an interrogation method for this object. By reference to
> difficulty
> > is that, again as a user (and given the nature of the object-oriented
> > paradigm as I (perhaps mistakenly) understand it, is the entire behaviour
> of
> > the object should be encapsulated in the object. It is the generation of
> the
> > vtkStream Tracer that terminates and I should be able to ask that object
> > why?
> >
> > Just my two cents....
> >
> > Regards and thanks for the help.
> >
> > Jim
> >
> > ______________________
> >
> > James C. Robinson, PhD,
> > Chartered Engineer,
> > Kepler Simulation Systems Ltd.,
> > 42 Rivergrove,
> > Glanmire, Co. Cork,
> > Eire
> >
> > Tel: +353-21-4822028
> > Tel: +353-87-2393010
> > Fax: +353-21-4822028
> > E-mail: j.robinson at kepler-systems.com
> > ______________________
> >
> > -----Original Message-----
> > From: Berk Geveci [mailto:berklist at nycap.rr.com]
> > Sent: 26 April 2004 15:42
> > To: goodwin.lawlor at ucd.ie
> > Cc: j.robinson at kepler-systems.com; 'Jeff Lee'; 'Vtk Users'
> > Subject: RE: [vtkusers] vtkStreamTracer
> >
> > > Looking at the code, if the filter executes without seeds (no Source or
> > > StartPosition) then the ReasonForTermination array isn't allocated...
> > > The allocation is done in ::Integrate() rather than ::Execute() as Jim
> > > points out.
> > >
> > > 3 changes could be make to the class:
> > >
> > > 1. Instantiate and add the ReasonForTermination array to the output in
> > > ::Execute()
> >
> > I disagree. If the output is empty, there is no reason to create the
> > array. The application should check for this.
> >
> > > 2. Define the ReasonForTermination array in the class definition along
> > > with a vtkGetObjectMacro(ReasonForTermination, vtkIntArray) and allocate
> > > in the constructor
> >
> > I don't understand why it is so difficult to get the array from the
> > output. It belongs to the output after all. It is not a "property" of
> > the filter.
> >
> > > 3. Put a caveat in the documentation.
> >
> > This I agree with :-)
> >
> > By the way, a warning: I have been running into some strange behavior
> > when using RK 45. I didn't have time to track this yet. I would
> > appreciate any bug reports.
> >
> > Also, Jeff has quite a few bug fixes he hasn't committed yet. If you
> > guys pressure him, he might commit them :-) I have been trying...
> >
> > >
> > > Just my thoughts,
> > >
> > > Goodwin
> > > -----Original Message-----
> > > From: James C. Robinson [mailto:j.robinson at kepler-systems.com]
> > > Sent: 26 April 2004 13:19
> > > To: goodwin.lawlor at ucd.ie; Jeff Lee
> > > Cc: Vtk Users
> > > Subject: RE: [vtkusers] vtkStreamTracer
> > >
> > >
> > > Gents,
> > >
> > > Many thanks for the continued interest. Goodwin, I am using the adaptive
> > > integrator. I will try the other two types as an experiment, but a big
> > > part of going to the vtkStreamTracer is to avail of the adaptive
> > > integrator, so it may indicate whether or not it is the issue, but will
> > > not resolve it.
> > >
> > > Jeff, the issue of being able to generate a set of streamtracers from a
> > > rake doesn't negate the possibility of having a method to interrogate it
> > > directly. The argument could point the vtkSTreamTracer to the seed
> > > particle for which one wants to determine the reason for termination -
> > > e.g. vtkStreamTracer::ReasonForTermination(int particlenumber).
> > >
> > > Now, more information: I have discovered that the crash was due to the
> > > fact that
> > > vtkIntArray* ReasonForTermination =
> > > (vtkIntArray*)pStreamLine->GetOutput()->GetCellData()->GetArray("ReasonF
> > > orTe
> > > rmination") ;
> > >
> > > was returning a NULL pointer (sometimes) and I was trying (naughty me)
> > > to use that pointer without checking for this condition. However, the
> > > question is now, why is the pointer coming back as NULL. I assume that
> > > it is because some condition is not met before it gets to the
> > > vtkStreamTracer::Integrate method (which is where "ReasonForTermination"
> > > is set up). The seed particle points that cause trouble are generally in
> > > zones where the flow rate is very low. In other areas the two
> > > ReasonForTermination messages that I am getting are either the stream
> > > tracer "generated and unexpected value" or exceeded the "max propagation
> > > time".
> > >
> > > Again many thanks.
> > >
> > > Regards,
> > >
> > > Jim
> > >
> > > ______________________
> > >
> > > James C. Robinson, PhD,
> > > Chartered Engineer,
> > > Kepler Simulation Systems Ltd.,
> > > 42 Rivergrove,
> > > Glanmire, Co. Cork,
> > > Eire
> > >
> > > Tel: +353-21-4822028
> > > Tel: +353-87-2393010
> > > Fax: +353-21-4822028
> > > E-mail: j.robinson at kepler-systems.com
> > > ______________________
> > >
> > > -----Original Message-----
> > > From: Goodwin Lawlor [mailto:goodwin.lawlor at ucd.ie]
> > > Sent: 26 April 2004 12:00
> > > To: j.robinson at kepler-systems.com
> > > Subject: RE: [vtkusers] vtkStreamTracer
> > >
> > > Hi Jim,
> > >
> > > Which integrator are you using? If its vtkRungeKutta45 try using
> > > vtkRungeKutta4 and see if vtkStreamTracer still crashes where the flow
> > > rate is close to zero. If this solves the problem then it's the adaptive
> > > time step causing the problem...
> > >
> > > Regards,
> > >
> > > Goodwin
> > >
> > > Ps Actually try each of the integrators and see if they make a
> > > difference.
> > >
> > > -----Original Message-----
> > > From: James C. Robinson [mailto:j.robinson at kepler-systems.com]
> > > Sent: 26 April 2004 10:07
> > > To: goodwin.lawlor at ucd.ie; Jeff Lee
> > > Cc: Vtk Users
> > > Subject: RE: [vtkusers] vtkStreamTracer
> > >
> > >
> > > Gents,
> > >
> > > Thanks for your efforts. You have confirmed what I did myself is
> > > reasonable (Note, for all those harping on about the manual.... Where is
> > > the syntax for accessing that array explicitly stated in the manual? One
> > > would think that, since the reason for termination is a kernel part of
> > > the object, there would be a simple method to interrogate the object
> > > such as a vtkStreamTracer::ReasonForTermination()).
> > >
> > > You may have more contributions to make. I am finding two main problems
> > > (and a crash) with the vtkStreamTracer object:
> > > 1) The streamtube generated is not as long as the one attained using
> > > vtkStreamLine,
> > > 2) There is a crash when I use a source point where the flow rate is
> > > close to (or equal to) zero.
> > >
> > > Any ideas?
> > >
> > > Regards,
> > >
> > > Jim
> > > PS: Again, for those saying "give us some example code...". My programme
> > > is written as an MFC View/Doc with a very structured list of methods for
> > > newing, creating (setting up) and deleting all the objects that I use.
> > > It would be an arduous (though perhaps fruitful and worthwhile)
> > > procedure to extract all the objects and use them in the same way as I
> > > use them in the overall programme.
> > >
> > >
> > > ______________________
> > >
> > > James C. Robinson, PhD,
> > > Chartered Engineer,
> > > Kepler Simulation Systems Ltd.,
> > > 42 Rivergrove,
> > > Glanmire, Co. Cork,
> > > Eire
> > >
> > > Tel: +353-21-4822028
> > > Tel: +353-87-2393010
> > > Fax: +353-21-4822028
> > > E-mail: j.robinson at kepler-systems.com
> > > ______________________
> > >
> > > -----Original Message-----
> > > From: Goodwin Lawlor [mailto:goodwin.lawlor at ucd.ie]
> > > Sent: 25 April 2004 13:05
> > > To: vtkusers at vtk.org
> > > Cc: j.robinson at kepler-systems.com
> > > Subject: RE: [vtkusers] vtkStreamTracer
> > >
> > > Hi Jim
> > >
> > > Tracer->GetOutput()->GetCellData()->GetArray("ReasonForTermination");
> > >
> > > Hth,
> > >
> > > Goodwin
> > >
> > > Message: 3
> > > Reply-To: <j.robinson at kepler-systems.com>
> > > From: "James C. Robinson" <j.robinson at kepler-systems.com>
> > > To: "Vtk Users" <vtkusers at vtk.org>
> > > Date: Sat, 24 Apr 2004 20:50:06 +0100
> > > Subject: [vtkusers] vtkStreamTracer
> > >
> > > Dear All,
> > >
> > > In vtkStreamTracer:
> > >
> > > The reason for the termination is stored in a cell array named
> > > ReasonForTermination.
> > >
> > > How do I access it? (I am probably tired and slow at the moment).
> > >
> > > Thanks,
> > >
> > > Jim
> > >
> > > ______________________
> > >
> > > James C. Robinson, PhD,
> > > Chartered Engineer,
> > > Kepler Simulation Systems Ltd.,
> > > 42 Rivergrove,
> > > Glanmire, Co. Cork,
> > > Eire
> > >
> > > Tel: +353-21-4822028
> > > Tel: +353-87-2393010
> > > Fax: +353-21-4822028
> > > E-mail: j.robinson at kepler-systems.com
> > > ______________________
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > This is the private VTK discussion list.
> > > Please keep messages on-topic. Check the FAQ at:
> > <http://public.kitware.com/cgi-bin/vtkfaq>
> > > Follow this link to subscribe/unsubscribe:
> > > http://www.vtk.org/mailman/listinfo/vtkusers
> > --
> > Berk Geveci <berklist at nycap.rr.com>
>
>
>
>
More information about the vtkusers
mailing list