Re: [Paraview] [EXTERNAL] Re: Make animation from steady state result

[Andrew Parker via ParaView]

Cory,

As a follow up.  Can I ask if it would be possible to do all that is
suggested on Scott's page:
https://www.paraview.org/Wiki/Advanced_Tips_and_Tricks#
Animating_a_static_vector_field

Along with all of your additional steps below from your last post (be great
to add these to Scott's page), entirely in pvpython or pvbatch?  I make use
of the anaconda version from here: https://anaconda.org/conda-forge/paraview

Would it be possible do you think to script all of this? I have not tired
it yet I should add just checking for show stoppers before I begin.
Thanks,
Andy

On 19 January 2018 at 13:18, Cory Quammen <cory.quam...@kitware.com> wrote:

> Andrew,
>
> Responses inlined below:
>
> On Fri, Jan 19, 2018 at 6:27 AM, Andrew Parker via ParaView
> <paraview@paraview.org> wrote:
> > Dear all,
> >
> > Sorry to post onto an old thread. I have been reading this thread and the
> > related write up here:
> > https://www.paraview.org/Wiki/Advanced_Tips_and_Tricks#
> Animating_a_static_vector_field
> >
> > This thread (and the tips and tricks post) is really close to what I
> want to
> > do, but I have a few follow-up questions.  I too have a steady-state
> > solution field. I want to trace particles from the inlet of my domain to
> the
> > exit, following the steady-state velocity field, and report for each
> > particle the temperature-time history (or any other scalar from my
> > simulation) that the particle sees.  In additional and crucially, the
> time
> > the particle has within the domain: a residence time.  The residence time
> > would be the maximum value or IntegrationTime each particle attains
> before
> > it leaves the domain.
> >
> > I see that if I follow the notes I can plot (using Glyphs) the
> temperature
> > as it varies across my domain as the particles are animated down the
> > streamlines: this is working.  What I do not seem to be able to find
> > however, is the IntegrationTime.  It appears as point-field data after
> the
> > streamlines are created, but vanishes after the contour filter is
> applied.
> > I guess the contour filter is computing a singular value for all values
> of
> > the IntegrationTime from T=0 to T=N with a specific level of granularity.
>
> By default, the Contour filter does not copy the scalar field used to
> determine the contour surface since it will always be the same value.
> You can tell it to copy the scalar field by enabling the Compute
> Scalars option.
>
> > However, I can't seem to extract the specific value of IntegrationTime
> (the
> > contour value) when I stop the simulation at any given point.  Do you
> know
> > how to do that?  The "time" scale in the VCR window always goes from 0->1
> > not from 0->(max value of IntegrationTime in seconds).  Can the actual
> value
> > of time be backed out or animated? If so how do I do that, or am I
> applying
> > the Contour filter wrongly: as per the post, I am only using the default
> > values in the Counter filter panel.
>
> Instead of using the Sequence animation mode, use Real Time. Then, set
> the Start Time to the minimum IntegrationTime value and End Time to
> the maximum IntegrationTime value. You can see these listed either in
> the Information tab of the StreamTracer filter in the Pipeline Browser
> or under the Contour filter's Property tab under the Isosurfaces
> section (Value Range). To show the current time in the render view,
> use an Annotate Time source, available in the Sources menu.
>
> > Finally, and importantly for me, while the Glyphs move across the screen
> > following the streamlines, and render via the temperature field, how to I
> > actually extract information from this pseudo time series to perform
> > analysis?  For example, the min and max temperature seen by a particle
> as it
> > moved across the streamline for instance?  I'm actually hoping to plot
> > offline (as a function of IntegrationTime) the min and max temperature
> > obtained for each particle: I can then take the min and max of that set
> for
> > the quickest and slowest particles.
>
> You can run the Connectivity filter on the StreamTracer output to
> assign a unique value to each streamline. This unique value will be
> called RegionId. It starts at 0 and ends at the number of stream lines
> minus 1. Selecting each stream line can be done with the Threshold
> filter in ParaView using the RegionId as the threshold array, then you
> can see the min/max of your temperature and IntegrationTime variables
> in the Information tab. Iterating over all stream lines and saving the
> min/max of the different scalar fields is possible using Par

Re: [Paraview] [EXTERNAL] Re: Make animation from steady state result

[Andrew Parker]

Thank you very much for these comments.  I'll give them a go and follow up
if need be.
Thanks,
Andy

On 19 January 2018 at 13:18, Cory Quammen <cory.quam...@kitware.com> wrote:

> Andrew,
>
> Responses inlined below:
>
> On Fri, Jan 19, 2018 at 6:27 AM, Andrew Parker via ParaView
> <paraview@paraview.org> wrote:
> > Dear all,
> >
> > Sorry to post onto an old thread. I have been reading this thread and the
> > related write up here:
> > https://www.paraview.org/Wiki/Advanced_Tips_and_Tricks#
> Animating_a_static_vector_field
> >
> > This thread (and the tips and tricks post) is really close to what I
> want to
> > do, but I have a few follow-up questions.  I too have a steady-state
> > solution field. I want to trace particles from the inlet of my domain to
> the
> > exit, following the steady-state velocity field, and report for each
> > particle the temperature-time history (or any other scalar from my
> > simulation) that the particle sees.  In additional and crucially, the
> time
> > the particle has within the domain: a residence time.  The residence time
> > would be the maximum value or IntegrationTime each particle attains
> before
> > it leaves the domain.
> >
> > I see that if I follow the notes I can plot (using Glyphs) the
> temperature
> > as it varies across my domain as the particles are animated down the
> > streamlines: this is working.  What I do not seem to be able to find
> > however, is the IntegrationTime.  It appears as point-field data after
> the
> > streamlines are created, but vanishes after the contour filter is
> applied.
> > I guess the contour filter is computing a singular value for all values
> of
> > the IntegrationTime from T=0 to T=N with a specific level of granularity.
>
> By default, the Contour filter does not copy the scalar field used to
> determine the contour surface since it will always be the same value.
> You can tell it to copy the scalar field by enabling the Compute
> Scalars option.
>
> > However, I can't seem to extract the specific value of IntegrationTime
> (the
> > contour value) when I stop the simulation at any given point.  Do you
> know
> > how to do that?  The "time" scale in the VCR window always goes from 0->1
> > not from 0->(max value of IntegrationTime in seconds).  Can the actual
> value
> > of time be backed out or animated? If so how do I do that, or am I
> applying
> > the Contour filter wrongly: as per the post, I am only using the default
> > values in the Counter filter panel.
>
> Instead of using the Sequence animation mode, use Real Time. Then, set
> the Start Time to the minimum IntegrationTime value and End Time to
> the maximum IntegrationTime value. You can see these listed either in
> the Information tab of the StreamTracer filter in the Pipeline Browser
> or under the Contour filter's Property tab under the Isosurfaces
> section (Value Range). To show the current time in the render view,
> use an Annotate Time source, available in the Sources menu.
>
> > Finally, and importantly for me, while the Glyphs move across the screen
> > following the streamlines, and render via the temperature field, how to I
> > actually extract information from this pseudo time series to perform
> > analysis?  For example, the min and max temperature seen by a particle
> as it
> > moved across the streamline for instance?  I'm actually hoping to plot
> > offline (as a function of IntegrationTime) the min and max temperature
> > obtained for each particle: I can then take the min and max of that set
> for
> > the quickest and slowest particles.
>
> You can run the Connectivity filter on the StreamTracer output to
> assign a unique value to each streamline. This unique value will be
> called RegionId. It starts at 0 and ends at the number of stream lines
> minus 1. Selecting each stream line can be done with the Threshold
> filter in ParaView using the RegionId as the threshold array, then you
> can see the min/max of your temperature and IntegrationTime variables
> in the Information tab. Iterating over all stream lines and saving the
> min/max of the different scalar fields is possible using ParaView's
> Python scripting capabilities. However, you may find it faster to
> export the data to a tool with which you are more familiar.
>
> To do that, I would suggest saving the Connectivity filter output to a
> .csv file. The CSV file will contain all the scalar fields in
> different columns, including the aforementioned RegionId field. Simply
> filter on the RegionId field using your favorite software/plotting
> tool to find the min and m

Re: [Paraview] [EXTERNAL] Re: Make animation from steady state result

[Andrew Parker via ParaView]

Dear all,

Sorry to post onto an old thread. I have been reading this thread and the
related write up here:
https://www.paraview.org/Wiki/Advanced_Tips_and_Tricks#Animating_a_static_vector_field

This thread (and the tips and tricks post) is really close to what I want
to do, but I have a few follow-up questions.  I too have a steady-state
solution field. I want to trace particles from the inlet of my domain to
the exit, following the steady-state velocity field, and report for each
particle the temperature-time history (or any other scalar from my
simulation) that the particle sees.  In additional and crucially, the time
the particle has within the domain: a residence time.  The residence time
would be the maximum value or IntegrationTime each particle attains before
it leaves the domain.

I see that if I follow the notes I can plot (using Glyphs) the temperature
as it varies across my domain as the particles are animated down the
streamlines: this is working.  What I do not seem to be able to find
however, is the IntegrationTime.  It appears as point-field data after the
streamlines are created, but vanishes after the contour filter is applied.
I guess the contour filter is computing a singular value for all values of
the IntegrationTime from T=0 to T=N with a specific level of granularity.
However, I can't seem to extract the specific value of IntegrationTime (the
contour value) when I stop the simulation at any given point.  Do you know
how to do that?  The "time" scale in the VCR window always goes from 0->1
not from 0->(max value of IntegrationTime in seconds).  Can the actual
value of time be backed out or animated? If so how do I do that, or am I
applying the Contour filter wrongly: as per the post, I am only using the
default values in the Counter filter panel.

Finally, and importantly for me, while the Glyphs move across the screen
following the streamlines, and render via the temperature field, how to I
actually extract information from this pseudo time series to perform
analysis?  For example, the min and max temperature seen by a particle as
it moved across the streamline for instance?  I'm actually hoping to plot
offline (as a function of IntegrationTime) the min and max temperature
obtained for each particle: I can then take the min and max of that set for
the quickest and slowest particles.

Using the latest stock version of paraview.

Cheers,
Andy

On 6 June 2014 at 20:30, Scott, W Alan  wrote:

