[Paraview] Some feedback please: Referencing invalid variable array names in Python Calculator/Find Data/Calculator

[RVA Developer]

On 6/7/12 7:24 AM, Utkarsh Ayachit wrote:

Lawrence,

Very good point. I'd definitely vote posting this on the mailing list,
as I'd like to get feed back from the users/developers before we
decide what would be the best approach for dealing with names. A patch
is always appreciated :).

For other bugs you mention, yes, mantis is indeed the best approach.
For non trivial issues, after reporting the bug, if might be
worthwhile to post on the mailing list to raise awareness. A bug
requiring some major work is more likely to be fixed if there more
people are affected by it -- but that's totally optional. We do parse
over the mantis bugs periodically.

Utkarsh

On Wed, Jun 6, 2012 at 6:27 PM, Lawrence Angrave <angrave at illinois.edu>
wrote:

Hi Utkarsh,

I'd be happy to post this/discuss this on the Paraview mailing list or
Paraview developer public  mailing lists
- if so, let me know which one is a better fit.

Feature suggestion:
 Define, document and implement a convention on how array names are
consistently mapped to script variables even when the original array name is
not a valid variable name.
This would affect the "Calculator" "FindData" and "Python Calculator"
features (possibly more).


As a concrete example, suppose you had a point array with the name "1.1
Phase: Total (s)#2" . You would be able to reference it in a script
calculation as
"_1_1_Phase__Total_s__2"


This could be implemented as an instance method eg "GetSanitizedName()" on
vtkArray
(that returns a variable name compliant name),
 or we leave vtk alone and implement it as a few static helper methods to
be used just before variables
are referenced in client languages / or calculators.

Anyway, What do you think?

 I'd be happy to help implement an initial first pass of this.
(It would be useful for RVA - our custom version of ParaView where we have
many geologic and oil based variables we read from other packages)

Best,
Lawrence.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.paraview.org/pipermail/paraview/attachments/20120607/bdbb2743/attachment.htm>