Sometimes I think in VTK-terms where you can initialize a class and then set properties afterwards (r = vtk.vtkXdmfReader(); r.SetFileName('fname') or whatever) and it’s really frustrating to have it crash my current session.
I’m suggesting a check/catch be implemented in order to prevent this. I could potentially add this myself.
I believe the implementation would go into paraview.simple module similar to how an AttributeError is raised if you misspell a keyword, or a RuntimeError if you pass the argument without a keyword.
Am I on the right track? Any potential issues with this or additional insight?
I’m pretty surprised this doesn’t work. It may be that we can fix the crash, and allow this usage pattern.
If I create a source first, like s = Sphere(), the crash goes away because the source is automatically used as input to the Clip filter. Inside ParaView I’m not seeing r = XDMFReader() crash - it just prints errors. Clip and Slice are not checking that inputVector[0]->GetInformationObject(0) is non-null. Several other filters can be created, with errors.
Are you seeing other filters crash? I’d file an issue, and see what approach is recommended there.
@aron.helser I suppose using a filter like Clip() as the first item in a pipeline isn’t a great example, but nonetheless the behavior of “operation” filters is actually inconsistent. See below.
And I should add that before I was only testing with v5.9
I’ve tested with v5.10-RC1 now as well and the behavior is a little different.
As the first command in v5.9: XDMFReader() crashes Clip() crashes Threshold() outputs errors
As the first command in v5.10-RC1: XDMFReader() outputs errors Clip() crashes Threshold() outputs errors