> Ken and Jean, excellent idea!  I liked it so much that I wrote it up in
> the SNL ParaView tutorials, tips and tricks page.  It is located here:
> http://www.paraview.org/Wiki/Advanced_Tips_and_Tricks
>
>
>
> Alan
>
>
>
> *From:* ParaView [mailto:paraview-boun...@paraview.org] *On Behalf Of 
> *Moreland,
> Kenneth
> *Sent:* Friday, June 06, 2014 11:43 AM
> *To:* David E DeMarle; minh hien
> *Cc:* paraview@paraview.org
>
> *Subject:* [EXTERNAL] Re: [Paraview] Make animation from steady state
> result
>
>
>
> Here's a more expanded list of steps outlining the solution David gave in
> case you are not very familiar with the contour filter and animation
> controls in ParaView.
>
>
>
> 1. Create the streamlines as you normally would.
>
>
>
> 2. Add a Contour filter to the streamline (third toolbar, second button
> from the left).
>
> 2.a. Change the Contour By property to IntegrationTime.
>
> 2.b. Press Apply.
>
> This little trick will create a point on each streamline at a particular
> time in the particle advection simulation that created the streamlines.
>
>
>
> 3. Open the Animation View (View -> Animation View)
>
> 3.a. On the bottom row, select the contour filter in the first chooser box
> and Isosurfaces in the second chooser box. Then hit the blue plus button at
> the left.
>
> 3.b. Make sure Mode is set to Sequence and change No. Frames to 100.
>
> 3.c. Hit the play button in the VCR controls (green triangle in the top
> toolbar). You will see the dots animate over the streamlines.
>
> 3.d. You can adjust the speed of the animation by changing the No. Frames.
>
>
>
> 4. If you want to see glyphs instead of dots, just add the glyph filter to
> the output of the contour filter.
>
>
>
> BTW, props to Jean Favre for originally posting this solution to the
> ParaView mailing list (http://markmail.org/message/ms57z7jjubh2pzjg).
>
>
>
> -Ken
>
>
>
> *From: *David E DeMarle 
> *Date: *Thursday, June 5, 2014 8:07 AM
> *To: *minh hien 
> *Cc: *"paraview@paraview.org" 
> *Subject: *[EXTERNAL] Re: [Paraview] Make animation from steady state
> result
>
>
>
> Make an isocontour of the streamlines' integrationTime variable.
>
> Then in animation view, make a track for the isocontour value.
>
>
> David E DeMarle
> Kitware, Inc.
> R Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4909 <(518)%20881-4909>
>
>
>
> On Thu, Jun 5, 2014 at 9:52 AM, minh hien  wrote:
>
> Hi 

[Paraview] Paraview bug found in pvtu files containing polyhedrons

[Andrew Parker via ParaView]

Dear All,

I have recently been having problems reading pvtu files in paraview when those 
files contain arbitrary polyhedrons: this is from the output of a large scale 
code that runs in parallel via mpi.  To show the problem, I have written a very 
small sample code, attached, that runs in serial but reproduces the salient 
issues experienced by my larger code when run in parallel.  It is clear, via 
the toggling a boolean, that the problem happens when vtk_polyhedrons types are 
used.  There is a short description at the top of the bug.cxx file, followed by 
instructions.  I use stock versions of paraview here, although self compiled 
ones show no difference.

In short compile the code, run it, and open the pvtu file in paraview.  You 
should see 4 cells.
Switch the “bug” bool to true, recompile, re-run it, and reopen the pvtu file.  
The screen will be blank.  

The only difference is that cells are added to the unstructured grid explicitly 
as vtk_polyhedrons using a face-stream, rather than as hexs.  I cannot do this 
in the real code!  The rest of the code is just there to produce the “serial” 
mesh, and threshold this mesh to produce two “parallel-partition” meshes.  I 
use the new ghost type framework as this is consistent with the real code, and 
this runs and compiles on OS X and gcc.  Likewise it has been build against vtk 
6.3 and the bug manifests itself in paraview 4.4 and 5.0.  Visit 2.10 does not 
have this bug and can correctly open the pvtu containing polyhedrons: this is 
my current workaround.

Can any of the developers shed light on this?  Is a fix known, if so when will 
it be released?  Do others have this problem [1, 2, 3] outside of those long 
reported? Does anyone else have workarounds?

Any help really appreciated, 
Andy

[1] http://public.kitware.com/pipermail/vtkusers/2015-May/090835.html
[2] https://cmake.org/pipermail/paraview/2012-October/026456.html
[3] https://cmake.org/pipermail/paraview/2015-January/032950.html



bug.cxx
Description: Binary data
cmake_minimum_required(VERSION 2.8)

PROJECT(ptvuBug)

set(CMAKE_COLOR_MAKEFILE ON)
   


set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wextra -Wall -Wconversion 
-Wuninitialized -std=c++11 -Wno-sign-conversion -Werror=ignored-qualifiers 
-Werror=unused-local-typedefs -Werror=return-type -Werror=cast-qual")

find_package(VTK REQUIRED)
include(${VTK_USE_FILE})

ADD_EXECUTABLE(bug bug.cxx)
TARGET_LINK_LIBRARIES(bug ${VTK_LIBRARIES})
 


___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the ParaView Wiki at: 
http://paraview.org/Wiki/ParaView

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

[Paraview] Potential bug in vtkPolygon normal and area calculations

[Andrew Parker]

Dear all,

This is driving me round the bend. When I have a meshing coming from a
rectilinear source, I get NANs from my normal and face area calculations.
 When all other input meshes are used, i.e. unstructured, the results are
correct. To test this I've written the following test code which makes a
single cell mesh and produces the NANs.  I then demonstrate that by using
the transform classes, with zero rotation, I can then extract the same mesh
back as a structured grid, and the errors disappear.  I can also apply a
non-zero rotation and the errors disappear too.

Note I apply a rotation, zero or otherwise, because my hypothesis having
stepped through 6.1 in the debugger, is that the vtk_pixel cell type (axis
aligned) coming from the rectilinear grid does not play well with the
normal calculation.  But I can't find the bug, only that all entries of the
normal are zero and the rest of the function fails.

Clearly, and more likely, is that I could also not be using the classes
correctly, and if so please let me know??  Hope somebody can find the bug,
I've got nowhere on this after a day of looking.  Again, anything non-axis
aligned and or non vtk_pixel would appear to work as expected.

Help appreciated,

Cheers again,
Andy
cmake_minimum_required(VERSION 2.8)
PROJECT(weird)

set(CMAKE_COLOR_MAKEFILE ON)

set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} -Wextra -Wall -Wconversion -pedantic 
-Wuninitialized -std=c++11 -Wno-extra-semi)
 
FIND_PACKAGE(VTK REQUIRED NO_MODULE)
INCLUDE(${VTK_USE_FILE})

find_package(Qt5Widgets REQUIRED)

set(SOURCES main.cxx)

ADD_EXECUTABLE(weird ${SOURCES})

TARGET_LINK_LIBRARIES(weird ${VTK_LIBRARIES})


#include vtkRectilinearGrid.h
#include vtkXMLRectilinearGridWriter.h
#include vtkXMLStructuredGridWriter.h
#include vtkDoubleArray.h
#include vtkSmartPointer.h
#include vtkCell.h
#include vtkPolygon.h
#include vtkPoints.h
#include vtkIdTypeArray.h
#include vtkTransform.h
#include vtkTransformFilter.h
#include vtkPointSet.h
#include vtkStructuredGrid.h
//
#include array

