which seems to be either exactly the same or very close.
As can be seen, both have a lot of filled squares (way more than I would expect, since I expected them to be sparse, not with solid blocks), and seem to be filled most in the initial 4096x4096 square, and not at all in the bottom-right corner (which makes sense).
the matrices should be identical. You can check that if you save them and open them in python and calculate the difference.
the question is how sparsity changes with mesh size, for very small meshes tangent matrix is close to dense even for 3D problems.
calculate the sparsity nnz/(ndof*ndof) and see how it changes with problem size the ICNTL(14) error might actually be justified for small meshes. In this case you can either convert the matrix to dense and use a dense solver or increase ICNTL(14). But as you increase the number of elements, the matrix should start becoming more and more sparse. How sparse, you should be able to calculate by hand.
Yep - matrix density is 1.89% for this case. I am scaling it up currently to see if the density is still lower. Does the added computational time make sense with this in mind?
I think I figured out a faster way of solving the K * x = rhs equation. Is there any way to inject the results back into getFEM so I can use integrations such as asm_generic to compare it with my original results?
Just to confirm, this is an out-of-memory error, correct?
Trace 2 in getfem_models.cc, line 2643: Global generic assembly tangent term
Traceback (most recent call last):
File "C:\Users\ecomstock3\AppData\Local\anaconda3\envs\Research_FEM\lib\site-packages\spyder_kernels\py3compat.py", line 356, in compat_exec
exec(code, globals, locals)
File "c:\users\ecomstock3\onedrive - georgia institute of technology\documents\getfem simulations\test6d_add_multiplier.py", line 321, in <module>
force, stability, result_arrays = calc_F(0e-6, 0, -7.8, 0., 1e6+0.0, 2.9, make_grids(N, 10))
File "c:\users\ecomstock3\onedrive - georgia institute of technology\documents\getfem simulations\test6d_add_multiplier.py", line 261, in calc_F
K = md.tangent_matrix()
File "C:\Users\ecomstock3\AppData\Local\anaconda3\envs\Research_FEM\lib\site-packages\getfem\getfem.py", line 2807, in tangent_matrix
return self.get("tangent_matrix")
File "C:\Users\ecomstock3\AppData\Local\anaconda3\envs\Research_FEM\lib\site-packages\getfem\getfem.py", line 2775, in get
return getfem('model_get',self.id, *args)
RuntimeError: (Getfem::InterfaceError) -- getfem caught a bad_alloc exception
Hexarractal meshing leads to the md.add_filtered_fem_variable method and the md.add_multiplier yielding the same result. gmres works as a solver fairly well, but I have not been able to get the built-in getFEM solver to work. The problem is that these results usually do not make sense, as they include strongly negative particle densities, which are unphysical.
Simplex meshing with md.add_multiplier gets me results that make sense
Simplex meshing with md.add_filtered_fem_variable gets me different results, which also include strongly negative particle densities, but are different from the results on a hexarractal mesh.
md.add_multiplier = md.add_filtered_variable + elimination of null space
which means that for Hexarractal your multiplier constrain has zero null-space, while for simplex mesh your multiplier has non-zero null-space.
It could be related to:
I think you need to find an applied-mathematics specialist that knows more about FE discretization of this problem. I do not think there is a very high chance that there is some GetFEM specific issue.
