Remove test_post_processing

[davidrudlstorfer]

Each and every single time something in the tests is updated or changed problems arise from the four_c_test_post_processing tests.

Currently the following 18 tests still use this feature:

four_c_test_post_processing(constr3D_MPC_direct.4C.yaml 2 2 ndxyz ndxyz 25)
four_c_test_post_processing(contact2D_onlylin_stdlagr.4C.yaml 2 2 ndxyz ndxyz 50)
four_c_test_post_processing(contact2D_simpler.4C.yaml 2 2 ndxyz ndxyz 50)
four_c_test_post_processing(contact3D_pwlin_penalty_hex20.4C.yaml 2 2 ndxyz ndxyz 10)
four_c_test_post_processing(contact3D_pwlin_penalty_hex27.4C.yaml 2 2 ndxyz ndxyz 10)
four_c_test_post_processing(orthopressure_solidw6.4C.yaml 2 2 ndxyz ndxyz 10)
four_c_test_post_processing(poro_3D_hex8.4C.yaml 2 2 ndxyz ndxyz 10 "_porofluid" "")
four_c_test_post_processing(poro_3D_hex8_new_struc.4C.yaml 2 2 ndxyz ndxyz 10 "_porofluid" "")
four_c_test_post_processing(soshw6_thin_nonlinear_pinched_hemisphere.4C.yaml 2 2 ndxyz ndxyz 20)
four_c_test_post_processing(sotet10_cooks_nl.4C.yaml 2 2 ndxyz ndxyz 100)
four_c_test_post_processing(strufem_tet10_disp_cantilever.4C.yaml 2 2 ndxyz ndxyz 30)
four_c_test_post_processing(strufem_tet4_disp_cantilever.4C.yaml 2 2 ndxyz ndxyz 30)
four_c_test_post_processing(strufem_wedge6_disp_cantilever.4C.yaml 2 2 ndxyz ndxyz 30)
four_c_test_post_processing(w1q4_cantilever_eas.4C.yaml 2 2 ndxyz ndxyz 1)
four_c_test_post_processing(w1q4_patch_eas.4C.yaml 2 2 ndxyz ndxyz 1)
four_c_test_post_processing(w1q8_patch_nonlinear.4C.yaml 2 2 ndxyz ndxyz 1)
four_c_test_post_processing(w1q9_dyn_rot_drt_gena.4C.yaml 2 2 ndxyz ndxyz 100)
four_c_test_post_processing(w1t6_patch_linear.4C.yaml 2 2 cxyz cxyz 1)

With the move to runtime output do we really still need this testing feature? Some of the above mentioned tests are already in the new structure framework.

The deletion of this testing feature would allow us to remove the entire PVPython dependence of 4C as well as the packaged Paraview version in the image.

We already talked about this a lot but maybe now is the time to finally drop these tests.

[davidrudlstorfer]

Also see #93

[mayrmt]

I think that this is closely tied to the move to run-time output. However, there hasn't been much progress lately, so various fields still rely on the existence (an the testing) of the post-filter.

If we complete the migration to run-time output, the post-filter tests will go away naturally.

[maxfirmbach]

Is there an overview issue what needs to be done regarding the run-time output (e.g. which modules need to be ported)? And more importantly, is it up to date? That would be nice to have.

[davidrudlstorfer]

Can be found here #211

[c-p-schmidt]

#211 (comment)

[maxfirmbach]

Ah perfect :D.

[davidrudlstorfer]

Closing this discussion - PVPython was removed with #1358 and #1362 by @amgebauer - thanks!