[visit-developers] Question on plots

Hank Childs hankchilds at yahoo.com
Wed May 27 09:24:52 EDT 2009


Hi Dave,

Sorry for not weighing in before, as I believe I implemented ChangesRequireRecalculation.

The bottom line on that method is whether or not we have to go to the engine.  For the time being, assume we are not in SR mode.  If you have what you need on the viewer and can make the change in a mapper, then ChangesRequireRecalculation should return false.  If you need to go to the engine, then it should return true.

(If you're in SR, then it is going to the engine, but there is no pipeline recalculation.)

This may not be what you want, but it is what's implemented right now.

-Hank

--- On Wed, 5/27/09, Dave Pugmire <pugmire at ornl.gov> wrote:

From: Dave Pugmire <pugmire at ornl.gov>
Subject: Re: [visit-developers] Question on plots
To: "VisIt Developers" <visit-developers at email.ornl.gov>
Date: Wednesday, May 27, 2009, 6:06 AM

Thanks Mark and Jeremy,

That clarifies some things on the meaning of 
::ChangesRequiresRecalculation().
I'll try and work it into that framework.  For my purposes, it seems 
ChangesRequiresRecalculation() returns true only if the streamlines change.
If the analysis needs to be redone, treat that as a re-render.

But Jeremy, you mention scalable rendering. Are there implications there?
The Poincare analysis will create new geometry from the streamlines. But 
it computes it strictly from the streamline geometry. Nothing else is 
needed. Is that sufficient to be considered a re-render? -I would assume 
so as I don't have to touch the database to produce it.

And, I was a little unclear in my use of the word filter previously.  
The poincare Filter inherits from the streamline filter, so there is 
actually only one "filter". Just two calculation steps in the filter.  
So, if I can keep the filter from being deleted, I might be in business.

thx.

-dave



Meredith, Jeremy S. wrote:
> ChangesRequiresRecalculation is kind of like the viewer/engine split when you're in geometry mode (i.e. non-scalable rendering).  Like Mark says, it's either a re-render, or a full re-execution.
>
> At some point in time, we used to have per-filter caching.  Or at least per-operator caching.  I.e. you do slice+contour plot, or slice+clip+pseudocolor plot, it will keep the results from the slice operator.  So if we re-enabled caching, that could come back.  (I'm sure that logic probably doesn't exist anymore, by the way, so "re-enable" is a bit of a misnomer.)
>
> But that may not solve your case -- in your case, it's a single RPC to the engine to get the whole poincare plot in the pipeline, and so the network manager doesn't have access at the right level.  So if we want to enable caching at the filter (no plot/operator) level, that's a different, and maybe harder -- problem.
>
> So right now, I think you're stuck.  But "Caching" is a topic for the 2.0 planning sessions (hint hint).....   :-)
>
> --
> Jeremy Meredith
> Oak Ridge National Laboratory
>
>
>   
>> -----Original Message-----
>> From: Dave Pugmire [mailto:pugmire at ornl.gov]
>> Sent: Tuesday, May 26, 2009 11:36 AM
>> To: VisIt Developers
>> Subject: [visit-developers] Question on plots
>>
>> Hi All,
>>
>> I have a basic question on plots.
>>
>> I'm trying to optimize the performance of the poincare plot by doing
>> the
>> minimal set of filter updates. There are two things that can change:
>> 1- The streamlines
>> 2- Analysis parameters of the streamlines
>>
>> There are two filters, streamline and poincare. I only want to execute
>> the minimal set.
>>
>> A few questions:
>> I have added the attribute method: ChangesRequireRecalculation().  This
>> returns true if either the streamline or the analysis needs to be
>> recalculated.
>> However, if I return true, it seems to delete the plot's filters and re
>> executes the entire plot. And so I lose my cached streamlines.
>>
>> If I return false, SetAtts() is called but no filters get executed.
>>
>>
>> Am I going about this the right way?
>> Is there another plot that is similar that I can follow?
>>
>> Thanks,
>> Dave
>>
>>     
>
>
>   



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://email.ornl.gov/pipermail/visit-developers/attachments/20090527/ae5692ba/attachment.html>


More information about the visit-developers mailing list