Il giorno 13/feb/08, alle ore 03:03, Roy Stogner ha scritto:
>> I output the matrix assembled in libmesh using PetSC function, I
>> find lots of zero values in matrix. Because the matrix in Petsc is
>> stored using sparse compressed strage format, zero values should not
>> appear.
>
> That is incorrect. The sparsity pattern we tell PETSc to use comes
> from the connectivity of your mesh, which is much more efficient than
> building it on the fly as you assemble the matrix with your particular
> equation. Some multivariable equations (NavierStokes, in
> particular) and/or some choices of basis functions can then leave you
> with zero entries. If your equation is of the former type you can use
> DofObject::_dof_coupling to tell libMesh not to bother allocating
> matrix entries that you know will always be zero.
Hi Roy,
thanks for the explanations but i have a doubt.
I have tried to use DofMap::_dof_coupling but it seems that an issue
with amr arises... maybe I miss something obvious...
For example if I solve an advection diffusion equation in 3D with a
semiimplicit scheme I want to save the memory required to store the
Kuv, Kuw, Kvw, (and also Kvu, Kvw, Kwu,) blocks of each of my element
matrices.
With _dof_coupling I can obtain the right sparsity pattern but then at
assembly time I'll need a sparse element matrix. I can instead decide
to assemble only Kuu, Kvv, Kww as tree different dense matrices. This
works without amr, It saves a lot of memory. If I want to use amr the
problem is that the method DofMap::constrain_element_matrix_and_vector
wants to constrain all my system variables at the same time preventing
me to assemble Kuu, Kvv, Kww as different matrices.
Is there a simple solution?
Lorenzo