int main()
{
  vtkSmartPointervtkRectilinearGridrg3D = vtkSmartPointervtkRectilinearGrid::New();

  vtkSmartPointervtkDoubleArray xdata = vtkSmartPointervtkDoubleArray::New();
  vtkSmartPointervtkDoubleArray ydata = vtkSmartPointervtkDoubleArray::New();
  vtkSmartPointervtkDoubleArray zdata = vtkSmartPointervtkDoubleArray::New();
  
  const double deltaX = 0.01;

  xdata-InsertNextValue(0.0);
  xdata-InsertNextValue(deltaX);

  ydata-InsertNextValue(0.0);
  ydata-InsertNextValue(deltaX);

  zdata-InsertNextValue(0.0);
  zdata-InsertNextValue(deltaX);

  rg3D-SetDimensions(2,2,2);
  rg3D-SetXCoordinates(xdata);
  rg3D-SetYCoordinates(ydata);
  rg3D-SetZCoordinates(zdata);
  
  vtkSmartPointervtkXMLRectilinearGridWriter writer =
vtkSmartPointervtkXMLRectilinearGridWriter::New();
  writer-SetInputData(rg3D);
  writer-SetFileName(rgrid.vtr);
  writer-Write();
  
  vtkSmartPointervtkTransform transform =
vtkSmartPointervtkTransform::New();
  //transform-RotateZ(1.2345); // makes no difference
  transform-RotateZ(0.0);
  
  vtkSmartPointervtkTransformFilter transformFilter =
vtkSmartPointervtkTransformFilter::New();
  transformFilter-SetInputData(rg3D);
  transformFilter-SetTransform(transform);
  transformFilter-Update();

  vtkSmartPointervtkXMLStructuredGridWriter writer2 =
vtkSmartPointervtkXMLStructuredGridWriter::New();
  writer2-SetInputData(transformFilter-GetStructuredGridOutput());
  writer2-SetFileName(sgrid.vts);
  writer2-Write();

   /// switch these two round to enable weirdness.
  //auto grid = transformFilter-GetStructuredGridOutput(); // removes NaNs
  auto grid = rg3D; // gives NaNs
  

  for(uint c = 0; c  grid-GetNumberOfCells(); c++)
{
  auto cell = grid-GetCell(c);
  
  const auto numFaces = cell-GetNumberOfFaces();
  for(uint f = 0; f  numFaces; f++)
	{
	  const auto face = cell-GetFace(f);
	  //std::cout  cell-GetCellType() face-GetCellType()  std::endl;
	  
	  vtkSmartPointervtkPolygon polygon = vtkSmartPointervtkPolygon::New();
	  polygon-GetPoints()-SetNumberOfPoints(4);
	  polygon-GetPointIds()-SetNumberOfIds(4);
	  for(uint i = 0; i  face-GetNumberOfPoints(); i++)
	{
	  polygon-GetPointIds()-SetId(i,i);
	}
	  
	  for(uint p = 0; p  face-GetNumberOfPoints(); p++)
	{
	  std::arraydouble,3 pp;
	  face-GetPoints()-GetPoint(p, pp.data());
	  polygon-GetPoints()-SetPoint(p, pp[0], pp[1], pp[2]);
	}
	  const double area = polygon-ComputeArea();
	  std::cout  Areaarea  std::endl;

	  std::arraydouble,3 faceNormal;
	  const double faceArea = vtkPolygon::ComputeArea(polygon-GetPoints(),
			  face-GetNumberOfPoints(),
			  polygon-GetPointIds()-GetPointer(0),
			  faceNormal.data());
	  std::cout  Area 2faceArea  std::endl;
	  std::cout  Face Normal   faceNormal[0] faceNormal[1] faceNormal[2]  std::endl;
	  
	  vtkSmartPointervtkIdTypeArray pointsIDs = 

[Paraview] Explicit numbering of nodes indexes in Xdmf/h5

[Andrew Parker]

All,

I thought I'd forward this onto the paraview lists in case somebody could
think of a way to do this?  Please see my email below which I originally
sent to the vtk user list.  Any help would be very much appreciated,
including the fact that it just cannot be done.  I would in particular
welcome thoughts from those who have helped develop the xdmf2 lib within
the paraview source.

Many thanks again,
Andy

-- Forwarded message --
Date: 23 November 2013 17:13
Subject: [vtkusers] Explicit numbering of nodes for Xdmf/h5
To: vtkus...@vtk.org vtkus...@vtk.org


All,

In an effort to spark some comments I thought I'd try to provide a small
example for what I want to do in case my previous post (below) was unclear.
 Below is a valid xdmf file that paraview understands for a plane.

?xml version=1.0?
!DOCTYPE Xdmf SYSTEM Xdmf.dtd
Xdmf xmlns:xi=http://www.w3.org/2003/XInclude; Version=2.2
  Domain
Grid GridType=Uniform
  Topology TopologyType=Quadrilateral Dimensions=1
DataItem Dimensions=1 4 NumberType=Int Precision=8
Format=XML
   0 1 3 2
/DataItem
  /Topology
  Geometry GeometryType=XYZ
DataItem Dimensions=4 3 NumberType=Float Precision=4
Format=XML
  -0.5 -0.5 0
  0.5 -0.5 0
  -0.5 0.5 0
  0.5 0.5 0
/DataItem
  /Geometry
/Grid
  /Domain
/Xdmf

---  Now, what I want to do is to allow for the fact that the nodes
defining this plane, may happen to be labelled 300, 20, 22, 80 instead of
0-3.  The key point being that there is still only 4 nodes, not 300 in the
file for which I only need 4 to define the geom, but need to write out 300
to all for the 0-based implicit ordering.  Therefore, I'd like a section in
the geom part of the xmf file to qualify this numbering.  It doesn't bother
me if they're subsequently renumbered inside paraview/vtk, only that I
don't have to, as this is a simplistic version of something more
complicated.  So to be verbose, it should now look like:

?xml version=1.0?
!DOCTYPE Xdmf SYSTEM Xdmf.dtd
Xdmf xmlns:xi=http://www.w3.org/2003/XInclude; Version=2.2
  Domain
Grid GridType=Uniform
  Topology TopologyType=Quadrilateral Dimensions=1
DataItem Dimensions=1 4 NumberType=Int Precision=8
Format=XML
  * 300 20 22 80 *
/DataItem
  /Topology
  Geometry GeometryType=*XYZ_Explicit*
DataItem Dimensions=4 3 NumberType=Float Precision=4
Format=XML
*   20 -0.5 -0.5 0 *
*   22 0.5 -0.5 0 *
*   80 -0.5 0.5 0 *
*   300 0.5 0.5 0 *
 /DataItem
  /Geometry
/Grid
  /Domain
/Xdmf

Can this be done, or could this be done in the future?  Am I being daft and
there is an easy way to do this?

Cheers again,
Andy
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the ParaView Wiki at: 
http://paraview.org/Wiki/ParaView

Follow this link to subscribe/unsubscribe:
http://www.paraview.org/mailman/listinfo/paraview

[Paraview] Explicit numbering of nodes indexes in Xdmf/h5

[Andrew Parker]

All,

I thought I'd forward this onto the paraview list in case somebody could
think of a way to do this?  Please see my email below which I originally
sent to the vtk user list.  Any help would be very much appreciated,
including the fact that it just cannot be done.  I would in particular
welcome thoughts from those who have helped develop the xdmf2 lib within
the paraview source.

Many thanks again,
Andy

-- Forwarded message --
Date: 23 November 2013 17:13
Subject: [vtkusers] Explicit numbering of nodes for Xdmf/h5
To: vtkus...@vtk.org vtkus...@vtk.org


All,

In an effort to spark some comments I thought I'd try to provide a small
example for what I want to do in case my previous post (below) was unclear.
 Below is a valid xdmf file that paraview understands for a plane.

?xml version=1.0?
!DOCTYPE Xdmf SYSTEM Xdmf.dtd
Xdmf xmlns:xi=http://www.w3.org/2003/XInclude; Version=2.2
  Domain
Grid GridType=Uniform
  Topology TopologyType=Quadrilateral Dimensions=1
DataItem Dimensions=1 4 NumberType=Int Precision=8
Format=XML
   0 1 3 2
/DataItem
  /Topology
  Geometry GeometryType=XYZ
DataItem Dimensions=4 3 NumberType=Float Precision=4
Format=XML
  -0.5 -0.5 0
  0.5 -0.5 0
  -0.5 0.5 0
  0.5 0.5 0
/DataItem
  /Geometry
/Grid
  /Domain
/Xdmf

---  Now, what I want to do is to allow for the fact that the nodes
defining this plane, may happen to be labelled 300, 20, 22, 80 instead of
0-3.  The key point being that there is still only 4 nodes, not 300 in the
file for which I only need 4 to define the geom, but need to write out 300
to all for the 0-based implicit ordering.  Therefore, I'd like a section in
the geom part of the xmf file to qualify this numbering.  It doesn't bother
me if they're subsequently renumbered inside paraview/vtk, only that I
don't have to, as this is a simplistic version of something more
complicated.  So to be verbose, it should now look like:

?xml version=1.0?
!DOCTYPE Xdmf SYSTEM Xdmf.dtd
Xdmf xmlns:xi=http://www.w3.org/2003/XInclude; Version=2.2
  Domain
Grid GridType=Uniform
  Topology TopologyType=Quadrilateral Dimensions=1
DataItem Dimensions=1 4 NumberType=Int Precision=8
Format=XML
  * 300 20 22 80 *
/DataItem
  /Topology
  Geometry GeometryType=*XYZ_Explicit*
DataItem Dimensions=4 3 NumberType=Float Precision=4
Format=XML
*   20 -0.5 -0.5 0 *
*   22 0.5 -0.5 0 *
*   80 -0.5 0.5 0 *
*   300 0.5 0.5 0 *
 /DataItem
  /Geometry
/Grid
  /Domain
/Xdmf

Can this be done, or could this be done in the future?  Am I being daft and
there is an easy way to do this?

Cheers again,
Andy
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the ParaView Wiki at: 
http://paraview.org/Wiki/ParaView

Follow this link to subscribe/unsubscribe:
http://www.paraview.org/mailman/listinfo/paraview

Re: [Paraview] Explicit numbering of nodes indexes in Xdmf/h5

[Andrew Parker]

Hi Jason,

Many thanks for your reply.  In my case I'm not quite sure how attributes
would help me, but I may not fully understand how they work.  As I posted
in the second xmf example file in my last email, given 4 nodes with 4
unique positions, I can completely define the plane topologically by
writing the node numbers out in the correct order, their actual
label/value/number doesn't matter (as long as it consistently refers to the
correct position).

In my example I used [300 20 22 80] as the node labels to define a 2D
plane.  However, my current understanding of xdmf(2) is that I would need
to supply in the geometry section (regardless of GeometryType) 301 x, y and
z node positions (even if 297 are just zeros), just so that I could conform
to the zero-based implicit numbering of that section.  That allows paraview
to index that data and pick out (the only) 4 positions it requires to
define the plane.

I'm asking whether there is a way round this so that, as I gave as an
example in my second xmf file, one could additionally provide an explicit
node number next to each x,y,z position so that the implicit zero-based
numbering could be skipped and only 4 x,y,z positions needed to be added to
the file in addition to their label/value/number.

Can attributes do this?  If so could you provide a quick example, ideally
just with reference to the second example file I included in my email?  Do
you have a link to the xdmf(2) mail list?

Many thanks again,
Andy


On 25 November 2013 16:13, Jason Fleming
jason.flem...@seahorsecoastal.comwrote:

 Hello Andy

 The XDMF2 library has the ability to assign Attributes and Information
 data to Geometry objects. So you wouldn't be changing the node numbers,
 you'd just be adding a new Attribute that has different values at each
 node, and you'd need to display this new Attribute in Paraview instead of
 the node numbers.

 Since you mentioned offsets for XDMF arrays: I've been working on an XDMF2
 implementation for ADCIRC, a finite element coastal ocean model. Being a
 fortran code, ADCIRC uses 1-offset arrays, while the XDMF2 standard is
 0-offset.

 Its easy enough for us to subtract 1 from the node numbers in the element
 table when storing mesh data as XDMF2, reversing the operation upon read
 into ADCIRC or leaving them as-is for reading into Paraview. However, when
 looking at node and element number labels on ADCIRC data in Paraview, the
 analyst has to remember that all the displayed values are actually off by
 1.

 I emailed the XDMF mailing list and got a reply from the primary
 developers that they were previously unaware of the demand for 1-offset
 arrays, but they are now researching the possibility of adding this.

 Your case is a little different, since it seems you are interested in
 arbitrary node numbering. But I thought I would mention the above
 background info for completeness. As I said, XDMF2 Attributes may be the
 solution for you.

 Cheers
 Jason






 On Mon, Nov 25, 2013 at 10:41 AM, Andrew Parker 
 andy.john.par...@googlemail.com wrote:

 All,

 I thought I'd forward this onto the paraview list in case somebody could
 think of a way to do this?  Please see my email below which I originally
 sent to the vtk user list.  Any help would be very much appreciated,
 including the fact that it just cannot be done.  I would in particular
 welcome thoughts from those who have helped develop the xdmf2 lib within
 the paraview source.

 Many thanks again,
 Andy

 -- Forwarded message --
 Date: 23 November 2013 17:13
 Subject: [vtkusers] Explicit numbering of nodes for Xdmf/h5
 To: vtkus...@vtk.org vtkus...@vtk.org


 All,

 In an effort to spark some comments I thought I'd try to provide a small
 example for what I want to do in case my previous post (below) was unclear.
  Below is a valid xdmf file that paraview understands for a plane.

 ?xml version=1.0?
 !DOCTYPE Xdmf SYSTEM Xdmf.dtd
 Xdmf xmlns:xi=http://www.w3.org/2003/XInclude; Version=2.2
   Domain
 Grid GridType=Uniform
   Topology TopologyType=Quadrilateral Dimensions=1
 DataItem Dimensions=1 4 NumberType=Int Precision=8
 Format=XML
0 1 3 2
 /DataItem
   /Topology
   Geometry GeometryType=XYZ
 DataItem Dimensions=4 3 NumberType=Float Precision=4
 Format=XML
   -0.5 -0.5 0
   0.5 -0.5 0
   -0.5 0.5 0
   0.5 0.5 0
 /DataItem
   /Geometry
 /Grid
   /Domain
 /Xdmf

 ---  Now, what I want to do is to allow for the fact that the nodes
 defining this plane, may happen to be labelled 300, 20, 22, 80 instead of
 0-3.  The key point being that there is still only 4 nodes, not 300 in the
 file for which I only need 4 to define the geom, but need to write out 300
 to all for the 0-based implicit ordering.  Therefore, I'd like a section in
 the geom part of the xmf file to qualify this numbering.  It doesn't bother
 me if they're subsequently renumbered inside paraview/vtk, only that I
 don't have to, as this is a simplistic version

[Paraview] Median Dual Mesh Construction

[Andrew Parker]

Hi,

Just a quick one.  Is there any filter in vtk/paraview to obtain the median
dual of a mesh?  I'm happy to assume the cells are know cell types, but
would want it for any input type of mesh.

Anybody had success with something like this in vtk?

Cheers,
Andy
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the ParaView Wiki at: 
http://paraview.org/Wiki/ParaView

Follow this link to subscribe/unsubscribe:
http://www.paraview.org/mailman/listinfo/paraview

Re: [Paraview] Construct 3D revolved mesh from a 2d mesh

[Andrew Parker]

Sorry to repost.  Does anybody have a feel for whether I can apply a filter
and essentially produce a 3d volume mesh with associated scalars and
transformed vectors, from it's 2d counter part using vtk?

i.e. a cylindrically symmetric simulation converted to a valid 3d volume
mesh.  I can apply the filter, similar to this thread:

http://www.paraview.org/pipermail/paraview/2012-March/024320.html

but in my case, rather than for presentational purposes, I need the
internal of the rotated shell to be a populated volume mesh.  Using the
method in the above post, or described in my previous post gives only the
outer shell.

Any help either way really appreciated!

Cheers,
Andy


All,

 I am doing this in code using vtk, but can be reproduced using paraview as
 noted below.

 I have a 2d mesh which represent a cylindrically symmetric simulation.  I
 want to be able to revolve this around the z-axis to create a 3d mesh.
  However, when doing this using the rotational extrusion filter, I only
 seem to have boundary faces.  I can't get this to give me 3d cells inside
 the volume of revolution, which is what I'm after.  Can this be done?  I
 have done this in visit and sure enough the mesh is inside the volume of
 revolution as I expect.

 This can be reproduced in paraview using the UCD_3.inp example from
 the data set.

 First apply a transform and rotate around 90 degrees round the y axis.
  Then apply the extract surface filter. I too must do this in my code as
 the incoming mesh is a vtkUnstructuredGrid and the rotational extrusion
 filter wants a polydata.  Then apply the rotational extrusion filter for
 360 degrees with 120 resolution.  Finally perform an x-normal slice at the
 default position.  Viewing only the slice shows the outer boundary only,
 but I had wanted the interior of the boundary to be populated with a mesh,
 not bothered about its topology, just want a fully populated mesh within
 the interior.

 Again, any help on the above really appreciated??  As I say achieved with
 visitwhich I mention only because I assume the code under the hood
 would be vtk and hence possible in my case.

 Many thanks,
 Andy

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the ParaView Wiki at: 
http://paraview.org/Wiki/ParaView

Follow this link to subscribe/unsubscribe:
http://www.paraview.org/mailman/listinfo/paraview

[Paraview] Construct 3D revolved mesh from a 2d mesh

[Andrew Parker]

All,

I am doing this in code using vtk, but can be reproduced using paraview as
noted below.

I have a 2d mesh which represent a cylindrically symmetric simulation.  I
want to be able to revolve this around the z-axis to create a 3d mesh.
 However, when doing this using the rotational extrusion filter, I only
seem to have boundary faces.  I can't get this to give me 3d cells inside
the volume of revolution, which is what I'm after.  Can this be done?  I
have done this in visit and sure enough the mesh is inside the volume of
revolution as I expect.

This can be reproduced in paraview using the UCD_3.inp example from the
data set.

First apply a transform and rotate around 90 degrees round the y axis.
 Then apply the extract surface filter. I too must do this in my code as
the incoming mesh is a vtkUnstructuredGrid and the rotational extrusion
filter wants a polydata.  Then apply the rotational extrusion filter for
360 degrees with 120 resolution.  Finally perform an x-normal slice at the
default position.  Viewing only the slice shows the outer boundary only,
but I had wanted the interior of the boundary to be populated with a mesh,
not bothered about its topology, just want a fully populated mesh within
the interior.

Again, any help on the above really appreciated??  As I say achieved with
visitwhich I mention only because I assume the code under the hood
would be vtk and hence possible in my case.

Many thanks,
Andy
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the ParaView Wiki at: 
http://paraview.org/Wiki/ParaView

Follow this link to subscribe/unsubscribe:
http://www.paraview.org/mailman/listinfo/paraview

[Paraview] Possible vtkOBBTree bug or weirdness

[Andrew Parker]

Hi,

So I've been having some problems with vtkOBBTree using the
intersectWithLine method with the following signature:

int IntersectWithLine (double a0[3], double a1[3], double tol, double t,
double x[3], double pcoords[3], int subId, vtkIdType cellId,
vtkGenericCell *cell)

In particular, depending on what I have initialised some of the input
parameters to, which I had assumed and the code and docs indicate their
initial values are not important, with exception of a0, a1, and tol(0,0), I
got different results.  Having looked at the tree, I found that I had
forgotten to set the tolerance, it was undefined in the class and unset.
(might be good if a sensible default got set, this too could be defined as
a bug...)  Anyway, correcting that and setting the tolerance to zero I then
got this:

Percentage Complete: 2Generic Warning: In VTK/Common/vtkMath.cxx, line 736
vtkMath::Jacobi: Error extracting eigenfunctions

A lot.  Looking at the code, the following comment is a bit worrying:

   this is NEVER called
  if ( i = VTK_MAX_ROTATIONS )
{
vtkGenericWarningMacro(
   vtkMath::Jacobi: Error extracting eigenfunctions);
return 0;
}

I need a locator that can let me intersect with a line, and given me back:
1) the cell that it intersected with,
2) the location of the intersection.

