-1 in terms of maintainability of freecad and flexibility of the simulations;) Python is definitely the better way. Look how fast HarryvL shows new results...
start with this one :p https://www.coursera.org/learn/finite-element-method
As said, slow parts can be ported to c++ if it makes sense. But for most parts python has fast ways (matrix solving, eigenvalues, and other matrix operations). I guess the slow part is the assembling of element entries in global matrices. If elements are defined by classes it should be possible to reimplement these classes in c++ and create python representations with pybind11.PrzemoF wrote: ↑Fri Feb 08, 2019 9:39 pmWhat about speed? I mean I don't like C++ (*), but the python flexibility comes at a huge speed penalty.
(*) the only language I wanted to learn and I gave up when I realised if feels like a bunch of workarounds one on top of another. And then one more to fix it.
I am planning to profile the code and report out on where time is spent. Clearly, solving the matrix equations is the most computationally intensive, but here is where NumPy/SciPy comes the rescue. Including smart use of preconditioning with classical techniques, like Cuthill McKee band optimization (also available as a routine in SciPy btw). Assembly of the global stiffness matrix is not normally the most intensive, but involves a lot of loops. Here I Need to focus on maximizing use of masking, matrix multiplication and list comprehension instead of dum loops. Suggestions on cutting out for loops are welcome.looo wrote: ↑Sat Feb 09, 2019 6:15 amI guess the slow part is the assembling of element entries in global matrices. If elements are defined by classes it should be possible to reimplement these classes in c++ and create python representations with pybind11.
Also with modern c++ and eigen c++ doesn't differ a lot from python and numpy. But in my eyes python is the right tool to create and design such a library.
yeah sure Harry. I need to duplicate faces and tried Boolenfragments Mode: Split, but that does not give the desired result. In fact all three mode types give exactly the same mesh. In all three cases the report view just says “Part to mesh: ... ShapeType —> Compound”. Is there a way to force duplicate element faces at a contact? I tried a simple Part>Compound of two separate Compsolids, but that won’t guarantee the element faces will be lined-up at the contact (right?) ... which is a must for interface elements. I also read about GMSH physical surfaces and wanted to specify that in the geo file, but can not locate that file (or the tmp directory for that matter) on my hard disk. Does it get deleted after use?