[Paraview] [EXT] Re: More Customization of Python programmable Filter Panel

[Dennis Conklin]

All,

OK, I admit it – I’m greedy – I want it all.

As I have written these customized filters, one thing that I have realized is that memory utilization is not optimum for my setup.   I run on a single machine, not a cluster, so I am concerned about memory usage.

I have possibly a radical idea – I would like to have both ShallowCopy and DeepCopy in the same object.    When I am creating new Point or Cell variables, I must DeepCopy the input because when you Append to PointData or CellData after doing a ShallowCopy, the new variables are actually appended to the input.   And I agree with this approach, because otherwise we would have a case where we delete the Filter and the filter-created variables still remain (don’t ask me how I know this!).  However, we do not necessarily have to do it this way.  The PointData or CellData are, at their essence, an array of pointers to arrays of data.   I understand it may not be consistent with the current organization of the C++ objects, but it should be possible to have a CellData, for instance, in which some of the variables point to data arrays in the input (ShallowCopy) and some of the variables point to data arrays that only exist in the output (DeepCopy).   It may require some modification, but I think it has substantial advantages.

Let me give an extreme example to illustrate.  Imagine that I load an Exodus file and that I load 35 variables from the initial file on disk.   Now, I am going to run 10 filters, each of which will create at least 1 new variable.  So, in the present scheme, I must DeepCopy the input for each of these and I end up with 10 copies of the original variables (as if I had loaded 350 variables) plus multiple copies of the new variables created by the filters.   Putting aside the possibility of running Pass Arrays to eliminate some of these – that would reduce my flexibility for filters later in the tree to use variables from higher up the tree.  Ideally we would have a scheme where the variables loaded from the file could be available at every level of the tree (only requiring 1 copy of them in memory instead of 10 copies) and the only additional memory would be for the new calculated properties.   A further benefit could be realized if variables calculated throughout the tree also could be inherited by succeeding objects on the tree without copying them.

So, I am proposing that executing ShallowCopy of the input, would function as it does now, but it would allow a subsequent call to something like “AppendtoOutput” (or “DeepCopyAppend”) that would create a new variable array to store the new variable to be appended.    The CellData and PointData of the resulting output would point to the input copy of input variables and point to the newly allocated memory location of the newly created and appended variables.

Of course, sometimes we would really want to DeepCopy, like if we wanted to modify the Point coordinates and have both the original and modified geometry available, but we could choose to DeepCopy in that case and choose to ShallowCopy with DeepCopyAppend when that was appropriate.

So, best case is there is already a way to do this that I’m unaware of.

What do you think?

Dennis

From: Cory Quammen [mailto:cory.quammen at kitware.com]
Sent: Wednesday, September 30, 2015 3:05 PM
To: Dennis Conklin <dennis_conklin at goodyear.com>
Cc: Paraview (paraview at paraview.org) <paraview at paraview.org>
Subject: Re: [EXT] Re: [Paraview] More Customization of Python programmable Filter Panel

Hi Dennis,

The documentation that is available in the online help is generated at build time from the sources/filters/readers that ship with ParaView. The same is true for binary pluginsthat are built into a shared library.

Unfortunately documentation from purely XML plugins is not added to the online help. It could be, but it would take some effort to implement.

The good news is that you *can* create a shared library plugin from a pure XML filter. Just follow a couple steps in the ParaView Plugin HowTo, specifically, sections [1] and [2].

Cory

[1] http://www.paraview.org/Wiki/ParaView/Plugin_HowTo#Compiling_into_a_Shared_Library

[2] http://www.paraview.org/Wiki/ParaView/Plugin_HowTo#Adding_plugins_to_ParaView_source

On Tue, Sep 29, 2015 at 11:00 AM, Dennis Conklin <dennis_conklin at goodyear.com<mailto:dennis_conklin at goodyear.com>> wrote:
All,

It appears that the help or Documentation provided in the xml file is not accessible from Paraview.  I could not access it for the original files from the blog, or from mine.   Perhaps I just don’t understand the proper way to access it, but all I got with clicking on ? or hitting F1 was the Paraview manual.  Is there any way to have help text from my xml file accessible in Paraview?

Thanks

Dennis





--
Cory Quammen
R&D Engineer
Kitware, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview/attachments/20151006/74867aec/attachment.html>