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();
}
}
_______________________________________________
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