Also I found in some instances 't' was bigger than one, which I understood
to not be possible.

Any help, and advice on an alternative intersector that can give me back
the above would be great as my choice of vtkobbtree was almost random

Cheers,
Andy
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the ParaView Wiki at: 
http://paraview.org/Wiki/ParaView

Follow this link to subscribe/unsubscribe:
http://www.paraview.org/mailman/listinfo/paraview

[Paraview] 3.98-rc2 and multiple selections

[Andrew Parker]

Hi,

So as requested, I built the latest rc against 4.7.2 and that also happens
to be built against qt 4.8.3, and it compiles and installs fine. This is
built against openmpi 1.6.2 with use_mpi on.  However, I have noticed that
when loading multiple files around 20 of them, vtu's in this instance, each
representing a sub part of the domain, after apply is pressed it only opens
the last file in the list.  I had to go through each file, 20 odd and click
apply on each to see them all.  Don't know if this is a known bug, or is a
feature change and I'm now doing it incorrectly, but this does not behave
the same as 3.14.1 would be nice if you only needed to press apply once
as before.

Hope the info is useful,
Cheers,
Andy
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the ParaView Wiki at: 
http://paraview.org/Wiki/ParaView

Follow this link to subscribe/unsubscribe:
http://www.paraview.org/mailman/listinfo/paraview

[Paraview] Bug with 4.7.2 build and 3.14.1

[Andrew Parker]

Hi,

I get this error building a fresh clone of 3.14.1 using gcc 4.7.2, vtk
build and works perfectly fine with this compiler so I presume it's a
slight change in ordering that has caused the problem.:

[ 30%] Building CXX object
VTK/Rendering/CMakeFiles/vtkRendering.dir/vtkFreeTypeUtilities.cxx.o

