Theodore Papadopoulo

For constructing sensors, we have to adopt the Geometry strategy (see %extend OpenMEEG::Geometry at the end of openmeeg.i). I think this is the only way to have a nice pythonic...

Just a naive question: Is there a specific reason you want integrators exposed. I know they are now part of the interface, but I thought that python code could rely...

If it's too complicated, let's forget about ATLAS. From the https://github.com/math-atlas/math-atlas, it looks like it is not maintained since almost 3 years....

I will have a look.

To reproduce the build: cmake -DBLASLAPACK_IMPLEMENTATION=MKL -DMKL_USE_interface=ilp64 ~/src/Git/OpenMEEG-NG/

For the record, I doubt it is a problem with an int size. This is in the code: ``` unsigned vertex_index(const Vertex& V) const { for (unsigned i=0;i

I remove the data copy change and did the test. For me the test fails on: assert_allclose(om.Matrix(hminv).array(), om.Matrix(hminv_inplace).array()) I added an rtol up to 1e-1 and it still fails. So...

In conclusion, we cannot copy the data, otherwise we get mistakes at the om.Geometry level which expects the vertices to have the same addresses in memory. But with the current...

Just a comment. I'n not sure that the error message is better by providing the vertex coordinates. Because, these same coordinates are also in the copy.... So it might be...

> > I'll try to explore that later tonight or tomoroow. > > Sounds good! Feel free to push here directly. In the meantime, I think I fixed the OpenMP...