Hello, I am considering using TNL in a project involving two-phase flow in heterogeneous media. I have bumped into a nice paper from Comp. Phys. Comm. 2019 by you on this topic but I couldn't find it among the examples your provide. Do you have example similar to dumux https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/examples/2pinfiltration/README.md#part-1-two-phase-infiltration-set-up ? Thanks
Hello Roland, I am very glad if you found TNL potentialy usefull for you. The solver from the paper is not a part of TNL yet. The solver is very experimental. TNL does not have any systematical support for the finite elements at this moment and it is why we keep the MHFEM solver apart. However, there is a robust data structure for unstructured numerical meshes with support for GPUs and MPI. This could help you to write the two-phase flow solver. If you would need any help with TNL, do not hasitate to ask.
Yes, Roland, you can find it here - https://mmg-gitlab.fjfi.cvut.cz/gitlab/tnl/tnl-dev/-/blob/develop/src/TNL/Solvers/Linear/GMRES.h . Unfortunately, it is not documented yet, but I plan to write the documentation within the next few weeks, and it is pretty easy to use, so I am sure, that you will easily understand how to use it. If not, feel free to ask. The MGSR variant seems to be better than CWY. And there is one more thing I should warn you about to be fair. Currently, TNL has no efficient prencoditioner for GPUs. Our experiments show, that GMRES with ILUT on CPU is more or less as fast as GMRES on GPU with Jacoby (diagonal) preconditioner. We also test BDDC on CPU and I think that it is much faster than GPU. So preconditioners for GPUs are becoming our priority, we already work on one but have no tests so far and will take some time.
Ok, we do not have SVD, LU only on CPU, I think that we could help you with QR and we do not have any algorithm for eigen-decomposition. But it should not be in issue to combine TNL with BLAS. When it comes to Blas Level 1, I think all operations are somehow implemented in TNL based on expression templates and parallel reduction. Blas Level 2 should be also more or less covered by TNL, but Level 3 is still something we are working on.
Roland, we have just finished the documentation on linear solvers. You can find it here - https://mmg-gitlab.fjfi.cvut.cz/doc/tnl/tutorial_Linear_solvers.html . There are several examples which might help you.
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.