Dear Lailai,
Taking a another look at your original email, I realise that my suggestion
was one that you already tried.
However, I've now had a very brief fiddle with your test case, and I see
that you program is indeed "leaking" memory somewhere. But its not at all
where you think... It turns out that you're testing the limits of
LogStream's prefix stack size. In your solve() call, you push an entry onto
the log
deallog.push("DirectKLU");
but forgot to pop it off :-) So what you want is
deallog.push("DirectKLU");
{
TrilinosWrappers::SolverDirect::AdditionalData data_klu
("Amesos_Klu");
SolverControl solver_control_klu (1000, 1e-10);
TrilinosWrappers::SolverDirect solver_klu(solver_control_klu,
data_klu);
p_constraints.distribute (p_solution);
}
deallog.pop(); // <---- Missing line :-)
So what you were witnessing was the gradual creation (over your *many* time
steps) of a very large vector of strings. That's all!
I hope that you find the simplicity of the solution pleasantly satisfying.
Best,
Jean-Paul
On Thursday, February 2, 2017 at 8:35:25 PM UTC+1, Jean-Paul Pelteret wrote:
>
> Dear Lailai,
>
> I have not had the opportunity to look at your problem in detail, but the
> one thing I've noticed is that you initialise the solver as a global
> variable. I think you might find that if you create the solver in the scope
> of the solve_p() so that it, and the underlying Trilinos objects, are
> removed after this function is called. There's really not much
> computational inefficiency in doing this - you don't reuse the
> factorisation of your matrix so the next time you call solver.solve()
> <https://github.com/dealii/dealii/blob/master/source/lac/trilinos_solver.cc#L860>
>
> you'll end up refactorising
> <https://github.com/dealii/dealii/blob/master/source/lac/trilinos_solver.cc#L836>
>
> the matrix anyway. Being able to reuse the factorisation
> <https://github.com/dealii/dealii/blob/master/source/lac/trilinos_solver.cc#L732>
>
> would be the only reason you would want to keep this direct solver in scope.
>
> I'll still try to look at this more closely when I have the chance to do
> so.
>
> Best,
> Jean-Paul
>
> On Wednesday, February 1, 2017 at 6:00:06 PM UTC+1, femFluid wrote:
>>
>> hi, Jean-Paul,
>>
>> here i attach a minimal test solving a Possion equations with trilinos's
>> amesos's direct solver, the memory
>> increases with the time step. Could you please check if there is anything
>> wired in that? Thanks in advance,
>>
>> best,
>> lailai
>>
>>
>> On Tuesday, 31 January 2017 01:42:06 UTC-5, Jean-Paul Pelteret wrote:
>>>
>>> Dear Lailai,
>>>
>>> Internally we store the Amesos solver in a smart pointer
>>> <https://github.com/dealii/dealii/blob/master/include/deal.II/lac/trilinos_solver.h#L737>,
>>>
>>> so when the solver goes out of scope the solver is destroyed. At this time,
>>> the Amesos solver should clean up after itself - in its class
>>> documentation
>>> <https://trilinos.org/docs/dev/packages/amesos/doc/html/classAmesos__BaseSolver.html>
>>>
>>> I can find no mention of a "delete" or "destroy" function. So I don't think
>>> its likely that this is causing a memory leak, but if you're able to
>>> produce a minimal test case then we could investigate further. I suppose I
>>> should ask, which version of Trilinos are you using?
>>>
>>> Regards,
>>> Jean-Paul
>>>
>>>
>>> On Tuesday, January 31, 2017 at 3:41:47 AM UTC+1, femFluid wrote:
>>>>
>>>> hi, dear all,
>>>>
>>>> i am using trilino's direct solver interface to solve a time-dependent
>>>> problem. I realized that
>>>> when the number of iterations increases, the memory usage also
>>>> increases. This increase
>>>> does not arise when turning the solver off, so just assembling the
>>>> matrices.
>>>>
>>>> At the beginning, i used the following subroutine at every time step,
>>>>
>>>> {
>>>> deallog.push("DirectKLU");
>>>> TrilinosWrappers::SolverDirect::AdditionalData data;
>>>> data.solver_type = "Amesos_Klu";
>>>> SolverControl solver_control (1000, 1e-10);
>>>> TrilinosWrappers::SolverDirect solver(solver_control, data);
>>>> solver.solve (matrix, solution, rhs);
>>>> thick_constraints.distribute (thick_solution);
>>>> }
>>>>
>>>> then i realized that the memory might be allocated every time when
>>>> defining TrilinosWrappers::SolverDirect solver(.....), which is not
>>>> released.
>>>> Then I predefine the solver in a namespace, which is the used by
>>>> calling
>>>> solver.solve (matrix, solution, rhs) at each step. Still, the memory
>>>> leakage
>>>> occurs.
>>>>
>>>> I also tried to use "Amesos_Mumps", the problem still exists. I tried
>>>> to
>>>> see the documentation of Amesos, i realized that when amesos solver
>>>> finished solving, there is a procedure 'delete solver' after. May I ask
>>>> whether
>>>> such a member function exists in dealII wrappers? Thanks in advance,
>>>>
>>>> best,
>>>> lailai
>>>>
>>>
--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see
https://groups.google.com/d/forum/dealii?hl=en
---
You received this message because you are subscribed to the Google Groups
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to dealii+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