ParaView/VTK/Rendering/vtkFreeTypeUtilities.cxx: In function ‘FT_Error
vtkFreeTypeUtilitiesFaceRequester(FTC_FaceID, FT_Library, FT_Pointer,
FT_FaceRec_**)’:
ParaView/VTK/Rendering/vtkFreeTypeUtilities.cxx:343:46: error: expected
type-specifier before ‘intptr_t’
ParaView/VTK/Rendering/vtkFreeTypeUtilities.cxx:343:46: error: expected ‘’
before ‘intptr_t’
ParaView/VTK/Rendering/vtkFreeTypeUtilities.cxx:343:46: error: expected ‘(’
before ‘intptr_t’
ParaView/VTK/Rendering/vtkFreeTypeUtilities.cxx:343:46: error: ‘intptr_t’
was not declared in this scope

Seems very simple, just seems to me to be a missing #include stdint.h,
fixing it by including said header in the cxx file above, then gives this:

ParaView/VTK/Rendering/vtkFreeTypeTools.cxx: In function ‘FT_Error
vtkFreeTypeToolsFaceRequester(FTC_FaceID, FT_Library, FT_Pointer,
FT_FaceRec_**)’:
ParaView/VTK/Rendering/vtkFreeTypeTools.cxx:229:46: error: expected
type-specifier before ‘intptr_t’
ParaView/VTK/Rendering/vtkFreeTypeTools.cxx:229:46: error: expected ‘’
before ‘intptr_t’
ParaView/VTK/Rendering/vtkFreeTypeTools.cxx:229:46: error: expected ‘(’
before ‘intptr_t’
ParaView/VTK/Rendering/vtkFreeTypeTools.cxx:229:46: error: ‘intptr_t’ was
not declared in this scope

including this again inside the cxx fixes this too and it seems to go
through fine.  Probably too late for 3.14.1 but might be of use for
3.98?

Let me know if this was the wrong thing to use?? As I've change my local
copy to reflect the above.

Cheers,
Andy
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the ParaView Wiki at: 
http://paraview.org/Wiki/ParaView

Follow this link to subscribe/unsubscribe:
http://www.paraview.org/mailman/listinfo/paraview

Re: [Paraview] [vtkusers] vtkDistributedDataFilter and ghost cells

[Andrew Parker]

Hi mate, how goes it?

How do you set the ghost level to be one rather than default zero then?
 Have you written your own downstream filter to update the number of
ghost levels?  If so any tips?

If you know the name of a global node ID array in the input dataset, set
that name with this method... Which method??  How do I set this?  I could
probably work out the global node and cell numbers and stick them into the
meshes that I pass to D3.  But how do I do that?  What method do I call to
set them, and what name do I give them this method ain't that helpful
in the docs ;-)

Cheers,
Andy

On 8 November 2012 01:18, Paul Edwards paul.m.edwa...@gmail.com wrote:

 Hi Andy,

 I've had a few problems with D3.  The limitation I find is that global
 node ids are slow to generate and the point merging (I think) is only
 performed in single precision.  Also, remember that everything will be
 redone each time the number of ghost levels that are requested changes -
 this means the global ids are recalculated, it is repartitioned and then
 the number of ghost levels are added.  In some ways it might be better to
 have D3 split into 3 filters for the different steps although it would make
 a long pipeline.

 Btw looking at the docs it seems to suggest that it only creates temporary
 arrays for global ids within d3 (although I think in the past I have had
 access to the global ids it created):

 If you know the name of a global node ID array in the input dataset, set
 that name with this method. If you leave it unset, D3 will search the input
 data set for certain common names of global node ID arrays. If none is
 found, and ghost cells have been requested,* D3 will create a temporary
 global node ID array* before acquiring ghost cells. It is also desirable
 to have global element IDs. However, if they don't exist D3 can create them
 relatively quickly. Set the name of the global element ID array if you have
 it. If it is not set, D3 will search for it using common names. If still
 not found, D3 will create a temporary array of global element IDs.


 My filters now add their own global ids so I don't use d3 for that.

 Regards,
 Paul


 On 7 November 2012 14:50, George Zagaris george.zaga...@kitware.comwrote:

 On Wed, Nov 7, 2012 at 9:34 AM, Andrew Parker
 andy.john.par...@googlemail.com wrote:
  Many thanks for that.  I perform some threshold stuff early on, so
 basically
 

 Perhaps an easy solution is to append a GlobalCellID and
 GlobalNodeID before thresholding. To the best of my knowledge,
 threshold will extract vtkUnstructuredGrid instance from whatever goes
 in the input and not automatically retain this type of global
 information.

 Hope this helps.

 Best,
 George

  On 7 November 2012 13:00, George Zagaris george.zaga...@kitware.com
 wrote:
 
  Hello,
 
  Since the data is essentially structured (rectilinear grids), I think
  the best way to get the global/local mapping is to use extent
  information. Specifically, you need the whole extent of the grid and
  the global extent of each partition. Then from the global IJK of a
  point or cell, and the whole extent you can use methods from
  vtkStructuredData to compute the corresponding global linear index for
  a point or cell. Do you have extent information?
 
  Also, I have done some work on ghost generation in VTK for structured
  (and AMR) data. Unfortunately, currently it doesn't work outside the
  box with rectilinear grids. This functionality can still be used to
  create ghost layers and exchange the fields (node and/or cell data) on
  the grid but, it doesn't communicate the coordindates on the
  rectilinear grid. Alternatively, you may be able to converge to a
  solution faster if you convert the rectilinear grid to a
  vtkStructuredGrid and use vtkPStructuredGridConnectivity or
  vtkPStructuredGridGhostDataGenerator to generate ghost layers. There
  are tests that illustrate how to use these classes and I can provide
  more information if you are interested.
 
  Best,
  George
 
  On Wed, Nov 7, 2012 at 7:22 AM, Moreland, Kenneth kmo...@sandia.gov
  wrote:
   Hmmm. I thought global point IDs were always created. Maybe it only
   happens
   when ghost cells are created. Try getting that working first.
  
   As far as global cell IDs are concerned, you are out of luck.
   vtkDistributedDataFilter does not create them. But they are not all
 that
   useful anyway since, unlike points, once you remove the out cells
 there
   is
   no overlap. Usually you can get all the information you want from the
   ghost
   level.
  
   If you really need global cell IDs, I'm sure you would have no
 trouble
   making them yourself. I would do it before running
   vtkDistributedDataFilter.
   Assuming when you first read in your data you have no duplicate
 cells,
   just
   label those on process 0 as 0..N_0, those on process 1 as N_0+1..N_1,
   and so
   on.
  
   -Ken
  
   Sent from my iPad so blame autocorrect.
  
   On Nov 7, 2012, at 2:38 AM, Andrew Parker

Re: [Paraview] vtkDistributedDataFilter and ghost cells

[Andrew Parker]

So that's working now in terms of the cast, forgot GetOutput() inside the
cast operator!  The returned vtkUGrid is now fully populated and contains
sensible information.

However, both getPointData()-GetGlobalIds()  and
 getCellData()-GetGlobalIds() return null pointers.  Any thoughts?

Also, should I be using CellData since I want the cell global to local
mapping for cells not the nodes, at the moment at least?

On 6 November 2012 19:05, Moreland, Kenneth kmo...@sandia.gov wrote:

   Perhaps it is outputting a composite data set of some type?  Try
 running GetClassName() to see what type of data object it really is.

  -Ken

   From: Andrew Parker andy.john.par...@googlemail.com
 Date: Tuesday, November 6, 2012 9:50 AM

 To: Kenneth Moreland kmo...@sandia.gov
 Cc: vtkus...@vtk.org vtkus...@vtk.org, paraview@paraview.org 
 paraview@paraview.org
 Subject: [EXTERNAL] Re: [Paraview] vtkDistributedDataFilter and ghost
 cells

   Thanks on both accounts.  Any thoughts why the downcast called after
 dd-Update() on distributedDataFilter is a null pointer?  As in, dd is
 working perfectly properly, but I don't seem to be able to extract a valid
 unstructuredgrid.  For a follow up question I assume
 getPointData()-GetGlobalIds() gives the local to global for the mesh
 nodes, and I should use getCellData()-GetGlobalIds() to get the local to
 global for the cells?  Once I get a valid pointer that is

  Cheers again,
 Andy

 On 6 November 2012 16:40, Moreland, Kenneth kmo...@sandia.gov wrote:

   You should be able to do a vtkUnstructuredGrid::SafeDownCast() to the
 data to get the unstructured mesh (and access to the point data).

  -Ken

   From: Andrew Parker andy.john.par...@googlemail.com
 Date: Tuesday, November 6, 2012 9:32 AM
 To: Kenneth Moreland kmo...@sandia.gov
 Cc: vtkus...@vtk.org vtkus...@vtk.org, paraview@paraview.org 
 paraview@paraview.org
 Subject: [EXTERNAL] Re: [Paraview] vtkDistributedDataFilter and ghost
 cells

   Another question which I'd forgotten, how do I get to a
 vtkUnstructuredGrid per processor from the vtkDistributedDataFilter.

  For instance, dd-GetOutput()-GetPointData()-GetGlobalIds() doesn't
 work as it's a vtkDataObject

  Stupid question I'm sure but the doxy notes say this type returns an
 unstructured mesh, but I can't seem to get it out?

  Also, why exactly do I need the vtkPieceScalars and
 vtkDataSetSurfaceFilter again? If the above can be made to work and
 return the mapping, what are they adding in terms of information?

  Thanks again,
 Andy

 On 6 November 2012 16:00, Moreland, Kenneth kmo...@sandia.gov wrote:

   I believe vtkDistributedDataFilter will always return with global
 point ids (a mapping from local point ids to global point ids), although it
 might pass them if they already exist.  So
 dd-GetOutput()-GetPointData()-GetGlobalIds() should return the array
 that gives this mapping.

  Ghost cells are only created on demand, and this is usually done by
 pipeline convention.  If you have a filter that needs a layer of ghost
 cells, it should override the RequestUpdateExtent method to increment the
 value of UPDATE_NUMBER_OF_GHOST_LEVELS from the output information to the
 input information.  This method would look something like this.

   int vtkDistributedDataFilter::RequestUpdateExtent(
   vtkInformation *vtkNotUsed(request),
   vtkInformationVector **inputVector,
   vtkInformationVector *outputVector)
 {
   // get the info objects
   vtkInformation *inInfo = inputVector[0]-GetInformationObject(0);
   vtkInformation *outInfo = outputVector-GetInformationObject(0);

int piece, numPieces, ghostLevels;

// We require an extra layer of ghost cells from upstream.

piece =
 outInfo-Get(vtkStreamingDemandDrivenPipeline::UPDATE_PIECE_NUMBER());
   numPieces =

 outInfo-Get(vtkStreamingDemandDrivenPipeline::UPDATE_NUMBER_OF_PIECES());
   ghostLevels =
 outInfo-Get(
 vtkStreamingDemandDrivenPipeline::UPDATE_NUMBER_OF_GHOST_LEVELS());

inInfo-Set(vtkStreamingDemandDrivenPipeline::UPDATE_PIECE_NUMBER(),
 piece);

 inInfo-Set(vtkStreamingDemandDrivenPipeline::UPDATE_NUMBER_OF_PIECES(),
   numPieces);

 inInfo-Set(vtkStreamingDemandDrivenPipeline::UPDATE_NUMBER_OF_GHOST_LEVELS(),
   ghostLevels);

return 1;
 }


  The operation of the RequestData method should also strip off this
 layer of ghost cells.  It might be possible to request a layer of ghost
 cells by setting UPDATE_NUMBER_OF_GHOST_LEVELS at the bottom of the
 pipeline, but I'm not totally sure how to make that work.  It's probably
 easier (or at least cleaner) to do it from within a filter.

  -Ken

   From: Andrew Parker andy.john.par...@googlemail.com
 Date: Tuesday, November 6, 2012 8:25 AM
 To: vtkus...@vtk.org vtkus...@vtk.org, paraview@paraview.org 
 paraview@paraview.org
 Subject: [EXTERNAL] [Paraview] vtkDistributedDataFilter and ghost cells

   Hi,

  Hope you can help.  I have some code running in parallel, that by
 other means I have constructed

Re: [Paraview] [vtkusers] vtkDistributedDataFilter and ghost cells

[Andrew Parker]

Many thanks for that.  I perform some threshold stuff early on, so
basically I'm working with unstructured grids pretty much from zero.  I
think I need to try to populate the ghost cells using the approach Ken
suggested, but I'm not sure how to do that both from a conceptual point of
view - I'd just be copying Ken's code, but also from the perspective of
fitting into my code design.

There does seem to be some confusion surrounding ghost cells and local to
global cell mappings both in terms of which class computes/owns them and
when and how.  Is that fair? I had assumed that given the massive amount of
work that D3 is doing, it would (must have) computed this info and have
been readily available via get methods, rather than going down the route of
extending the class just to define my own virtual methods

These things are basic sets of info for parallel computing and I would have
assumed others would have wanted them but there is a lack of usage examples
and postsnot a complaint just surprised given that basically you can't
get going with vtk in parallel unless you use something like D3 for the
type of things I want to do.  i.e. local processing and some exchange over
halos

It is odd that I also can't get cell local to global out of the box as Ken
said...

Going to have a go with Ken's method and see where I get to.  Are there any
good examples of creating and using ghost cells with unstructured meshes
that you could recommend??

Cheers again,
Andy

On 7 November 2012 13:00, George Zagaris george.zaga...@kitware.com wrote:

 Hello,

 Since the data is essentially structured (rectilinear grids), I think
 the best way to get the global/local mapping is to use extent
 information. Specifically, you need the whole extent of the grid and
 the global extent of each partition. Then from the global IJK of a
 point or cell, and the whole extent you can use methods from
 vtkStructuredData to compute the corresponding global linear index for
 a point or cell. Do you have extent information?

 Also, I have done some work on ghost generation in VTK for structured
 (and AMR) data. Unfortunately, currently it doesn't work outside the
 box with rectilinear grids. This functionality can still be used to
 create ghost layers and exchange the fields (node and/or cell data) on
 the grid but, it doesn't communicate the coordindates on the
 rectilinear grid. Alternatively, you may be able to converge to a
 solution faster if you convert the rectilinear grid to a
 vtkStructuredGrid and use vtkPStructuredGridConnectivity or
 vtkPStructuredGridGhostDataGenerator to generate ghost layers. There
 are tests that illustrate how to use these classes and I can provide
 more information if you are interested.

 Best,
 George

 On Wed, Nov 7, 2012 at 7:22 AM, Moreland, Kenneth kmo...@sandia.gov
 wrote:
  Hmmm. I thought global point IDs were always created. Maybe it only
 happens
  when ghost cells are created. Try getting that working first.
 
  As far as global cell IDs are concerned, you are out of luck.
  vtkDistributedDataFilter does not create them. But they are not all that
  useful anyway since, unlike points, once you remove the out cells there
 is
  no overlap. Usually you can get all the information you want from the
 ghost
  level.
 
  If you really need global cell IDs, I'm sure you would have no trouble
  making them yourself. I would do it before running
 vtkDistributedDataFilter.
  Assuming when you first read in your data you have no duplicate cells,
 just
  label those on process 0 as 0..N_0, those on process 1 as N_0+1..N_1,
 and so
  on.
 
  -Ken
 
  Sent from my iPad so blame autocorrect.
 
  On Nov 7, 2012, at 2:38 AM, Andrew Parker
  andy.john.par...@googlemail.com wrote:
 
  So that's working now in terms of the cast, forgot GetOutput() inside the
  cast operator!  The returned vtkUGrid is now fully populated and contains
  sensible information.
 
  However, both getPointData()-GetGlobalIds()  and
  getCellData()-GetGlobalIds() return null pointers.  Any thoughts?
 
  Also, should I be using CellData since I want the cell global to local
  mapping for cells not the nodes, at the moment at least?
 
  On 6 November 2012 19:05, Moreland, Kenneth kmo...@sandia.gov wrote:
 
  Perhaps it is outputting a composite data set of some type?  Try running
  GetClassName() to see what type of data object it really is.
 
  -Ken
 
  From: Andrew Parker andy.john.par...@googlemail.com
  Date: Tuesday, November 6, 2012 9:50 AM
 
  To: Kenneth Moreland kmo...@sandia.gov
  Cc: vtkus...@vtk.org vtkus...@vtk.org, paraview@paraview.org
  paraview@paraview.org
  Subject: [EXTERNAL] Re: [Paraview] vtkDistributedDataFilter and ghost
  cells
 
  Thanks on both accounts.  Any thoughts why the downcast called after
  dd-Update() on distributedDataFilter is a null pointer?  As in, dd is
  working perfectly properly, but I don't seem to be able to extract a
 valid
  unstructuredgrid.  For a follow up question I assume

Re: [Paraview] [vtkusers] vtkDistributedDataFilter and ghost cells - PROGRESS

[Andrew Parker]

So I've added this in an .cpp file and complied it:

vtkStandardNewMacro(MyD3)

MyD3::MyD3()
: vtkDistributedDataFilter()
{
}

void MyD3::PrintSelf(ostream os, vtkIndent indent)
{
  this-Superclass::PrintSelf(os,indent);
}

int MyD3::RequestUpdateExtent(vtkInformation *vtkNotUsed(request),
  vtkInformationVector **inputVector,
  vtkInformationVector *outputVector)
{
  // get the info objects
  vtkInformation *inInfo = inputVector[0]-GetInformationObject(0);
  vtkInformation *outInfo = outputVector-GetInformationObject(0);

  int piece, numPieces, ghostLevels;

  // We require an extra layer of ghost cells from upstream.

  piece =
outInfo-Get(vtkStreamingDemandDrivenPipeline::UPDATE_PIECE_NUMBER());
  numPieces =
outInfo-Get(vtkStreamingDemandDrivenPipeline::UPDATE_NUMBER_OF_PIECES());
  ghostLevels =
outInfo-Get(vtkStreamingDemandDrivenPipeline::UPDATE_NUMBER_OF_GHOST_LEVELS())
+ 1; //# New bit, modified from Ken's notes

  inInfo-Set(vtkStreamingDemandDrivenPipeline::UPDATE_PIECE_NUMBER(),
piece);
  inInfo-Set(vtkStreamingDemandDrivenPipeline::UPDATE_NUMBER_OF_PIECES(),
numPieces);

inInfo-Set(vtkStreamingDemandDrivenPipeline::UPDATE_NUMBER_OF_GHOST_LEVELS(),
ghostLevels);

  return 1;
}

And I add this to a .h file:

class MyD3
  : public vtkDistributedDataFilter
{
  vtkTypeMacro(MyD3, vtkDistributedDataFilter);

public:
  static MyD3 *New();
  void PrintSelf(ostream os, vtkIndent indent);
  int RequestUpdateExtent(vtkInformation *vtkNotUsed(request),
  vtkInformationVector **inputVector,
  vtkInformationVector *outputVector);
protected:
  MyD3();

private:
  // MyD3(const MyD3);  // Not implemented.
  // void operator=(const MyD3);  // Not implemented.
};

I then invoke it in parallel 3 way, as I did before, but now using:

  vtkSmartPointerMyD3 dd = vtkSmartPointerMyD3::New();

  // here mesh is a vtkUnstructuredGrid on each processor, obtained from
other (non-vtk) means, but represents a valid and checked subset of the
entire mesh.
  dd-SetInput(mesh);
  dd-SetController(getVtkController());
  dd-SetBoundaryModeToSplitBoundaryCells();  // clipping
  dd-UseMinimalMemoryOff();
  dd-Update();

  vtkSmartPointervtkUnstructuredGrid
ddUmesh(vtkUnstructuredGrid::SafeDownCast(dd-GetOutput()));

  auto ids = ddUmesh-GetPointData()-GetGlobalIds();
  auto cids = ddUmesh-GetCellData()-GetGlobalIds();


Notes:

1) Both ids, and cids remain null, although I now understand from Ken that
cids will always be null as they're not created.
2) Using totalview and stopping the code in parallel 3 way on line 670 of
vtkDistributedDataFilter.cxx, the member this-GhostLevel is always zero
and never executes codes branches dependent on it, however, the above code
successfully increments the ghostLevels to one.
3) So basically moved forward a little bit, but still not working.  Any
thoughts??
4) If I had created the ghost cells, how would I know, is my next question.
 How can I visualise them to check?

