Missing FieldData after setting mesh with sensei::VTKDataAdaptor::SetDataObject

SENSEI
1

Hi there,

I have recently added a SENSEI interface to our solver, based on a working CATALYST interface.

I have refactored an existing Catalyst-Solver interface so that the code to create the VTK data structure and updating the fields in unsteady simulations is coded only once. I have then created the solver_sensei_bridge code using the sensei::VTKDataAdaptor class. As a result I have 2 separate executables of my solver, one with Catalyst, one with Sensei interface. Both can write in-situ output (point and cell data) for multiple time steps, which is identical regardless whether I use the Catalyst or the Sensei interface.

However when I add some field data (let’s say the current time step as a double value) to each block in a multiblock hierarchy, with Catalyst, those FieldData entries show up in the co-processing results, but with SENSEI they are silently dropped somewhere. I read through the SENSEI source code, but can’t find any reason why they are dropped. It looks like the Catalyst interface is doing some copying, which the Sensei interface does not. I saw some ParaView version dependent code in SENSEI that looked like the place where the VTK dataset is shallow copied

auto mesh = solverDataAdaptor->GetMesh(config, *time);
dataAdaptor->SetDataTime(*time);
dataAdaptor->SetDataTimeStep(*step);
dataAdaptor->SetDataObject("input", mesh);

Above, mesh has proper Point, Cell, and Field data, but the FieldData never shows up when running scripts in sensei.

This happend with Sensei 3.1.0 and I have tried PV 5.4 and PV 5.6.

So my questions are:

  • Should this work for FieldData as it does for Point and Cell data?
  • Can I fix this from outside or is a change in SENSEI required?
  • Is there maybe a recommended version combination between ParaView and SENSEI, where this actually works?

Many thanks for any hints,
Axel

2

Hi @axel.gerstenberger,

With Sensei 3.1.0, your simulation should provide its own DataAdaptor class that inherits sensei::DataAdaptor and overrides DataAdaptor::GetMeshMetadata. The mesh metadata should allow you to advertise field data as well as point and cell data with ParaView 5.6 or 5.8. If you use ParaView 5.5 or older and are advertising a field-data array, you should see an “Unknown association” warning (emitted from around line 106 in sensei/CatalystAnalysisAdaptor.cxx of the Sensei source code).

Can you verify that your mesh metadata lists the field-data array? If so, it may also be that you need to configure your catalyst pipeline to request the array; presumably you have sensei’s configurable analysis set to use catalyst with pipeline="pythonscript", so your python script must either ask for the field-data array by name or call datadescription.GetInputDescription(xxx).AllFieldsOn() for the relevant input description inside the python RequestDataDescription() function.

3

Hi David,

thanks for the quick response.

Good to know that Sensei 3.1 and PV 5.6+ should work together, I will concentrate on those versions. I’m also quite sure that I have proper point, cell, and field data - I write out .vtm files during co-processing runs and check for existence and values of my arrays using unit-tests. The tests are identical for Catalyst and Sensei executables and only in the Sensei run, the Field Data is missing. The same is happens, if I connect live to each run using ParaView - the FieldData is missing in the Sensei version.

From my understanding, sensei::VTKDataAdaptor is the class that inherits sensei::DataAdapter and that you proposed to write. It is a convenience class, if one already has a proper vtkDataObject. Is that correct? And I can just give it my vtkDataObject and it will then answer using its GetMeshMetaData implementation based on my mesh. All my blocks in my vtkMultiBlockDataSet have the same field data, so from the documentation, the first block should be able to answer all questions: https://sensei-insitu.readthedocs.io/en/rtd_user_guide/rtd-docs/reference/sensei/html/classsensei_1_1VTKDataAdaptor.xhtml#details

I have checked my catalyst Python scripts (autogenerated using ParaView 5.4.1) and they have this block:

def RequestDataDescription(datadescription):
  "Callback to populate the request for current timestep"
  global coprocessor
  if datadescription.GetForceOutput() == True:
    # We are just going to request all fields and meshes from the simulation
    # code/adaptor.
    for i in range(datadescription.GetNumberOfInputDescriptions()):
        datadescription.GetInputDescription(i).AllFieldsOn()
        datadescription.GetInputDescription(i).GenerateMeshOn()
    return

# setup requests for all inputs based on the requirements of the
# pipeline.
coprocessor.LoadRequestedData(datadescription)

So it should request all fields as you suggested - but is seems not to be enough. Ideally, I want to make sure (if possible already in the C++ code) that all data from the mesh is visible in the coprocessing run, as our post-processing filters that we now use in co-processing just assume all data is there. Asking for arrays on demand is something our filters can not handle right now.

I suspect that something in sensei::VTKDataAdaptor needs to change to make my FieldData not disappear, but I have looked at the code and don’t see what I could try to fix it.

Any further ideas?

Thanks,
Axel

4

Just a thought: Following what sensei::VTKDataAdaptor is doing, it will at some point try to find out what arrays are on one or all vtkDataSets of my multiblock data structure. And it uses a method in VTKUtils.cxx named GetArrayMetadata

int GetArrayMetadata(vtkDataSet *ds, MeshMetadataPtr &metadata)
{
  VTKUtils::GetArrayMetadata(ds->GetPointData(), vtkDataObject::POINT,
    metadata->ArrayName, metadata->ArrayCentering, metadata->ArrayComponents,
    metadata->ArrayType, metadata->ArrayRange, metadata->NumGhostNodes);

  VTKUtils::GetArrayMetadata(ds->GetCellData(), vtkDataObject::CELL,
    metadata->ArrayName, metadata->ArrayCentering, metadata->ArrayComponents,
    metadata->ArrayType, metadata->ArrayRange, metadata->NumGhostCells);

  metadata->NumArrays = metadata->ArrayName.size();

  return 0;
}

Here, it looks like vtkDataObject::FIELD is not used and other types like POINT_THEN_CELL, VERTEX, EDGE, ROW, are not considered either. Just wondering if that makes a difference. It is somewhat hard to follow all the inheritance and overloading, so this is just a guess.

Axel

5

I agree this looks like a bug. I will submit a fix in the next day or so.