We commented out the entire if-else clause for the RT data and it seems to do what it is supposed to do, even without the special conditions. Need to check that in more detail.

Pushed new branch to rMITK MITK: bugfix/T28455-rt-struct-3d-visibility.

Discussed it in the MITK meeting:

I narrowed it down.

If you load a RTStruct via DICOMBrwoser, the node has a special "visible" property for stdmulti.widget3 (the 3D view). You can enable/disbale it via the Properties plugin. #Workaround :-P

Ok, we tested it on several machines and it is as described above: After loading via DICOM Browser we can confirm the issue.

@s434n and I tried this on Windows and Linux. It looks like, if you load the data via "classical drag'n'drop", it works as expected. If we use the DICOM browser to load the exact same dataset, we can reproduce @nolden's issue.

Sure, here it is:
https://phabricator.mitk.org/rOBSHYPPOPYa340b927d14acdef69cea4e64b92524270066920

Your argument makes sense to me. I did not have a specific order in mind when implementing it, so I do not have any counterargument here.

Forgot something and didn't request review correctly. I will open this one agian.

I updated the draft in the branch directly (same file).

fixed in https://github.com/MIC-DKFZ/Hyppopy/tree/fix/T28410-direct-call-of-blackbox-internal

I agree with the raised point. I checked the classes again and do not see a valid reason behind the blackbox_func call. I will fix this.

Sorry, I was on vacation.

The auto wrapping functionality for MPISolverWrapper looks correct and straightforward to me. A check for function type is already included in the HyppopySolver.

I agree. As we already said, we have to work on the mpiplayground anyways and convert it into a propper mpi_example. I will spawn a task for that and include your suggestion there.

In rOBSHYPPOPY1358b14d22f999ffcb9b8d1dbe7d8adfac020ef6#167883, @floca wrote:

@kleina I think you should move the mpi playground stuff away from the top level. Examples would be better suited. Don't you think?

That makes a lot of sense. I personally like the idea of a "optional dependency" better. I will have a look.