PyMFEM
PyMFEM copied to clipboard
MFEM 4.8 support
This PR does
- changed requirement swig >= 4.3
- fixed bilinearform.i issue due to change in BilinearForm::Print
- fixed trasfer.i not knowing mfem::Device (due to the new use of MemoryType in hpp)
- fixed eltrans.i issue by ignoring kernel_dispatch macro
- addressed fe_base.i by failing C++ STL template expansion. This is because poly1d is exported from header.
- changed default MFEM build to v4.8
This PR also include (https://github.com/mfem/PyMFEM/pull/254), which does
- address recent addition of kernel_dispatch.hpp in MFEM C++.
- kernel_dispatch.hpp doesn't need to be exposed to Python. But, we need MFEM_REGISTER_KERNELS macro to be defined somehow. In this PR, MFEM_REGISTER_KERNELS is replaced to be empty macro. So that SWIG does not see the lines containing this macro.
- Add CoefficentArray, VectorCoefficientArray, and MatrixCoefficientArray (represent Array<* Coefficient> and so on)
- Changed Array constructor behavior when list of SWIG-wrapped MFEM objects is passed. SWIG objects passed as an item in list/tuple looses owner ship to underlying C++ MFEM object. Internally, we create a new Array (depending on the length of container) and set each Array element one by one (after setting thisown to False).
- Renamed other Array< * MFEM object>.
- They are used to be named like VectorPtrArray. We simplify it as VectorArray.
- SparseMatrixArray2D, DenseMatrixArray2D, HypreParMatrixArray2D are added
- HypreParMatrixArray2D can be used with mfem.HypreParMatrixFromBlocks
- DenseMatrixArray2D appears in BlockNonlinearFormIntegrator
- SparseMatrixArray2D is used wtih MixedBilinearForm::GetBlocks
To Do in https://github.com/mfem/PyMFEM/issues/268