# Getting rid of modules FiltersParallelDIY2 and FiltersParallel?

**URL:** <https://discourse.vtk.org/t/getting-rid-of-modules-filtersparalleldiy2-and-filtersparallel/13972>\
**Category:** Development\
**Created:** [June 3, 2024, 7:59pm UTC](https://discourse.vtk.org/t/getting-rid-of-modules-filtersparalleldiy2-and-filtersparallel/13972 "2024-06-03T19:59:28Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Yohann\_Bearzi](https://discourse.vtk.org/user_avatar/discourse.vtk.org/yohann_bearzi/32/671_2.png) [@Yohann\_Bearzi](https://discourse.vtk.org/u/Yohann_Bearzi)\
**Post date:** [June 3, 2024, 7:59pm UTC](https://discourse.vtk.org/t/getting-rid-of-modules-filtersparalleldiy2-and-filtersparallel/13972/1 "2024-06-03T19:59:29Z")

</div>

The current module architecture around filters using DIY necessitates placing these filters in `FiltersParallelDIY2` or in a module for which `FiltersParallelDIY2` doesn’t depend on, to avoid cyclic dependencies. Some filters that require DIY may however have other dependencies (such as `FiltersTexture`). There can be dependencies within `FiltersTexture` that rely on `FiltersParallelDIY2` (for example, `vtkGenerateGlobalIds`, a general filter that uses DIY). When encountering this kind of interdependency, a filter intended for `FiltersTexture` but using `vtkGenerateGlobalIds` must be placed in `FiltersParallelDIY2` even if it seems illogical. This module arrangement segments filters based on their parallel backend requirements, particularly in a multi-process context.

I believe categorizing filters based on their “parallelness” is irrelevant. They should be organized based on the type of operation they perform more fundamentally. The current module structure likely stems from an outdated division between regular filters and their parallel subclasses (the “P” filters). This distinction is obsolete because filters can now include a `vtkMultiProcessController` without requiring MPI to be enabled in the build, functioning instead with a `vtkDummyController`. Several filters already operate this way (`vtkGhostCellsGenerator`, `vtkGenerateGlobalIds`, etc.), needing only access to the `vtkMultiProcessController` interface and potentially DIY, which performs well without MPI.

Maintaining the current infrastructure will lead to more arbitrary filters, without obvious parallel components, ending up in `FiltersParallel` or `FiltersParallelDIY2`. This situation already exists to some extent, with diverse filter types in these modules that might fit better elsewhere. The cyclic dependencies force these filters into these modules by default.

I propose establishing a base infrastructure that supports multi-process communication without relying on a module containing parallel-specific filters. Essentially, we should consider making DIY a more core component, allowing any filter to access it without creating cycles, and have `ParallelCore` also “more core” (which includes `vtkMultiProcessController`). We should then reassign the filters currently in `FiltersParallel` and `FiltersParallelDIY2` to more appropriate modules.

I seek feedback on this concern. Have I overlooked any factors that would make this change problematic? Is there a better approach?

---

<div class="post-metadata">

**Author:** ![ben.boeckel](https://discourse.vtk.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)\
**Post date:** [June 3, 2024, 8:15pm UTC](https://discourse.vtk.org/t/getting-rid-of-modules-filtersparalleldiy2-and-filtersparallel/13972/2 "2024-06-03T20:15:08Z")

</div>

As a compatibility layer, we should keep the associated targets (`VTK::FiltersParallel`) and Python modules (`vtkmodules.vtkFiltersParallel`) existing, but in a deprecated state while providing the classes that have relocated (Python can be exact with re-exports, but CMake is going to end up exposing the entire module that provides a moved class). This would involve some module work to tell wrappers what to do and to make the targets depend on the moved-to modules.

---

<div class="post-metadata">

**Author:** ![mwestphal](https://discourse.vtk.org/user_avatar/discourse.vtk.org/mwestphal/32/19_2.png) [@mwestphal](https://discourse.vtk.org/u/mwestphal)\
**Post date:** [June 4, 2024, 7:47am UTC](https://discourse.vtk.org/t/getting-rid-of-modules-filtersparalleldiy2-and-filtersparallel/13972/3 "2024-06-04T07:47:24Z")

</div>

I agree that the situation with that module is problematic and any steps taken to resolve the issue is good.

Retrocompatibility is paramount though.