[Paraview] ParaView 3.8.1 and HDF5

[Biddiscombe, John A.]

Nathalie



We use a customized vtkXdmfWriter which is inside the Icarus plugin. The writer is a subclass of the one in paraview and overrides a number of methods to

a) set the DSM manager etc

b) handle parallel writes properly using an H5MB utility that's also in there. This hooks into the callback mechanism of (the modified) Xdmf writing to delay creation of groups/datasets/etc until all processes have exchanged info (done in the H5MB utility).



It should write to DSM very nicely. I think we have a test somewhere which creates a DSM on nodes and writes to it using the writer. Maybe this test got squashed at some time.



Look in Icarus/DSMManager for the XdmfWriter classes. It may be that many fixes on the main branch that you are using don't exist. For writing to the DSM from paraview using Xdmf, the steering branch is the one to use, but we haven't made it public yet. we're trying to write it all up and submit it for publication, once that's done, we'll move the steering branch onto the public repo.



in Icarus/DSMManager key code is in XdmfH5MBCallback (the callback stuff that creates a tree from all nodes writing, then synchronizes them so collective dataset creates happen correctly - even when nodes are writing nothing). H5MB, the tree code used by above. The writer we use is XdmfWriter4 : see this snippet from the latest version which writes for us. Using this we can have paraview running on one set of nodes, write data into the DSM, and have it appear in another paraview session somewhere else using a shared DSM! This was our first bi-directional test of the DSM within paraview. For writing data into the simulation from paraview, we have more specialized HDF5 write code since the XdmfWriter carries a lot of baggage - (it does however handle early all vtk data types).



On another note : if you are only wanting live visualization, you might want to check out the coprocessing stuff, it is much easier to get working without documentation! Ours was intended for HDF5 enabled apps that want birectional communication, if you really need this, then we should take this off list an collaborate properly to get you going. (next week - not this!)





JB

One catch - the modified XdmfWriter does something unusual - it creates one dataset per process writing, so that parallel writes go into their own pieces - we wanted to preserve the spatial separation (decomposition) of data when writing in parallel - I'm actually changing this because for one current project we want a flat dataset combined using hyperslabs - not multiple blocks....anyway


//-----------------------------------------------------------------------------
// writes the currently selected object int the paraview GUI into the DSM
// using XdmfWriter in parallel
void pqDSMViewerPanel::onWriteDataToDSM()
{
  if (this->DSMReady()) {
    if (!this->Internals->ActiveSourceProxy) {
      vtkGenericWarningMacro(<<"Nothing to Write");
      return;
    }
    //
    vtkSMProxyManager* pm = vtkSMProxy::GetProxyManager();
    vtkSmartPointer<vtkSMSourceProxy> XdmfWriter =
      vtkSMSourceProxy::SafeDownCast(pm->NewProxy("icarus_helpers", "XdmfWriter4"));
    XdmfWriter->SetConnectionID(pqActiveObjects::instance().activeServer()->GetConnectionID());

    // Delete our reference now and let smart pointer clean up later
    XdmfWriter->UnRegister(NULL);

    pqSMAdaptor::setProxyProperty(
      XdmfWriter->GetProperty("DSMManager"), this->Internals->DSMProxy);

    pqSMAdaptor::setElementProperty(
      XdmfWriter->GetProperty("FileName"), "stdin"); // dummy non null filename, DSM is used

    pqSMAdaptor::setInputProperty(
      XdmfWriter->GetProperty("Input"),
      this->Internals->ActiveSourceProxy,
      this->Internals->ActiveSourcePort
      );

    XdmfWriter->UpdateVTKObjects();
    XdmfWriter->UpdatePipeline();
  }

}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.paraview.org/pipermail/paraview/attachments/20110119/79ca7265/attachment-0001.htm>