@charly_bollinger In which context do you intend to use these process ids to synchronize data? Do you intend to make vtkGhostCellsGenerator use this array if present to move around cell and point data? Or do you intend to use it within a few filters that might require synchronization, and just write a utility synchronizing ghosts? (It should possibly also update the point positions if a filter moves points upstream, assuming that the topology hasn’t changed).
Usually, it doesn’t matter if all the data across ranks is not 100% similar, as long as the amount of required ghost layers to process something are similar across ranks. So if someone worries about not having to recompute ghosts all the time, he needs to compute the required number of ghosts so at the end of the pipeline, all non ghost data has the correct value. If you have a vtkGradient in the pipeline, you should have one layer. If you cascade 2 vtkGradient, you need 2 layers.
In theory there is a key information to propagate the number of ghosts to compute from the source (UPDATE_NUMBER_OF_GHOST_LEVELS()) that should propagate upstream to tell the source how many layers of ghosts are needed downstream. I don’t believe this key is really used, and possibly it would be nice to be able from vtkStreamingDemandDrivenPipeline to invoke vtkGhostCellsGenerator when the source hasn’t generated the requested ghosts. It would let the user not have to worry about how many ghost each filter requires.
Nevertheless, I think that a new assigned array or vtkDataSetAttributes that stores process ids won’t hurt. I’m all for it.