Any thoughts really welcome.

Cheers again,
Andy



On 7 November 2012 14:50, George Zagaris george.zaga...@kitware.com wrote:

 On Wed, Nov 7, 2012 at 9:34 AM, Andrew Parker
 andy.john.par...@googlemail.com wrote:
  Many thanks for that.  I perform some threshold stuff early on, so
 basically
 

 Perhaps an easy solution is to append a GlobalCellID and
 GlobalNodeID before thresholding. To the best of my knowledge,
 threshold will extract vtkUnstructuredGrid instance from whatever goes
 in the input and not automatically retain this type of global
 information.

 Hope this helps.

 Best,
 George

  On 7 November 2012 13:00, George Zagaris george.zaga...@kitware.com
 wrote:
 
  Hello,
 
  Since the data is essentially structured (rectilinear grids), I think
  the best way to get the global/local mapping is to use extent
  information. Specifically, you need the whole extent of the grid and
  the global extent of each partition. Then from the global IJK of a
  point or cell, and the whole extent you can use methods from
  vtkStructuredData to compute the corresponding global linear index for
  a point or cell. Do you have extent information?
 
  Also, I have done some work on ghost generation in VTK for structured
  (and AMR) data. Unfortunately, currently it doesn't work outside the
  box with rectilinear grids. This functionality can still be used to
  create ghost layers and exchange the fields (node and/or cell data) on
  the grid but, it doesn't communicate the coordindates on the
  rectilinear grid. Alternatively, you may be able to converge to a
  solution faster if you convert the rectilinear grid to a
  vtkStructuredGrid and use vtkPStructuredGridConnectivity or
  vtkPStructuredGridGhostDataGenerator to generate ghost layers. There
  are tests that illustrate how to use these classes and I can provide
  more information if you are interested.
 
  Best,
  George
 
  On Wed, Nov 7, 2012 at 7:22 AM, Moreland, Kenneth kmo...@sandia.gov
  wrote:
   Hmmm. I thought global point IDs were

Re: [Paraview] [vtkusers] vtkDistributedDataFilter and ghost cells - PROGRESS

[Andrew Parker]

Ok thanks again for the advice.  Think it's really clear I'm confused
between the downstream nomenclature.  Do mean just a class that
constructs or takes a D3 as input that I write from scratch outside of vtk?
Or do you mean something totally different?  Clearly my understanding of
it was to inherit was totally wrong.  I would prefer to stick with the
downstream filter if that's more robust.

Could you give me a quick explanation in this context?  In addition could
you point me towards an example of using a downstream filter in this
context?

Sorry again for the confusion,
Andy

On 7 November 2012 16:48, Moreland, Kenneth kmo...@sandia.gov wrote:

   The instructions I gave were for a downstream filter separate from D3.
  If you want to modify D3 itself (which sounds like a reasonable good idea
 for your purposes) then you will have change the value for
 UPDATE_NUMBER_OF_GHOST_LEVELS that the RequestData reads.  If you want to
 go with this approach, first blow away your RequestUpdateExtent method.
  Let D3 do its regular thing.  Then implement a RequestData method like the
 following:

  int MyD3::RequestData(
vtkInformation *request,
   vtkInformationVector **inputVector,
   vtkInformationVector *outputVector)
 {
vtkInformation *outInfo = outputVector-GetInformationObject(0);

int requestedGhostLevel = outInfo-Get(
  vtkStreamingDemandDrivenPipeline::UPDATE_NUMBER_OF_GHOST_LEVELS());
outInfo-Set(
  vtkStreamingDemandDrivenPipeline::UPDATE_NUMBER_OF_GHOST_LEVELS(),
  requestedGhostLevel + 1);

return this-Superclass::RequestData(request, inputVector,
 outputVector);
 }

   I don't know if the executive is going to get upset about you changing
 UPDATE_NUMBER_OF_GHOST_LEVELS in RequestData, but I think it will be all
 right.

  -Ken

   From: Andrew Parker andy.john.par...@googlemail.com
 Date: Wednesday, November 7, 2012 9:31 AM
 To: George Zagaris george.zaga...@kitware.com
 Cc: Kenneth Moreland kmo...@sandia.gov, vtkus...@vtk.org 
 vtkus...@vtk.org, paraview@paraview.org paraview@paraview.org
 Subject: [EXTERNAL] Re: [vtkusers] [Paraview] vtkDistributedDataFilter
 and ghost cells - PROGRESS

   So I've added this in an .cpp file and complied it:

  vtkStandardNewMacro(MyD3)

  MyD3::MyD3()
 : vtkDistributedDataFilter()
 {
 }

  void MyD3::PrintSelf(ostream os, vtkIndent indent)
 {
   this-Superclass::PrintSelf(os,indent);
 }

  int MyD3::RequestUpdateExtent(vtkInformation *vtkNotUsed(request),
  vtkInformationVector **inputVector,
  vtkInformationVector *outputVector)
 {
   // get the info objects
   vtkInformation *inInfo = inputVector[0]-GetInformationObject(0);
   vtkInformation *outInfo = outputVector-GetInformationObject(0);

   int piece, numPieces, ghostLevels;

   // We require an extra layer of ghost cells from upstream.

   piece =
 outInfo-Get(vtkStreamingDemandDrivenPipeline::UPDATE_PIECE_NUMBER());
   numPieces =
 outInfo-Get(vtkStreamingDemandDrivenPipeline::UPDATE_NUMBER_OF_PIECES());
   ghostLevels =
 outInfo-Get(vtkStreamingDemandDrivenPipeline::UPDATE_NUMBER_OF_GHOST_LEVELS())
 + 1; //# New bit, modified from Ken's notes

   inInfo-Set(vtkStreamingDemandDrivenPipeline::UPDATE_PIECE_NUMBER(),
 piece);
   inInfo-Set(vtkStreamingDemandDrivenPipeline::UPDATE_NUMBER_OF_PIECES(),
 numPieces);

 inInfo-Set(vtkStreamingDemandDrivenPipeline::UPDATE_NUMBER_OF_GHOST_LEVELS(),
 ghostLevels);

   return 1;
 }

  And I add this to a .h file:

  class MyD3
   : public vtkDistributedDataFilter
 {
   vtkTypeMacro(MyD3, vtkDistributedDataFilter);

 public:
   static MyD3 *New();
   void PrintSelf(ostream os, vtkIndent indent);
   int RequestUpdateExtent(vtkInformation *vtkNotUsed(request),
  vtkInformationVector **inputVector,
  vtkInformationVector *outputVector);
 protected:
   MyD3();

 private:
   // MyD3(const MyD3);  // Not implemented.
   // void operator=(const MyD3);  // Not implemented.
 };

  I then invoke it in parallel 3 way, as I did before, but now using:

vtkSmartPointerMyD3 dd = vtkSmartPointerMyD3::New();

   // here mesh is a vtkUnstructuredGrid on each processor, obtained from
 other (non-vtk) means, but represents a valid and checked subset of the
 entire mesh.
   dd-SetInput(mesh);
   dd-SetController(getVtkController());
   dd-SetBoundaryModeToSplitBoundaryCells();  // clipping
   dd-UseMinimalMemoryOff();
   dd-Update();

   vtkSmartPointervtkUnstructuredGrid
 ddUmesh(vtkUnstructuredGrid::SafeDownCast(dd-GetOutput()));

   auto ids = ddUmesh-GetPointData()-GetGlobalIds();
   auto cids = ddUmesh-GetCellData()-GetGlobalIds();

  
 Notes:

  1) Both ids, and cids remain null, although I now understand from Ken
 that cids will always be null as they're not created.
 2) Using totalview and stopping the code in parallel 3 way on line 670 of
 vtkDistributedDataFilter.cxx, the member this-GhostLevel is always zero
 and never executes codes branches dependent on it, however, the above code
 successfully increments

