Hi Roland, there is some issue with our system for deployement of documentation. I have already asked Kuba to fix it. Meanwhile, if you execute
./install doc in your TNL directory, it will create the documentation localy on your system. You may find it in Documentation/html folder then.
I understand that no being able to mutate a mesh is good design and enables perfomance, but maybe there is an easy way to construct a new mesh from the old by refining it. You have a lot of nice examples about how to initialise matrices (sparse and denses), is there something like that for unstructured meshes. For the moment I manage only to initialise a mesh by reading it from a file.
Yes, that could be the best solution at the moment - create a new mesh. The mesh can be read from a file only now. But I think that it should not be an issue to modify it so that you could create a mesh algorithmicaly. I have to ask Kuba, maybe we could find solution for it ;).
TNL has a tool for uniform mesh refinement (it works by creating a new mesh using the
The internals are in the
As Tomáš said, the
MeshBuilder class): https://mmg-gitlab.fjfi.cvut.cz/gitlab/tnl/tnl-dev/-/blob/develop/src/Tools/tnl-refine-mesh.cppThe internals are in the
getRefinedMesh function and the EntityRefiner class: https://mmg-gitlab.fjfi.cvut.cz/gitlab/tnl/tnl-dev/-/blob/develop/src/TNL/Meshes/Geometry/getRefinedMesh.h https://mmg-gitlab.fjfi.cvut.cz/gitlab/tnl/tnl-dev/-/blob/develop/src/TNL/Meshes/Geometry/EntityRefiner.hAs Tomáš said, the
Mesh class itself is static, so the modifications need to go through the mesh initialization process, which will be the bottleneck. It can be optimized by using a minimal mesh config to avoid unnecessary data and initialization steps, though.
Or maybe, could you try to substitute
MatrixView a s a Matrix to the linear solver? For example using Solver = GMRES< SparseMatrixView< .. >>. The MatrixPointer would be std::shared_pointer< SparseMatrixView >.
still I am not sure why you need the shared pointer
if that data is read only
The shared pointer in linear solvers ensures that users do not have to call the
setMatrix function manually whenever views to the matrix get invalidated. This happens upon reallocation, especially when matrix size or row capacities change. The approach suggested by Tomáš should work, but of course you need to ensure that the view wrapped by the shared pointer is always valid when the solver is used.
Roland, did you solve the mass lumping? I am not sure if we have some example on it.
Hello! I've encountered weird behavior when moving TNL meshes. My code would crash if I attempted to move-construct a mesh from another non-empty mesh and then move data back into the original variable. So, something like this:
TNL::Meshes::Mesh<MeshConfig> m1;
// ...
// Initialize m1
// ...
auto m2(std::move(m1));
m1 = std::move(m2); // This line will throw an "Attempted to move data to a nullptr" exception
// if m1 was initialized with some data, and will not if m1 was originally emptyThis will not happen if I pre-declared m2, like this:
TNL::Meshes::Mesh<MeshConfig> m1, m2;
// Initialize m1
m2 = std::move(m1);
m1 = std::move(m2); // It's ok nowHere's the gist with an example code for this issue: https://gist.github.com/GregTheMadMonk/7b14a538a3a0e147f9ba5510d4831be4.
Is it a bug, or am I doing something that I'm not supposed to do?
HI! Of course it was a bug, should be fixed in the last commit: https://mmg-gitlab.fjfi.cvut.cz/gitlab/tnl/tnl-dev/-/commit/4403b2dca895e2c32636395d6f1c1210c7afcefd
Hey! TNL is now officially on the public gitlab.com instance: https://gitlab.com/tnl-project/tnl Please update the URLs in your local repositories to receive the latest commits on
git pull.