VTK pipeline performance and ghost cells

Development
1

Here is how the VTK pipeline handles ghost cells.

  • Source can produce data with up to N level of ghost cells
  • Filter request M level of ghost cells
  • During the RequestUpdateExtent pass, M is forwarded to the Source
  • During the RequestData pass, Source produce M level of ghost cells

This working very well when you update the pipeline only once and M never changes, but in complex application, it is almost always never the case. ParaView comes to mind.

Here is what happens if M changes over time for any reason, eg in ParaView:

  • Source can produce data with up to N level of ghost cells
  • Filter1 request N level of ghost cells
  • Filter2 request M (>N) level of ghost cells
  • ParaView create the Source and update the pipeline, no ghost cells were requested, none were produced
  • Filter1 is added, ParaView update the pipeline, N is forwarded and the source needs to reexecute
  • There is no way around it, this is what should be done
  • Filter2 is added, ParaView update the pipeline, M is forwarded and the source execute again but it still generate N level of ghost cells as it cant generate more than that.
  • This is a useless execution

If source (and filters for that matter) could declare the maximum number of ghost cells they can produce during the RequestInformation pass, the pipeline could take that into account and skip the Source execution altogether.

2

@Yohann_Bearzi @berk.geveci @Charles_Gueunet @jfausty

3

Do sources really have a limit on the number of ghosts they can produce? Assuming you have a source you cannot have more than N levels of ghosts, why not override UPDATE_NUMBER_OF_GHOSTS in RequestUpdateExtent with N when someone requests more than N ghosts?

4

Readers definitely do, they can produce what the file contains. Of course, Infinite should also be a valid answer.

why not override UPDATE_NUMBER_OF_GHOSTS in RequestUpdateExtent with N when someone requests more than N ghosts?

This is what is done, but its already too late, once you are in RequestUpdateExtent, you are going the full RequestData ride, with all filters in between.

5

I guess you could add an optional information key to be set by the source. Default behavior should remain infinity, it would be an opt-in option.