Re: [deal.II] Re: Memory loss in system solver
> > Hi again, it seems my last comment got lost, but I wanted to post it here for others researching that issue: I constructed a MWE and found out, that actually solving the system via GMRES, CG or BiCGstab using any of the implementations provided by PETSc, Trilinos or the dealii versions thereof did not result in memory loss! So, from my side this was a false alarm! -Good luck finding that bug Alberto! PS: I will make a new thread for the bug in my code if necessary! Kind regards, Richard -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/742566d8-65e0-4452-9a72-cc3a5a918886o%40googlegroups.com.
Re: [deal.II] Re: Memory loss in system solver
On 7/29/20 1:12 PM, Richard Schussnig wrote: Great to hear that you were able to construct a minimal working example & pinpoint the error location, that is already of great help, but please do share the MWE you have constructed! I can also confirm, that this behaviour described in the previous posts does not(!) occur when running step-18 (I am running v.9.0.1, which is why I did not want to bother the mailing list). If we have step-18 and your MWE, we simply compare and see, where the error might come from, right? -Unfortunately though, I am not overly skilled when it comes to C++, so maybe someone else might be kind enough to help us out on that one? All help would definitely be appreciated! (Hi Richard :-) Having the minimal example would be a great first step!. W. -- Wolfgang Bangerth email: bange...@colostate.edu www: http://www.math.colostate.edu/~bangerth/ -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/1f1974a2-896c-0906-2f37-15c373339b50%40colostate.edu.
Re: [deal.II] Re: Memory loss in system solver
Hi again, Great to hear that you were able to construct a minimal working example & pinpoint the error location, that is already of great help, but please do share the MWE you have constructed! I can also confirm, that this behaviour described in the previous posts does not(!) occur when running step-18 (I am running v.9.0.1, which is why I did not want to bother the mailing list). If we have step-18 and your MWE, we simply compare and see, where the error might come from, right? -Unfortunately though, I am not overly skilled when it comes to C++, so maybe someone else might be kind enough to help us out on that one? Regards, Richard Am Mittwoch, 29. Juli 2020 17:09:01 UTC+2 schrieb Alberto Salvadori: > > Hi Daniel, > > here is the report of valgrind. Can you maybe help devising potential > issues? I am afraid to be not sufficiently skilled, yet. > Thank you, I appreciate. > > Alberto > > > > albertosalvadori@ubuntu:~/Codes/m4_code/Release$ valgrind --leak-check=yes > mpirun -np 4 ./m4_code_9.1.1 ../input/viscosity_test -mechanics > ==15940== Memcheck, a memory error detector > ==15940== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. > ==15940== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright > info > ==15940== Command: mpirun -np 4 ./m4_code_9.1.1 ../input/viscosity_test > -mechanics > ==15940== > ==15940== Warning: noted but unhandled ioctl 0x5441 with no size/direction > hints. > ==15940==This could cause spurious value errors to appear. > ==15940==See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a > proper wrapper. > ==15944== Warning: invalid file descriptor 1024 in syscall close() > ==15944== Warning: invalid file descriptor 1025 in syscall close() > ==15944== Warning: invalid file descriptor 1026 in syscall close() > ==15944== Warning: invalid file descriptor 1027 in syscall close() > ==15944==Use --log-fd= to select an alternative log fd. > ==15944== Warning: invalid file descriptor 1028 in syscall close() > ==15944== Warning: invalid file descriptor 1029 in syscall close() > ==15945== Warning: invalid file descriptor 1024 in syscall close() > ==15945== Warning: invalid file descriptor 1025 in syscall close() > ==15945== Warning: invalid file descriptor 1026 in syscall close() > ==15945== Warning: invalid file descriptor 1027 in syscall close() > ==15945==Use --log-fd= to select an alternative log fd. > ==15945== Warning: invalid file descriptor 1028 in syscall close() > ==15945== Warning: invalid file descriptor 1029 in syscall close() > ==15945== Warning: invalid file descriptor 1030 in syscall close() > ==15946== Warning: invalid file descriptor 1024 in syscall close() > ==15946== Warning: invalid file descriptor 1025 in syscall close() > ==15946== Warning: invalid file descriptor 1026 in syscall close() > ==15946== Warning: invalid file descriptor 1027 in syscall close() > ==15946==Use --log-fd= to select an alternative log fd. > ==15946== Warning: invalid file descriptor 1028 in syscall close() > ==15946== Warning: invalid file descriptor 1029 in syscall close() > ==15947== Warning: invalid file descriptor 1024 in syscall close() > ==15947== Warning: invalid file descriptor 1025 in syscall close() > ==15947== Warning: invalid file descriptor 1026 in syscall close() > ==15947== Warning: invalid file descriptor 1027 in syscall close() > ==15947==Use --log-fd= to select an alternative log fd. > ==15947== Warning: invalid file descriptor 1028 in syscall close() > ==15947== Warning: invalid file descriptor 1029 in syscall close() > > > Welcome to m4_code, a multiphysics solver for several class of problems > developed at the m4lab @ UNIBS. > The problem that is going to be solved is: Mechanics for the data set > ../input/viscosity_test > > Problem LargeStrainMechanicalProblem_OneField defined > >Reading material parameters from file ../input/viscosity_test.materials > ... done >Reading time discretization parameters from file > ../input/viscosity_test.time_discretization ... done > > Time = 0., step =0 >Initialization >Reading discretization from file ../input/viscosity_test.msh ... done >Number of active cells: 24 (by partition: 6+6+6+6) >Number of degrees of freedom: 153 (by partition: 63+30+33+27) >Dirichlet faces: 36, Neumann faces (with non-zero tractions): 0, > contact faces: 0 > NR it. 0, Assembling..., convergence achieved. > Writing output..., 0.00 s. Elapsed time 0.00 s. > > Time = 0.0100, step =1 > Cycle 0: >Number of active cells: 24 (by partition: 6+6+6+6) >Number of degrees of freedom: 153 (by partition: 63+30+33+27) >Dirichlet faces: 36, symmetry faces: 0 >Dirichlet faces: 36, Neumann faces (with non-zero tractions): 0, > contact faces: 0 > NR it. 0, Assembling..., 0.00 s, norm of residual is > 85544.434331779601052 > Jacobi - Bicgstab , solver converged in 8
Re: [deal.II] Re: Memory loss in system solver
Hi Daniel, here is the report of valgrind. Can you maybe help devising potential issues? I am afraid to be not sufficiently skilled, yet. Thank you, I appreciate. Alberto albertosalvadori@ubuntu:~/Codes/m4_code/Release$ valgrind --leak-check=yes mpirun -np 4 ./m4_code_9.1.1 ../input/viscosity_test -mechanics ==15940== Memcheck, a memory error detector ==15940== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==15940== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==15940== Command: mpirun -np 4 ./m4_code_9.1.1 ../input/viscosity_test -mechanics ==15940== ==15940== Warning: noted but unhandled ioctl 0x5441 with no size/direction hints. ==15940==This could cause spurious value errors to appear. ==15940==See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper. ==15944== Warning: invalid file descriptor 1024 in syscall close() ==15944== Warning: invalid file descriptor 1025 in syscall close() ==15944== Warning: invalid file descriptor 1026 in syscall close() ==15944== Warning: invalid file descriptor 1027 in syscall close() ==15944==Use --log-fd= to select an alternative log fd. ==15944== Warning: invalid file descriptor 1028 in syscall close() ==15944== Warning: invalid file descriptor 1029 in syscall close() ==15945== Warning: invalid file descriptor 1024 in syscall close() ==15945== Warning: invalid file descriptor 1025 in syscall close() ==15945== Warning: invalid file descriptor 1026 in syscall close() ==15945== Warning: invalid file descriptor 1027 in syscall close() ==15945==Use --log-fd= to select an alternative log fd. ==15945== Warning: invalid file descriptor 1028 in syscall close() ==15945== Warning: invalid file descriptor 1029 in syscall close() ==15945== Warning: invalid file descriptor 1030 in syscall close() ==15946== Warning: invalid file descriptor 1024 in syscall close() ==15946== Warning: invalid file descriptor 1025 in syscall close() ==15946== Warning: invalid file descriptor 1026 in syscall close() ==15946== Warning: invalid file descriptor 1027 in syscall close() ==15946==Use --log-fd= to select an alternative log fd. ==15946== Warning: invalid file descriptor 1028 in syscall close() ==15946== Warning: invalid file descriptor 1029 in syscall close() ==15947== Warning: invalid file descriptor 1024 in syscall close() ==15947== Warning: invalid file descriptor 1025 in syscall close() ==15947== Warning: invalid file descriptor 1026 in syscall close() ==15947== Warning: invalid file descriptor 1027 in syscall close() ==15947==Use --log-fd= to select an alternative log fd. ==15947== Warning: invalid file descriptor 1028 in syscall close() ==15947== Warning: invalid file descriptor 1029 in syscall close() Welcome to m4_code, a multiphysics solver for several class of problems developed at the m4lab @ UNIBS. The problem that is going to be solved is: Mechanics for the data set ../input/viscosity_test Problem LargeStrainMechanicalProblem_OneField defined Reading material parameters from file ../input/viscosity_test.materials ... done Reading time discretization parameters from file ../input/viscosity_test.time_discretization ... done Time = 0., step =0 Initialization Reading discretization from file ../input/viscosity_test.msh ... done Number of active cells: 24 (by partition: 6+6+6+6) Number of degrees of freedom: 153 (by partition: 63+30+33+27) Dirichlet faces: 36, Neumann faces (with non-zero tractions): 0, contact faces: 0 NR it. 0, Assembling..., convergence achieved. Writing output..., 0.00 s. Elapsed time 0.00 s. Time = 0.0100, step =1 Cycle 0: Number of active cells: 24 (by partition: 6+6+6+6) Number of degrees of freedom: 153 (by partition: 63+30+33+27) Dirichlet faces: 36, symmetry faces: 0 Dirichlet faces: 36, Neumann faces (with non-zero tractions): 0, contact faces: 0 NR it. 0, Assembling..., 0.00 s, norm of residual is 85544.434331779601052 Jacobi - Bicgstab , solver converged in 8 iterations, 0.00 s, updating q. p. data, 0.00 s. NR it. 1, Assembling..., 0.00 s, norm of residual is 2.878811227221835 residual / initial_residual0.33652817389 Jacobi - Bicgstab , solver converged in 7 iterations, 0.00 s, updating q. p. data, 0.00 s. NR it. 2, Assembling..., 0.00 s, norm of residual is 1.251122517879704 residual / initial_residual0.14625411082 Jacobi - Bicgstab , solver converged in 8 iterations, 0.00 s, updating q. p. data, 0.00 s. NR it. 3, Assembling..., 0.00 s, norm of residual is 0.589683284238633 residual / initial_residual0.06893298072 Jacobi - Bicgstab , solver converged in 7 iterations, 0.00 s, updating q. p. data, 0.00 s. NR it. 4, Assembling..., 0.00 s, norm of residual is 0.286154795390284
Re: [deal.II] Re: Memory loss in system solver
Alberto,
Have you tried running valgrind (in parallel) on your code? Admittedly, I
expect quite a bit of false-positives from the MPI library but it should
still help.
Best,
Daniel
Am Fr., 24. Juli 2020 um 12:07 Uhr schrieb Alberto Salvadori <
alberto.salvad...@unibs.it>:
> Dear community,
>
> if I am not mistaking my analysis, it turned out that the memory loss is
> caused by this call:
>
> BiCG.solve (this->system_matrix, distributed_incremental_displacement,
> this->system_rhs, preconditioner);
>
> because if I turn it off the top command shows no change in the RES at all.
>
> Maybe this is of use. Thanks in advance.
>
> Alberto
>
> Il giorno venerdì 24 luglio 2020 alle 11:32:13 UTC+2 Alberto Salvadori ha
> scritto:
>
>> Dear community
>>
>> I have written the simple code below for solving a system using PETSc,
>> having defined
>>
>> Vector incremental_displacement;
>> Vector accumulated_displacement;
>>
>> in the class LargeStrainMechanicalProblem_OneField.
>>
>> It turns out that this code produces a memory loss, quite significant
>> since I am solving my system thousands of times, eventually inducing the
>> run to fail. I am not sure what is causing this issue and how to solve it,
>> maybe more experienced users than myself can catch the problem with a snap
>> of fingers.
>>
>> I have verified the issue on my mac (Catalina) as well as on linux ubuntu
>> (4.15.0), using deal.ii 9.1.1.
>> Apparently the issue reveals only when mpi is invoked with more than one
>> processor, whereas it does not emerge when running in serial or by mpirun
>> -np 1.
>>
>> Thanks in advance
>>
>> Alberto
>>
>> =
>>
>>
>>
>>
>> template
>> unsigned int LargeStrainMechanicalProblem_OneField
>> ::
>> solve (
>> const unsigned penaltyAmplification
>> )
>>
>> //
>> // this simplified version of solve has been written to find out
>> // the source of memory leak in parallel
>> //
>>
>> {
>>
>> PETScWrappers::MPI::Vector distributed_incremental_displacement
>> (this>locally_owned_dofs,this->mpi_communicator);
>>
>> distributed_incremental_displacement = incremental_displacement;
>>
>> size_t
>> bicgstab_max_iterations = 2 ;
>>
>> double
>> tolerance = 1e-10 * this->system_rhs.l2_norm() ;
>>
>> unsigned solver_control_last_step;
>>
>> SolverControl bicgstab_solver_control ( bicgstab_max_iterations ,
>> tolerance );
>>
>> PETScWrappers::PreconditionJacobi preconditioner( this->system_matrix );
>>
>> this->pcout << " Bicgstab " << std::flush ;
>>
>> PETScWrappers::SolverBicgstab BiCG (bicgstab_solver_control,
>> this->mpi_communicator);
>>
>> BiCG.solve (this->system_matrix, distributed_incremental_displacement,
>> this->system_rhs, preconditioner);
>>
>> solver_control_last_step = bicgstab_solver_control.last_step();
>>
>> incremental_displacement = distributed_incremental_displacement;
>> accumulated_displacement += incremental_displacement;
>> this->hanging_node_constraints.distribute (accumulated_displacement);
>>
>> return solver_control_last_step;
>>
>> }
>>
>
>
> Informativa sulla Privacy: http://www.unibs.it/node/8155
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/dealii/24389a5b-59ba-4f32-8c4b-06d23d0fe2ban%40googlegroups.com
>
> .
>
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/dealii/CAOYDWb%2BFzNpuJG5-TTjbNXTFZyzhMbaXAGoD7ENb%2BK2W_gbY0A%40mail.gmail.com.
[deal.II] Re: Memory loss in system solver
Dear community,
if I am not mistaking my analysis, it turned out that the memory loss is
caused by this call:
BiCG.solve (this->system_matrix, distributed_incremental_displacement,
this->system_rhs, preconditioner);
because if I turn it off the top command shows no change in the RES at all.
Maybe this is of use. Thanks in advance.
Alberto
Il giorno venerdì 24 luglio 2020 alle 11:32:13 UTC+2 Alberto Salvadori ha
scritto:
> Dear community
>
> I have written the simple code below for solving a system using PETSc,
> having defined
>
> Vector incremental_displacement;
> Vector accumulated_displacement;
>
> in the class LargeStrainMechanicalProblem_OneField.
>
> It turns out that this code produces a memory loss, quite significant
> since I am solving my system thousands of times, eventually inducing the
> run to fail. I am not sure what is causing this issue and how to solve it,
> maybe more experienced users than myself can catch the problem with a snap
> of fingers.
>
> I have verified the issue on my mac (Catalina) as well as on linux ubuntu
> (4.15.0), using deal.ii 9.1.1.
> Apparently the issue reveals only when mpi is invoked with more than one
> processor, whereas it does not emerge when running in serial or by mpirun
> -np 1.
>
> Thanks in advance
>
> Alberto
>
> =
>
>
>
>
> template
> unsigned int LargeStrainMechanicalProblem_OneField
> ::
> solve (
> const unsigned penaltyAmplification
> )
>
> //
> // this simplified version of solve has been written to find out
> // the source of memory leak in parallel
> //
>
> {
>
> PETScWrappers::MPI::Vector distributed_incremental_displacement
> (this>locally_owned_dofs,this->mpi_communicator);
>
> distributed_incremental_displacement = incremental_displacement;
>
> size_t
> bicgstab_max_iterations = 2 ;
>
> double
> tolerance = 1e-10 * this->system_rhs.l2_norm() ;
>
> unsigned solver_control_last_step;
>
> SolverControl bicgstab_solver_control ( bicgstab_max_iterations ,
> tolerance );
>
> PETScWrappers::PreconditionJacobi preconditioner( this->system_matrix );
>
> this->pcout << " Bicgstab " << std::flush ;
>
> PETScWrappers::SolverBicgstab BiCG (bicgstab_solver_control,
> this->mpi_communicator);
>
> BiCG.solve (this->system_matrix, distributed_incremental_displacement,
> this->system_rhs, preconditioner);
>
> solver_control_last_step = bicgstab_solver_control.last_step();
>
> incremental_displacement = distributed_incremental_displacement;
> accumulated_displacement += incremental_displacement;
> this->hanging_node_constraints.distribute (accumulated_displacement);
>
> return solver_control_last_step;
>
> }
>
--
Informativa sulla Privacy: http://www.unibs.it/node/8155
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/dealii/24389a5b-59ba-4f32-8c4b-06d23d0fe2ban%40googlegroups.com.
