Will Pazner

> Can we please add an item about this in `CHANGELOG`? Done! Thanks for the helpful suggestions @v-dobrev!

Thank you for this great contribution @arotem3!!

Marking this as ready for review… open to feedback and suggestions about this idea. In the branch [densemat-array](https://github.com/mfem/mfem/tree/densemat-array) I also made the changes to `DenseMatrix` and `DenseTensor`. We can pull...

> I would strongly be in favor of making similar changes to `DenseMatrix` as proposed, and might also add that `Vector` could also be a high-value target as well unless...

I merged the `DenseMatrix` and `DenseTensor` branch into this PR. `Vector` might make sense to do as a separate PR. Making sure everything works properly with e.g. `PetscParVector` will be...

There are certain MFEM configuration options that will lead to duplicate libraries in the link command when you build any of the examples, for example a parallel build with `MFEM_USE_SUITESPARSE...

Strange, it works for me, running: * macOS 12.6.1 * Python 3.10.8 * SWIG 4.1.1 In particular, the problematic line is ```c++ new mfem::TransferMap(static_cast< const mfem::TransferMap& >(result)) ``` but in...

Yes, it will definitely work with nesting. The first time the operator is applied, you won't see any benefit (since the allocator has to set up the buffers initially), but...

@v-dobrev suggested an alternative approach, where the workspace/"arena allocator" is available as a `MemoryType`. This would have some advantages (for example, other data structures, such as arrays or matrices, could...

> Well, if the package would not depend on GR, it may be interesting... I have plans to split the contour/pseudocolor computation and the actual drawing into separate packages in...