Re: [Libmesh-users] ImplicitSystem: Matrix access takes a long time

[Derek G. <fri...@gm...>]

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.

Derek

Sent from my iPhone

On Aug 11, 2009, at 4:09 PM, "Vijay S. Mahadevan" <vi...@gm...>  
wrote:

> 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<fri...@gm...>  
> wrote:
>> Vijay,
>>
>> 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  
>> propagated
>> properly to non-system matrices...
>>
>> Derek
>>
>> On Tue, Aug 11, 2009 at 1:22 PM, John Peterson
>> <pet...@cf...> wrote:
>>>
>>> On Tue, Aug 11, 2009 at 2:18 PM, Vijay S. Mahadevan<vi...@gm... 
>>> >
>>> wrote:
>>>
>>>> and when the matrix is accessed in the assembly routine again, I  
>>>> get
>>>>
>>>> [0] MatAssemblyEnd_SeqAIJ(): Matrix size: 3844 X 3844; storage  
>>>> space:
>>>> 33284 unneeded,132496 used
>>>> [0] MatAssemblyEnd_SeqAIJ(): Number of mallocs during MatSetValues 
>>>> () is
>>>> 11052
>>>
>>> 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  
>>> more
>>> 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...
>>>
>>> --
>>> John
>>>
>>>
>>> --- 
>>> --- 
>>> --- 
>>> --- 
>>> ------------------------------------------------------------------
>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>>> 30-Day
>>> trial. Simplify your report design, integration and deployment -  
>>> and focus
>>> on
>>> 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
>>> Lib...@li...
>>> https://lists.sourceforge.net/lists/listinfo/libmesh-users
>>
>>