Scripting Changes Progress

Progress

We developed a new Python module called simple. To load it, use

from paraview.simple import *

As discussed in Scripting Changes, this is a procedural interface. Here is a simple example (demo1 in the simple module):

ss = Sphere(Radius=2, ThetaResolution=32)
shr = Shrink(Input=ss)
cs = Cone()
app = AppendDatasets()
app.Input = [shr, cs]
Show(app)
Render()

Here is another example:

# Create the exodus reader and specify a file name
reader = ExodusIIReader(FileName=fname)
# Get the list of point arrays.
avail = reader.PointVariables.Available
print avail
# Select all arrays
reader.PointVariables = avail

# Turn on the visibility of the reader
Show(reader)
# Set representation to wireframe
SetDisplayProperties(Representation = "Wireframe")
# Black background is not pretty
SetViewProperties(Background = [0.4, 0.4, 0.6])
Render()
# Change the elevation of the camera. See VTK documentation of vtkCamera
# for camera parameters.
# NOTE: THIS WILL BE SIMPLER
GetActiveCamera().Elevation(45)
Render()
# Now that the reader executed, let's get some information about it's
# output.
pdi = reader[0].PointData
# This prints a list of all read point data arrays as well as their
# value ranges.
print 'Number of point arrays:', len(pdi)
for i in range(len(pdi)):
    ai = pdi[i]
    print "----------------"
    print "Array:", i, " ", ai.Name, ":"
    numComps = ai.GetNumberOfComponents()
    print "Number of components:", numComps
    for j in range(numComps):
        print "Range:", ai.Range(j)
# White is boring. Let's color the geometry using a variable.
# First create a lookup table. This object controls how scalar
# values are mapped to colors. See VTK documentation for
# details.
# Map min (0.00678) to blue, max (0.0288) to red
SetDisplayProperties(LookupTable = MakeBlueToRedLT(0.00678, 0.0288))
# Color by point array called Pres
SetDisplayProperties(ColorAttributeType = "POINT_DATA")
SetDisplayProperties(ColorArrayName = "Pres")
Render()

Issues

>> Selecting arrays in the Exodus reader
>> Too hard to just say load it all (a simple method?)
>> It would be helpful if all variables were in a single property, as is shown
>> in the GUI.
>
> What about name conflicts then (same variable name in point and
> element centered data)?

My inclination is to just select all of them by default and then provide and
"hidden" means to select one or the other.  I suspect that actually having
the same name for different variable types is pretty rare.

That said, I'm probably just whining, and we should put off any work until
someone of consequence complains.

> I could add a SelectAllVariables() method to
> the Exodus reader instead. Would that work?

That could work.  It would also be helpful to select all blocks sets or
maps.  Another (probably better) approach would be add a method to
ArrayListProperty to select everything in it.  That would automatically add
the feature for all readers and filters where multiple arrays can be
selected, right?

>> Selecting variables to color too hard (need to specify magic POINT_DATA
>> string).
>
> What would you recommend instead?

What if ColorAttributeType was set to some default like
POINT_DATA_THEN_CELL_DATA where it would first look for point data and then
cell data of the given name.  Again, I suspect it is fairly rare that the
two arrays exist (and there is some meaningful difference between them).  If
the user really wants one or the other, then they can change
ColorAttributeType to POINT_DATA or CELL_DATA.


>> Setting the lookup table needs work
>> Specifying range is awkward (you mention this)
>> Specifying lookup table needs work
>>
>> Why can't it have a default like GUI?
>> Perhaps we could move the predefined luts to SM so that Python can access
>> them easily.
>
> Sounds good. I'll talk to Utkarsh. Any recommendations about the range
> issue? Should it automatically adjust like the GUI?

Yes.  I think a good first pass is to make it behave just like the GUI,
since we have already gone through several iterations on how it should
behave (and continue to do so).  By default it should scale itself, but that
behavior can be overridden and reset.


>> The active source/view in the GUI still needs to by synchronized with the
>> active object in the Python interpreter.

> Yup. I wouldn't use the active_objects class. That functionality will
> move to server manager soon.

OK.  Should I be calling GetActiveSource() instead?

>> How do you turn on the color bar from Python?

Not easy to do. You have to create a
ScalarBarWidgetRepresentationProxy and a LookupTable. This should go
into the list of things to make easier. Do you have any
recommendations about what the Python API should look like? Should we
have one lookup table per array like in the GUI?