[Paraview] Catalyst and adaptor: attaching new fields

Michel Rasquin michel.rasquin at colorado.edu
Tue Oct 27 13:45:56 EDT 2015


Hi Andy,

Thank you for your quick answer.

You probably already read my previous answer about this issue.
The problem was located in NeedToCreateGrid(...), which also clears any field data associated with an existing grid.
The solution consists in calling simply this function only once for every new time step.

That said, you raised a good point about IsFieldNeeded(…), which was also on my radar.

I already observed that RequestDataDescription(datadescription) in the python script sets AllFields in the data description object to On. As a consequence, all the fields specified in the adaptor are passed to Catalyst since IsFieldNeeded() always returns true, whether the corresponding field is used in the Catalyst pipeline or not. Since we have improved our adaptor (we should commit it back now) and increased the number of fields we are potentially interest in for coprocesing purpose, this can indeed leads to additional memory usage and cpu time.

I definitely agree it would therefore be quite useful to have the possibility to request only the desired field variables through the IsFieldNeeded() function in the adaptor.
If you have any advice regarding this feature, I would be very interested in trying that out.

Thank you for your help!

Cheers,

Michel




On Oct 26, 2015, at 5:57 PM, Andy Bauer <andy.bauer at kitware.com<mailto:andy.bauer at kitware.com>> wrote:

Hi Michel,

You should be able to pass a single field at a time to Catalyst. I'm not sure where the problem is but my first guess is that maybe you're giving the same name to all of the fields. What does the code that's calling addfield() look like?

Note that the Catalyst API uses things like idd->IsFieldNeeded("pressure") to check if a field is needed by the pipeline. This has been in the API since nearly the beginning but we've never had a chance to generate Python scripts which can take advantage of loading only desired fields. This can potentially save on both execution time and memory usage. This is on my radar again but I'm not sure when it will get done. You can modify the Python scripts though to just request the desired field variables in the RequestDataDescription() method and everything should work as desired. Let us know if you want to try that out and need help with it.

Cheers,
Andy

On Mon, Oct 26, 2015 at 11:22 AM, Michel Rasquin <michel.rasquin at colorado.edu<mailto:michel.rasquin at colorado.edu>> wrote:
Hi everyone,

I am trying to add some fields to a vtkCPAdaptorAPI object for coprocessing with Catalyst.
I rely for that purpose on the successful implementation of the Phasta adaptor provided along with ParaView.
See ParaView-v4.4.0-source/CoProcessing/Adaptors/PhastaAdaptor/PhastaAdaptor.cxx.
After the initialization of the coprocessing objects and the generation of the grid, the current implementation to add fields in the phasta adaptor relies on the following function:

void addfields(… double* dofArray, double* vortArray, double * otherFieldOfInterest … )
{
  vtkCPInputDataDescription* idd = vtkCPAdaptorAPI::GetCoProcessorData()->GetInputDescriptionByName("input”);
  vtkUnstructuredGrid* UnstructuredGrid = vtkUnstructuredGrid::SafeDownCast(idd->GetGrid());
  if(!UnstructuredGrid) {
    vtkGenericWarningMacro("No unstructured grid to attach field data to.");
    return;
  }

  // now add numerical field data
  //velocity
  vtkIdType NumberOfNodes = UnstructuredGrid->GetNumberOfPoints();
  if(idd->IsFieldNeeded("velocity"))
  {
    vtkDoubleArray* velocity = vtkDoubleArray::New();
    velocity->SetName("velocity");
    velocity->SetNumberOfComponents(3);
    velocity->SetNumberOfTuples(NumberOfNodes);
    for (vtkIdType idx=0; idx<NumberOfNodes; idx++) {
      velocity->SetTuple3(idx, dofArray[idx],
                          dofArray[idx+ *nshg],
                          dofArray[idx+ *nshg*2]);
    }
    UnstructuredGrid->GetPointData()->AddArray(velocity);
    velocity->Delete();
  }

  if(idd->IsFieldNeeded(“vorticity"))
  {
    vtkDoubleArray* vorticity = vtkDoubleArray::New();
    velocity->SetName(“vorticity");
    velocity->SetNumberOfComponents(3);
    velocity->SetNumberOfTuples(NumberOfNodes);
    for (vtkIdType idx=0; idx<NumberOfNodes; idx++) {
      velocity->SetTuple3(idx, vortArray[idx],
                          vortArray[idx+ *nshg],
                          vortArray[idx+ *nshg*2]);
    }
    UnstructuredGrid->GetPointData()->AddArray(vorticity);
    vorticity->Delete();
    }

  // etc for any the other fields of interest for Catalyst
}

Currently, all the fields requested for coprocessing needs to be attached in this function at the same time, using the same pointer to vtkUnstructuredGrid resulting from the SafeDownCast mentioned above. However, I need a more flexible implementation so that I can call addfield (with no “s”) as many times as needed and attach a single field to the vtkCPAdaptorAPI object each time this function is called.

Concretely, my first implementation is simply the following:

void addfield(std::string fieldName, int* NumberOfComp, double* fieldArray)
{
  vtkCPInputDataDescription* idd = vtkCPAdaptorAPI::GetCoProcessorData()->GetInputDescriptionByName("input");
  vtkUnstructuredGrid* UnstructuredGrid = vtkUnstructuredGrid::SafeDownCast(idd->GetGrid());
  if(!UnstructuredGrid) {
    vtkGenericWarningMacro("No unstructured grid to attach field data to.");
    return;
  }

  // Get number of nodes
  vtkIdType NumberOfNodes = UnstructuredGrid->GetNumberOfPoints();

  // Add field
  if(idd->IsFieldNeeded(fieldName.c_str())) {
    vtkDoubleArray* dataArray = vtkDoubleArray::New();
    dataArray->SetName(fieldName.c_str());
    dataArray->SetNumberOfComponents(*NumberOfComp);
    dataArray->SetNumberOfTuples(NumberOfNodes);
    // fill in dataArray from fieldArray, NumberOfNodes and NumberOfComp
    …
    UnstructuredGrid->GetPointData()->AddArray(dataArray);
    dataArray->Delete();
  }
}

The problem is that only the last field passed to this new addfield() function can be actually used by Catalyst for coprocessing.
Indeed, it appears that all other fields previously passed to addfield() cannot be retrieved from the vtkCPAdaptorAPI object.
Consequently, any filter in the Catalyst pipeline that relies on the N-1 first fields (out of N in total) passed to addfields() will be ignored because relevant data is missing.

I suspect the issue is in one of the first two lines of the addfield() function, namely

  vtkCPInputDataDescription* idd = vtkCPAdaptorAPI::GetCoProcessorData()->GetInputDescriptionByName("input");
  vtkUnstructuredGrid* UnstructuredGrid = vtkUnstructuredGrid::SafeDownCast(idd->GetGrid());

Could you please let me know if it is possible to pass one single field at a time to the Catalyst adaptor from different locations of the code, or if all the fields must be passed in one shot?

Thank you for your help.

Best regards,

Michel



_______________________________________________
Powered by www.kitware.com<http://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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview/attachments/20151027/838f2f49/attachment.html>


More information about the ParaView mailing list