[Paraview] vtkDistributedDataFilter and ghost cells

[Andrew Parker]

Hi,

Hope you can help.  I have some code running in parallel, that by other
means I have constructed nprocs worth of vtkRectilinearGrids, one per
process.  Each of which is a valid nprocs-worth of the whole serial mesh,
I've check this and I am happy with that i.e. it's partitioned properly and
nothing is missing.  I need the following information to process my data in
parallel:

1) I would like the local - global cell mapping between the local rgrid
and the corresponding global single mesh.
2) I would like to know which cells are on processor boundaries for
parallel exchange purposes.
3) I would like all the double arrays per processor to be expanded by the
amount of (1 level of) ghost cells such that I can properly do the
computations I want with the ability to exchange only those additional
cells given the local to global mapping.

I have tried from the examples to use the following code, which I call on
every process, each of which has it's own local rgrid as I said.  I do the
following:

 vtkSmartPointervtkDistributedDataFilter dd =
vtkSmartPointervtkDistributedDataFilter::New();
  dd-SetInput(rgrid);

 dd-SetController(getVtkController());
  dd-SetBoundaryModeToSplitBoundaryCells();
 //dd-SetBoundaryModeToAssignToOneRegion();
 //dd-SetBoundaryModeToAssignToAllIntersectingRegions();
 dd-UseMinimalMemoryOff();
 dd-Update();
  vtkPieceScalars *ps = vtkPieceScalars::New();
 ps-SetInputConnection(dd-GetOutputPort());
 ps-SetScalarModeToCellData();
  vtkDataSetSurfaceFilter *dss = vtkDataSetSurfaceFilter::New();
 dss-SetInputConnection(ps-GetOutputPort());

The dd object works fine and writing its contents out on each processor
gives nprocs worth of meshes, each of which look slightly different to the
way I've partitioned them up, but sum to the same serial mesh so I am happy
with that working correctly. But I can't for the life of me figure out how
to obtain local to global cell mappings, allocate ghost cells, or work out
how to exchange data given the above partition info and comms

Note I have not provided any additional information to dd regarding
global cells as per the doxy notes so I assume it went away and computed
it.  I can't figure out how to extract it however.  I also have no idea how
to modify each local processor rgrid to include the ghost cells for that
processor.  Finally given that info, I could exchange between processors to
write to each local processors ghost cells the corresponding real cell
data from the neighbouring meshes and continue the code.

Any help really appreciated!

Cheers,
Andy
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the ParaView Wiki at: 
http://paraview.org/Wiki/ParaView

Follow this link to subscribe/unsubscribe:
http://www.paraview.org/mailman/listinfo/paraview

Re: [Paraview] vtkDistributedDataFilter and ghost cells

[Andrew Parker]

Many thanks for this.

So I need to rethink my design such that I extend from a filter so I can
obtain the ghost cells?  There is no way to obtain them just from dd?

I can't do dd-GetGhostCells(processorNumber)?
or rgrid-AddGhostCells(dd)?

I know I can't do these last two, but that's kind of the thing I was
after

are there any other ways to do this?  Casting my current work in terms of a
filter is not going to be straight forward, although equally I'll have to
if this is the only wayso other ideas welcome.

Cheers again,
Andy

On 6 November 2012 16:00, Moreland, Kenneth kmo...@sandia.gov wrote:

   I believe vtkDistributedDataFilter will always return with global point
 ids (a mapping from local point ids to global point ids), although it might
 pass them if they already exist.  So
 dd-GetOutput()-GetPointData()-GetGlobalIds() should return the array
 that gives this mapping.

  Ghost cells are only created on demand, and this is usually done by
 pipeline convention.  If you have a filter that needs a layer of ghost
 cells, it should override the RequestUpdateExtent method to increment the
 value of UPDATE_NUMBER_OF_GHOST_LEVELS from the output information to the
 input information.  This method would look something like this.

   int vtkDistributedDataFilter::RequestUpdateExtent(
   vtkInformation *vtkNotUsed(request),
   vtkInformationVector **inputVector,
   vtkInformationVector *outputVector)
 {
   // get the info objects
   vtkInformation *inInfo = inputVector[0]-GetInformationObject(0);
   vtkInformation *outInfo = outputVector-GetInformationObject(0);

int piece, numPieces, ghostLevels;

// We require an extra layer of ghost cells from upstream.

piece =
 outInfo-Get(vtkStreamingDemandDrivenPipeline::UPDATE_PIECE_NUMBER());
   numPieces =

 outInfo-Get(vtkStreamingDemandDrivenPipeline::UPDATE_NUMBER_OF_PIECES());
   ghostLevels =
 outInfo-Get(
 vtkStreamingDemandDrivenPipeline::UPDATE_NUMBER_OF_GHOST_LEVELS());

inInfo-Set(vtkStreamingDemandDrivenPipeline::UPDATE_PIECE_NUMBER(),
 piece);
   inInfo-Set(vtkStreamingDemandDrivenPipeline::UPDATE_NUMBER_OF_PIECES(),
   numPieces);

 inInfo-Set(vtkStreamingDemandDrivenPipeline::UPDATE_NUMBER_OF_GHOST_LEVELS(),
   ghostLevels);

return 1;
 }


  The operation of the RequestData method should also strip off this layer
 of ghost cells.  It might be possible to request a layer of ghost cells by
 setting UPDATE_NUMBER_OF_GHOST_LEVELS at the bottom of the pipeline, but
 I'm not totally sure how to make that work.  It's probably easier (or at
 least cleaner) to do it from within a filter.

  -Ken

   From: Andrew Parker andy.john.par...@googlemail.com
 Date: Tuesday, November 6, 2012 8:25 AM
 To: vtkus...@vtk.org vtkus...@vtk.org, paraview@paraview.org 
 paraview@paraview.org
 Subject: [EXTERNAL] [Paraview] vtkDistributedDataFilter and ghost cells

   Hi,

  Hope you can help.  I have some code running in parallel, that by other
 means I have constructed nprocs worth of vtkRectilinearGrids, one per
 process.  Each of which is a valid nprocs-worth of the whole serial mesh,
 I've check this and I am happy with that i.e. it's partitioned properly and
 nothing is missing.  I need the following information to process my data in
 parallel:

  1) I would like the local - global cell mapping between the local rgrid
 and the corresponding global single mesh.
 2) I would like to know which cells are on processor boundaries for
 parallel exchange purposes.
 3) I would like all the double arrays per processor to be expanded by
 the amount of (1 level of) ghost cells such that I can properly do the
 computations I want with the ability to exchange only those additional
 cells given the local to global mapping.

  I have tried from the examples to use the following code, which I call
 on every process, each of which has it's own local rgrid as I said.  I do
 the following:

   vtkSmartPointervtkDistributedDataFilter dd =
 vtkSmartPointervtkDistributedDataFilter::New();
   dd-SetInput(rgrid);

  dd-SetController(getVtkController());
   dd-SetBoundaryModeToSplitBoundaryCells();
  //dd-SetBoundaryModeToAssignToOneRegion();
  //dd-SetBoundaryModeToAssignToAllIntersectingRegions();
  dd-UseMinimalMemoryOff();
  dd-Update();
   vtkPieceScalars *ps = vtkPieceScalars::New();
  ps-SetInputConnection(dd-GetOutputPort());
  ps-SetScalarModeToCellData();
   vtkDataSetSurfaceFilter *dss = vtkDataSetSurfaceFilter::New();
  dss-SetInputConnection(ps-GetOutputPort());

  The dd object works fine and writing its contents out on each processor
 gives nprocs worth of meshes, each of which look slightly different to the
 way I've partitioned them up, but sum to the same serial mesh so I am happy
 with that working correctly. But I can't for the life of me figure out how
 to obtain local to global cell mappings, allocate ghost cells, or work out
 how to exchange data given the above partition info and comms

  Note I have

Re: [Paraview] vtkDistributedDataFilter and ghost cells

[Andrew Parker]

Another question which I'd forgotten, how do I get to a vtkUnstructuredGrid
per processor from the vtkDistributedDataFilter.

For instance, dd-GetOutput()-GetPointData()-GetGlobalIds() doesn't work
as it's a vtkDataObject

Stupid question I'm sure but the doxy notes say this type returns an
unstructured mesh, but I can't seem to get it out?

Also, why exactly do I need the vtkPieceScalars and
vtkDataSetSurfaceFilter again?
If the above can be made to work and return the mapping, what are they
adding in terms of information?

Thanks again,
Andy

On 6 November 2012 16:00, Moreland, Kenneth kmo...@sandia.gov wrote:

   I believe vtkDistributedDataFilter will always return with global point
 ids (a mapping from local point ids to global point ids), although it might
 pass them if they already exist.  So
 dd-GetOutput()-GetPointData()-GetGlobalIds() should return the array
 that gives this mapping.

  Ghost cells are only created on demand, and this is usually done by
 pipeline convention.  If you have a filter that needs a layer of ghost
 cells, it should override the RequestUpdateExtent method to increment the
 value of UPDATE_NUMBER_OF_GHOST_LEVELS from the output information to the
 input information.  This method would look something like this.

   int vtkDistributedDataFilter::RequestUpdateExtent(
   vtkInformation *vtkNotUsed(request),
   vtkInformationVector **inputVector,
   vtkInformationVector *outputVector)
 {
   // get the info objects
   vtkInformation *inInfo = inputVector[0]-GetInformationObject(0);
   vtkInformation *outInfo = outputVector-GetInformationObject(0);

int piece, numPieces, ghostLevels;

// We require an extra layer of ghost cells from upstream.

piece =
 outInfo-Get(vtkStreamingDemandDrivenPipeline::UPDATE_PIECE_NUMBER());
   numPieces =

 outInfo-Get(vtkStreamingDemandDrivenPipeline::UPDATE_NUMBER_OF_PIECES());
   ghostLevels =
 outInfo-Get(
 vtkStreamingDemandDrivenPipeline::UPDATE_NUMBER_OF_GHOST_LEVELS());

inInfo-Set(vtkStreamingDemandDrivenPipeline::UPDATE_PIECE_NUMBER(),
 piece);
   inInfo-Set(vtkStreamingDemandDrivenPipeline::UPDATE_NUMBER_OF_PIECES(),
   numPieces);

 inInfo-Set(vtkStreamingDemandDrivenPipeline::UPDATE_NUMBER_OF_GHOST_LEVELS(),
   ghostLevels);

return 1;
 }


  The operation of the RequestData method should also strip off this layer
 of ghost cells.  It might be possible to request a layer of ghost cells by
 setting UPDATE_NUMBER_OF_GHOST_LEVELS at the bottom of the pipeline, but
 I'm not totally sure how to make that work.  It's probably easier (or at
 least cleaner) to do it from within a filter.

  -Ken

   From: Andrew Parker andy.john.par...@googlemail.com
 Date: Tuesday, November 6, 2012 8:25 AM
 To: vtkus...@vtk.org vtkus...@vtk.org, paraview@paraview.org 
 paraview@paraview.org
 Subject: [EXTERNAL] [Paraview] vtkDistributedDataFilter and ghost cells

   Hi,

  Hope you can help.  I have some code running in parallel, that by other
 means I have constructed nprocs worth of vtkRectilinearGrids, one per
 process.  Each of which is a valid nprocs-worth of the whole serial mesh,
 I've check this and I am happy with that i.e. it's partitioned properly and
 nothing is missing.  I need the following information to process my data in
 parallel:

  1) I would like the local - global cell mapping between the local rgrid
 and the corresponding global single mesh.
 2) I would like to know which cells are on processor boundaries for
 parallel exchange purposes.
 3) I would like all the double arrays per processor to be expanded by
 the amount of (1 level of) ghost cells such that I can properly do the
 computations I want with the ability to exchange only those additional
 cells given the local to global mapping.

  I have tried from the examples to use the following code, which I call
 on every process, each of which has it's own local rgrid as I said.  I do
 the following:

   vtkSmartPointervtkDistributedDataFilter dd =
 vtkSmartPointervtkDistributedDataFilter::New();
   dd-SetInput(rgrid);

  dd-SetController(getVtkController());
   dd-SetBoundaryModeToSplitBoundaryCells();
  //dd-SetBoundaryModeToAssignToOneRegion();
  //dd-SetBoundaryModeToAssignToAllIntersectingRegions();
  dd-UseMinimalMemoryOff();
  dd-Update();
   vtkPieceScalars *ps = vtkPieceScalars::New();
  ps-SetInputConnection(dd-GetOutputPort());
  ps-SetScalarModeToCellData();
   vtkDataSetSurfaceFilter *dss = vtkDataSetSurfaceFilter::New();
  dss-SetInputConnection(ps-GetOutputPort());

  The dd object works fine and writing its contents out on each processor
 gives nprocs worth of meshes, each of which look slightly different to the
 way I've partitioned them up, but sum to the same serial mesh so I am happy
 with that working correctly. But I can't for the life of me figure out how
 to obtain local to global cell mappings, allocate ghost cells, or work out
 how to exchange data given the above partition info and comms

  Note I have

