[vtkusers] vtk.vtkExodusIIReader: information in GetOutput()?

Nico Schlömer nico.schloemer at gmail.com
Sun Dec 12 11:11:36 EST 2010


Hi,

I was able to get it all together with

    reader.UpdateInformation()
    for k in xrange( reader.GetNumberOfPointResultArrays() ):
        arr_name = reader.GetPointResultArrayName( k )
        reader.SetPointResultArrayStatus( arr_name, 1 )

Then, after Update() has been called, the vtkUnstructuredGrid will
magically containt the array. Great!

> Note that because "_R" and "_Z" imply cylindrical coordinates, the two scalars
> in the exodus file will be combined into a 2-component vector by the reader and
> the result will be named either "x0" or "x0_" (I forget whether the trailing underscore
> is omitted or not).

Cylindrical coordinates, alright? Well, I got the data in there by
providing a complex valued array, but I guess that doesn't really
matter. The underscore is preserved by the way, so I'll just go ahead
and cut it off.

Thanks for the help!
--Nico



On Sun, Dec 12, 2010 at 3:30 AM, Thompson, David C <dcthomp at sandia.gov> wrote:
> Hi Nico,
>
>> Alright, so this
>> ...
>> gives me all vtkUnstructuredGrid in the vtkExodusIIReader output. Nice!
>> However, there's more data in the Exodus file I'd like to retrieve,
>> for example a data array for point data. In the ExodusII file, the
>> values are declared as "vals_nod_var1=..." and "name_nod_var =
>> "x0_R",  "x0_Z" ;", but those are certainly not contained in the block
>> hierarchy above.
>
> Each unstructured grid that is output may have point and cell
> arrays (I forget whether they are read by default or whether you
> must call SetObjectArrayStatus() to tell the reader you want them
> loaded). For the point variables "x0_R" and "x0_Z" in your example
> above, you would call
>
>  rdr = vtkExodusIIReader()
>  rdr.SetFileName( 'foo.exo' ) # or whatever
>  rdr.UpdateInformation() # this tells the reader to fetch metadata from the file
>  # Iterate over all the point arrays:
>  for i in range( rdr.GetNumberOfObjectArrays( rdr.NODAL ) ):
>    nname = rdr.GetObjectArrayName( rdr.NODAL, i )
>    print 'Array %d is "%s"' % (i,nname)
>    # if an array name matches, tell the reader we want to load it:
>    if nname == 'x0' or nname == 'x0_':
>      # 0 means "don't load", 1 means "load" the i-th nodal array
>      rdr.SetObjectArrayStatus( rdr.NODAL, i, 1 )
>  rdr.Update()
>  out = rdr.GetOutput()
>  # Assuming you have an element block, its point data will have
>  # the x0 array.
>  elem_blks = out.GetBlock( 0 )
>  elem_blk0 = elem_blks.GetBlock( 0 )
>  x0 = elem_blk0.GetPointData().GetArray( 'x0' )
>
> Note that because "_R" and "_Z" imply cylindrical coordinates, the two scalars
> in the exodus file will be combined into a 2-component vector by the reader and
> the result will be named either "x0" or "x0_" (I forget whether the trailing underscore
> is omitted or not).
>
> Because Exodus defines a single, global set of nodes for all element/face/edge
> blocks, any nodal variables you request will be present on every output block.
> However, because the cells in a block don't necessarily reference every point,
> the point coordinates and point data for each block are subsets of the global
> arrays. For instance, if you have 10 points defined in a mesh but the first
> element block contains a single quadrilateral (4 points), there will only be 4
> values in the 'x0' array attached to that element block's unstructured grid.
>
>    David
>
>
> On Mon, Dec 6, 2010 at 9:21 PM, David Thompson <dcthomp at sandia.gov> wrote:
>>> ... when reading an ExodusII file with
>>>  reader = vtk.vtkExodusIIReader()
>>>  reader.Update()
>>>  out = reader.GetOutput()
>>> 'out' would contain a whole lot of output the significance of which I
>>> don't quite understant;
>>
>> Hi Nico,
>>
>> The old vtkExodusReader used to output a single unstructured grid. This made
>> it difficult to handle the case when a variable was defined on some cells
>> (in one element block) but not on others (in a different element block). It
>> was also awkward to provide information about node sets and face sets. At
>> the time, there was also no concept of pedigree and global ID arrays in
>> vtkDataSetAttributes. This made writing Exodus datasets back out to a file
>> after some manipulation difficult since much of the information in the
>> original file could not be preserved. The vtkExodusModel and
>> vtkModelMetadata classes were attempts to encapsulate some of that
>> information for later access by a writer.
>>
>> The new vtkExodusIIReader outputs a multiblock dataset. Each multiblock
>> dataset may have an arbitrary number of blocks, where each block is a
>> arbitary dataset (an unstructured grid, an image, or even another multiblock
>> dataset). The new reader outputs a multiblock dataset where each of the
>> top-level blocks is itself a multiblock dataset holding unstructured grids
>> of a single type (element blocks, face blocks, edge blocks, element sets,
>> side sets, face sets, edge sets, node sets). When you "print out" you are
>> seeing all of the internal variables associated with the one toplevel
>> multiblock dataset and its children.
>>
>> This should print some more concise information about the blocks:
>> ====================== *snip* ======================
>> for i in range( out.GetNumberOfBlocks() ):
>>  print out.GetMetaData( i ).Get( vtkCompositeDataSet.NAME() )
>>  blk = out.GetBlock( i )
>>  for j in range( blk.GetNumberOfBlocks() ):
>>    print '  ' + blk.GetMetaData( j ).Get( vtkCompositeDataSet.NAME() )
>>
>> ====================== *snip* ======================
>> When the reader is told to read a block or set (only element blocks are read
>> by default), then an unstructured grid will be inserted into the appropriate
>> sub-block of the main reader's output.
>>
>>        Hope this helps,
>>        David
>>
>>
>>
>>
>
>
>



More information about the vtkusers mailing list