Optimization on meshes with cutting planes

[jadie1]

When you optimize on meshes with cutting planes, optimization seemingly freezes after initialization. No error is thrown but it gets stuck.

To test:

• unzip test.zip
• cd into test
• run: shapeworks optimize --name correspondence_1024.xml

Note that if the cutting plane is removed from the xml, optimization runs as expected.

[akenmorris]

Excellent bug report @jadie1 , small dataset included and instructions to reproduce.

@HeavenlyBerserker , for reference, it's stuck here:

Call graph:
    5 Thread_5215217   DispatchQueue_1: com.apple.main-thread  (serial)
    + 5 start  (in libdyld.dylib) + 1  [0x7fff69ef2cc9]
    +   5 main  (in shapeworks) + 2606  [0x102bfb9fe]  shapeworks.cpp:88
    +     5 shapeworks::Executable::run(int, char const* const*)  (in shapeworks) + 188  [0x102c0ad7c]  Executable.cpp:128
    +       5 shapeworks::Executable::run(std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > >, shapeworks::SharedCommandData&)  (in shapeworks) + 308  [0x102c0a6f4]  Executable.cpp:94
    +         5 shapeworks::Command::run(shapeworks::SharedCommandData&)  (in shapeworks) + 20  [0x102c14e64]  Command.cpp:27
    +           5 shapeworks::OptimizeCommand::execute(optparse::Values const&, shapeworks::SharedCommandData&)  (in shapeworks) + 921  [0x102c16889]  Commands.cpp:92
    +             5 shapeworks::Optimize::Run()  (in shapeworks) + 1938  [0x102ea5d52]  Optimize.cpp:120
    +               5 shapeworks::Optimize::Initialize()  (in shapeworks) + 1770  [0x102ea7d3a]  Optimize.cpp:733
    +                 1 itk::ParticleSystem<3u>::AdvancedAllParticleSplitting(double)  (in shapeworks) + 2133  [0x102eb46f5]  itkParticleSystem.txx:330
    +                 1 itk::ParticleSystem<3u>::AdvancedAllParticleSplitting(double)  (in shapeworks) + 2542  [0x102eb488e]  itkParticleSystem.txx:344
    +                 ! 1 itk::Constraints::IsAnyViolated(itk::Point<double, 3u> const&)  (in shapeworks) + 71  [0x102ecce67]  Constraints.h:61
    +                 1 itk::ParticleSystem<3u>::AdvancedAllParticleSplitting(double)  (in shapeworks) + 2530  [0x102eb4882]  itkParticleSystem.txx:344
    +                 1 itk::ParticleSystem<3u>::AdvancedAllParticleSplitting(double)  (in shapeworks) + 3010  [0x102eb4a62]  itkParticleSystem.txx:349
    +                 1 itk::ParticleSystem<3u>::AdvancedAllParticleSplitting(double)  (in shapeworks) + 1655  [0x102eb4517]  vector:0

[HeavenlyBerserker]

I second the quality of this bug report. I've looked at the problem. Thanks for checking on this, Alan.

The AdvancedAllParticleSplitting function will hang if none of the particles going in any direction by a certain radius (distance from the split particle to the original particle) satisfies the constraints. I thought about limiting the number of directions attempted, but decided against it because depending on the cutting planes, it can be that a hit is extremely rare, so any constant number might be ill-suited. I'm open to suggestions to handle this, although if the current work I'm doing pans out, AdvancedAllParticleSplitting won't be strictly necessary so we can discuss completely different particle splitting strategies.

As for the test itself, this is happening because of the positioning of the meshes. The cutting planes cut at z = -40.5 to -42.5, but the meshes are positioned at z = -737.593 to -609.55, -1217.76 to -1114.47, and 1079.93 to 1206.3 (shown below). This causes two problems. First, regardless of which way the normal is pointing (up/down), there will be at least one femur that completely violates the constraints. Second, the particle splitting radius is determined by a quantity epsilon, dependent on the spacing of the input; in this case, the spacing is in the 1000s, making any split likely to violate the constraints.

As a note, the femora you are using have already been cut using the clipping method. I don't think this would be done in a real scenario. Recall how I removed ClipBinaryVolumes and applyCropping for femur_cut.py.

Please assign me to any future issues regarding cutting planes (within C++). I have not tested the cutting plane's code with meshes. There isn't any reason it shouldn't work, but it'd be good to test it for bugs. Thanks, y'all!

[jadie1]

@HeavenlyBerserker oh okay, so in theory if the meshes and cutting planes made sense then the bug would not exist? Joe needs to optimize with cutting planes on unclipped femur meshes, I was trying to provide him with an example xml. So I just made up cutting planes and used femur meshes, but if I am more careful about it then it should work?

[HeavenlyBerserker]

Yes, I tried cutting planes that don't get violated but ran into the spacing problem, but it works. If you can put all the femora in the same general area and adjust the cutting planes to be reasonable, I see no reason this shouldn't work, especially considering you're only using one cutting plane.

[jadie1]

Okay yep confirmed no bug when I used this data: test.zip

Thanks for helping me understand @HeavenlyBerserker
Closing this now

[cchriste]

I have not tested the cutting plane's code with meshes. There isn't any reason it shouldn't work, but it'd be good to test it for bugs.

We've chopped up some meshes successfully and there are unit tests for this (MeshTests, PythonTests, and shapeworksTests).

Please assign me to any future issues within C++.

Absolutely! Thank you!!

[akenmorris]

@HeavenlyBerserker , is there any way this condition can be detected and an exception raised or error message? I would really prefer that to hanging or crashing. Also, is there a way we can verify prior to running? See #910 .

[HeavenlyBerserker]

Hmm, it should be possible to check if at least one of the mesh/image points of any input satisfies the constraint. Not fool-proof, but should work 99.9% of the time.