Re: [Paraview] vtkDistributedDataFilter and ghost cells

[Andrew Parker]

Thanks on both accounts.  Any thoughts why the downcast called after
dd-Update() on distributedDataFilter is a null pointer?  As in, dd is
working perfectly properly, but I don't seem to be able to extract a valid
unstructuredgrid.  For a follow up question I assume
getPointData()-GetGlobalIds() gives the local to global for the mesh
nodes, and I should use getCellData()-GetGlobalIds() to get the local to
global for the cells?  Once I get a valid pointer that is

Cheers again,
Andy

On 6 November 2012 16:40, Moreland, Kenneth kmo...@sandia.gov wrote:

   You should be able to do a vtkUnstructuredGrid::SafeDownCast() to the
 data to get the unstructured mesh (and access to the point data).

  -Ken

   From: Andrew Parker andy.john.par...@googlemail.com
 Date: Tuesday, November 6, 2012 9:32 AM
 To: Kenneth Moreland kmo...@sandia.gov
 Cc: vtkus...@vtk.org vtkus...@vtk.org, paraview@paraview.org 
 paraview@paraview.org
 Subject: [EXTERNAL] Re: [Paraview] vtkDistributedDataFilter and ghost
 cells

   Another question which I'd forgotten, how do I get to a
 vtkUnstructuredGrid per processor from the vtkDistributedDataFilter.

  For instance, dd-GetOutput()-GetPointData()-GetGlobalIds() doesn't
 work as it's a vtkDataObject

  Stupid question I'm sure but the doxy notes say this type returns an
 unstructured mesh, but I can't seem to get it out?

  Also, why exactly do I need the vtkPieceScalars and
 vtkDataSetSurfaceFilter again? If the above can be made to work and
 return the mapping, what are they adding in terms of information?

  Thanks again,
 Andy

 On 6 November 2012 16:00, Moreland, Kenneth kmo...@sandia.gov wrote:

   I believe vtkDistributedDataFilter will always return with global
 point ids (a mapping from local point ids to global point ids), although it
 might pass them if they already exist.  So
 dd-GetOutput()-GetPointData()-GetGlobalIds() should return the array
 that gives this mapping.

  Ghost cells are only created on demand, and this is usually done by
 pipeline convention.  If you have a filter that needs a layer of ghost
 cells, it should override the RequestUpdateExtent method to increment the
 value of UPDATE_NUMBER_OF_GHOST_LEVELS from the output information to the
 input information.  This method would look something like this.

   int vtkDistributedDataFilter::RequestUpdateExtent(
   vtkInformation *vtkNotUsed(request),
   vtkInformationVector **inputVector,
   vtkInformationVector *outputVector)
 {
   // get the info objects
   vtkInformation *inInfo = inputVector[0]-GetInformationObject(0);
   vtkInformation *outInfo = outputVector-GetInformationObject(0);

int piece, numPieces, ghostLevels;

// We require an extra layer of ghost cells from upstream.

piece =
 outInfo-Get(vtkStreamingDemandDrivenPipeline::UPDATE_PIECE_NUMBER());
   numPieces =

 outInfo-Get(vtkStreamingDemandDrivenPipeline::UPDATE_NUMBER_OF_PIECES());
   ghostLevels =
 outInfo-Get(
 vtkStreamingDemandDrivenPipeline::UPDATE_NUMBER_OF_GHOST_LEVELS());

inInfo-Set(vtkStreamingDemandDrivenPipeline::UPDATE_PIECE_NUMBER(),
 piece);
   inInfo-Set(vtkStreamingDemandDrivenPipeline::UPDATE_NUMBER_OF_PIECES(),
   numPieces);

 inInfo-Set(vtkStreamingDemandDrivenPipeline::UPDATE_NUMBER_OF_GHOST_LEVELS(),
   ghostLevels);

return 1;
 }


  The operation of the RequestData method should also strip off this
 layer of ghost cells.  It might be possible to request a layer of ghost
 cells by setting UPDATE_NUMBER_OF_GHOST_LEVELS at the bottom of the
 pipeline, but I'm not totally sure how to make that work.  It's probably
 easier (or at least cleaner) to do it from within a filter.

  -Ken

   From: Andrew Parker andy.john.par...@googlemail.com
 Date: Tuesday, November 6, 2012 8:25 AM
 To: vtkus...@vtk.org vtkus...@vtk.org, paraview@paraview.org 
 paraview@paraview.org
 Subject: [EXTERNAL] [Paraview] vtkDistributedDataFilter and ghost cells

   Hi,

  Hope you can help.  I have some code running in parallel, that by other
 means I have constructed nprocs worth of vtkRectilinearGrids, one per
 process.  Each of which is a valid nprocs-worth of the whole serial mesh,
 I've check this and I am happy with that i.e. it's partitioned properly and
 nothing is missing.  I need the following information to process my data in
 parallel:

  1) I would like the local - global cell mapping between the local
 rgrid and the corresponding global single mesh.
 2) I would like to know which cells are on processor boundaries for
 parallel exchange purposes.
 3) I would like all the double arrays per processor to be expanded by
 the amount of (1 level of) ghost cells such that I can properly do the
 computations I want with the ability to exchange only those additional
 cells given the local to global mapping.

  I have tried from the examples to use the following code, which I call
 on every process, each of which has it's own local rgrid as I said.  I do
 the following

[Paraview] Compile Error 3.14.1 with gcc 4.7.1

[Andrew Parker]

Hi,

Using 4.7.1 I get the following compile error when compiling the 3.14.1
tag, it looks like the pointer type is unknown, possibly missing header?

[ 21%] Building CXX object
VTK/Rendering/CMakeFiles/vtkRendering.dir/vtkFreeTypeUtilities.cxx.o
opt/ParaView/VTK/Rendering/vtkFreeTypeUtilities.cxx: In function ‘FT_Error
vtkFreeTypeUtilitiesFaceRequester(FTC_FaceID, FT_Library, FT_Pointer,
FT_FaceRec_**)’:
opt/ParaView/VTK/Rendering/vtkFreeTypeUtilities.cxx:343:46: error: expected
type-specifier before ‘intptr_t’
opt/ParaView/VTK/Rendering/vtkFreeTypeUtilities.cxx:343:46: error: expected
‘’ before ‘intptr_t’
opt/ParaView/VTK/Rendering/vtkFreeTypeUtilities.cxx:343:46: error: expected
‘(’ before ‘intptr_t’
opt/ParaView/VTK/Rendering/vtkFreeTypeUtilities.cxx:343:46: error:
‘intptr_t’ was not declared in this scope
make[2]: ***
[VTK/Rendering/CMakeFiles/vtkRendering.dir/vtkFreeTypeUtilities.cxx.o]
Error 1
make[1]: *** [VTK/Rendering/CMakeFiles/vtkRendering.dir/all] Error 2
make: *** [all] Error 2

Any help appreciated?

Cheers,
Andy
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the ParaView Wiki at: 
http://paraview.org/Wiki/ParaView

Follow this link to subscribe/unsubscribe:
http://www.paraview.org/mailman/listinfo/paraview

Re: [Paraview] Compile Error 3.14.1 with gcc 4.7.1

[Andrew Parker]

Found a fix, posting here for others:

http://anonscm.debian.org/gitweb/?p=collab-maint/vtk.git;a=commitdiff;h=428e763c995bb303805e07da70c1a34fc103d208

Andy

On 18 June 2012 15:00, Andrew Parker andy.john.par...@googlemail.comwrote:

 Hi,

 Using 4.7.1 I get the following compile error when compiling the 3.14.1
 tag, it looks like the pointer type is unknown, possibly missing header?

 [ 21%] Building CXX object
 VTK/Rendering/CMakeFiles/vtkRendering.dir/vtkFreeTypeUtilities.cxx.o
 opt/ParaView/VTK/Rendering/vtkFreeTypeUtilities.cxx: In function ‘FT_Error
 vtkFreeTypeUtilitiesFaceRequester(FTC_FaceID, FT_Library, FT_Pointer,
 FT_FaceRec_**)’:
 opt/ParaView/VTK/Rendering/vtkFreeTypeUtilities.cxx:343:46: error:
 expected type-specifier before ‘intptr_t’
 opt/ParaView/VTK/Rendering/vtkFreeTypeUtilities.cxx:343:46: error:
 expected ‘’ before ‘intptr_t’
 opt/ParaView/VTK/Rendering/vtkFreeTypeUtilities.cxx:343:46: error:
 expected ‘(’ before ‘intptr_t’
 opt/ParaView/VTK/Rendering/vtkFreeTypeUtilities.cxx:343:46: error:
 ‘intptr_t’ was not declared in this scope
 make[2]: ***
 [VTK/Rendering/CMakeFiles/vtkRendering.dir/vtkFreeTypeUtilities.cxx.o]
 Error 1
 make[1]: *** [VTK/Rendering/CMakeFiles/vtkRendering.dir/all] Error 2
 make: *** [all] Error 2

 Any help appreciated?

 Cheers,
 Andy




-- 

__

   Dr Andrew Parker

   Em@il:  andrew.par...@cantab.net
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the ParaView Wiki at: 
http://paraview.org/Wiki/ParaView

Follow this link to subscribe/unsubscribe:
http://www.paraview.org/mailman/listinfo/paraview