[vtk-developers] [EXTERNAL] inconsistencies in vtkExodusIIReader

[Andy Bauer]

Hi David,

Thanks for the help. To follow up for others that go down this path, the
following is the code that I used to load the element blocks and the sides
sets and then write them into a vtk file.
=============
from vtk import *

r = vtkExodusIIReader()
r.SetFileName("</path/to/file>")
r.GenerateGlobalNodeIdArrayOn()
r.GenerateGlobalElementIdArrayOn()
r.ExodusModelMetadataOn()

r.UpdateInformation()

nssa = r.GetNumberOfObjects(r.SIDE_SET)
for i in range(nssa):
  r.SetObjectStatus(r.SIDE_SET, i, 1)

def printblocks(mb, spacing):
  for i in range(mb.GetNumberOfBlocks()):
    if mb.GetBlock(i):
      print spacing, mb.GetBlock(i).GetClassName()
      if mb.GetBlock(i).IsA("vtkMultiBlockDataSet") == 1:
        printblocks(mb.GetBlock(i), spacing+"  ")
      if mb.GetBlock(i).IsA("vtkUnstructuredGrid") == 1:
        print 'ugrid has np ne ', mb.GetBlock(i).GetNumberOfPoints(),
mb.GetBlock(i).GetNumberOfCells()

r.Update()
mb = r.GetOutput()
printblocks(mb, "")

controller = vtkDummyController()
controller.SetGlobalController(controller)
w = vtkXMLPMultiBlockDataWriter()
w.SetController(vtkMultiProcessController.GetGlobalController())
w.SetFileName("/media/ssddrive/BUILDS/VTK/debug/testexo.vtm")
w.SetInputConnection(r.GetOutputPort())

w.Update()
============

I had to use the parallel XML multiblock data writer since not all blocks
in the output from the Exodus reader have grids in them and the serial XML
multiblock data writer doesn't like this.

Andy


On Mon, Oct 7, 2013 at 7:48 PM, David Thompson
<david.thompson at kitware.com>wrote:

> Hi Andy,
>
> > Thanks for the response but I'm still a bit confused. I have an ExodusII
> file with 4 side sets (file attached) but when I do, in vtkpython,
> r.GetNumberOfObjects(r.SIDE_SET) I get 4 but when I do
> r.GetNumberOfObjects(r.SIDE_SET_CONN) I get 0.
> > ... Is that correct then to use r.SIDE_SET instead of r.SIDE_SET_CONN
> here with r.SetObjectStatus()?
>
> I agree it is not self-consistent, but it is how the reader currently
> operates. The goal was to hide the existence of the *_CONN enums from users
> (because the context of the API call usually indicates whether the target
> is the connectivity array or results scalars defined over the connectivity
> array).
>
> The SetAllArrayStatus method should probably either
> 1. have the "*_CONN" variants in the switch statement removed, or
> 2. call SetObjectStatus(otyp,j,1) in addition to
> SetObjectArrayStatus(otyp,i,1) to guarantee that no block or set is not
> skipped (making it appear as if variables defined only on skipped objects
> were not loaded).
>
>         David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20131009/9586f3f0/attachment.html>