Topology optimization with homogenized level set

[manavbhatia]

-- Added a new example (structural example 8) that uses the homogenized level-set based for topology optimization.
-- Modified Nastran example to be enabled only if ENABLE_NASTRANIO is set.

[manavbhatia]

@jdeaton This influences mast_config.h here. I put this in since I wanted to be able to compile Mast without NastranIO support (which needs python).
So, if we are disabling this feature, then the respective source/header files and example7 becomes conditional, which uses this variable from mast_config.in exclude the NastranIO class: nastran_io.h, nastran_io.cpp.

[jdeaton]

I must be missing something. When -DENABLE_NASTRANIO=OFF at the CMake level (which is default), because of the guards around the NastranIO/Python parts in src/mesh/CMakeLists.txt and examples/structural/example_7/CMakeLists.txt, that is maintained without ever seeing MAST_ENABLE_NASTRAN. CMake is taking care of it instead of using the preprocessor. The source files just never get added to the target.

[jdeaton]

The problem I'm seeing is that Doxygen has some sort of its own pre-processor that isn't smart enough to get through #if MAST_ENABLE_NASTRANIO == 1 in nastran_io.h without stripping everything off the NastranIO class. If I turn that Doxygen feature off, it makes it through, but unfortunately causes a bunch of other miscellaneous stuff to be included in the documentation (most of which looks like it comes from Cython in pynastran_io.h/cpp).

[manavbhatia]

I see your points. I just tried to comment all occurrences of MAST_ENABLE_NASTRANIO and rebuilt the code with and without nastran support and both seem to have worked.

I added this conditional to address some problem that I was facing while building the code without nastran support a few days ago. Unfortunately, I do not remember what that problem was and given that the code is building fine in either configuration, it would make sense to remove it and revisit if necessary in future.

[jdeaton]

Yea, I may go in and remove those parts. It needs documented in the installation, but the way it's currently setup if ENABLE_NASTRANIO=OFF, nothing with NastranIO/Python/Cython should get built.

Also, I saw you made some changes and then reverted stuff, but I may need to go verify the Cython part. With pynastran_io.cpp/.h remaining in the repository, you can build support for NastranIO with ENABLE_NASTRANIO=ON and ENABLE_CYTHON=OFF without running Cython. The only time that ENABLE_CYTHON=ON currently should be if changes are made in src/mesh/pynastran_io.pyx and new header/source needs regenerated by Cython.

[manavbhatia]

Yes, I figured that by reading through the Cmake documentation. During my very first implementation with cython (about 3 year ago) I was rebuilding these file each time and needed cython. As a result, I did not need the pynastran_io.* files in my implementation since these were always regenerated. So, initially I removed these files (thinking that you may not have been deliberate about it), but this change did not go through the CI since you have set them up without cython. Then, reading through the Cmake files, it became apparent that this was a deliberate choice and I ended up undoing those changes.