I haven't noticed this happening in our codes... And we do use extra
matrices. I'll run with -info next week and make sure this isn't
happening to us.
Sent from my iPhone
On Aug 11, 2009, at 4:09 PM, "Vijay S. Mahadevan" <vijay.m@...>
> Well no. This system I'm solving is just with continuous galerkin
> (lagrange elements). Its a set of two elliptic systems and I'm trying
> to optimize by storing the mass matrix for the transient by computing
> it only once since it does not change during the transient. But when I
> add "mass_matrix" to ImplicitSystem and when I assemble before
> starting the transient, it does lots of mallocs. And I can't figure
> out why, yet. One thing that might be a factor is that mass_matrix is
> block diagonal while say my system-matrix has some coupling blocks.
> Not sure if these extra memory specified by dof_map is throwing off
> Petsc's matrix assembly..
> What you are saying is probably happening in my DG code also. But if I
> remember correct, there is an implicit_neighbor_dofs flag that gets
> set if one of your variables is discontinuous. I'll need to check that
> next after I fix this first.
> Well thanks for the comment anyway. But I'm curious about how you do
> this. I'm sure you use more than one matrix in your code while solving
> a problem. Does the preallocation work correctly there for non-system
> matrices ?
> On Tue, Aug 11, 2009 at 2:56 PM, Derek Gaston<friedmud@...>
>> You're doing DG right? Isn't there a flag you have to set in order
>> to get
>> the sparsity pattern right? I wonder if that's not getting
>> properly to non-system matrices...
>> On Tue, Aug 11, 2009 at 1:22 PM, John Peterson
>> <peterson@...> wrote:
>>> On Tue, Aug 11, 2009 at 2:18 PM, Vijay S. Mahadevan<vijay.m@...
>>>> and when the matrix is accessed in the assembly routine again, I
>>>>  MatAssemblyEnd_SeqAIJ(): Matrix size: 3844 X 3844; storage
>>>> 33284 unneeded,132496 used
>>>>  MatAssemblyEnd_SeqAIJ(): Number of mallocs during MatSetValues
>>>> () is
>>> Well, the problem is right here. There were a lot of mallocs during
>>> MatSetValues, which means that the matrix had the wrong sparsity
>>> pattern preallocated. I've never worked on a problem which used
>>> than one SparseMatrix. It's possible that there is a bug in the
>>> library preventing it from being pre-allocated, but I don't know.
>>> Some digging in implicit_system.C should lead to an answer though...
>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>>> trial. Simplify your report design, integration and deployment -
>>> and focus
>>> what you do best, core application coding. Discover what's new with
>>> Crystal Reports now. http://p.sf.net/sfu/bobj-july
>>> Libmesh-users mailing list