Re: [Libmesh-users] ksp monitor
On Thu, 3 Nov 2016, John Peterson wrote: On Thu, Nov 3, 2016 at 4:21 PM, Rossi, Simone wrote: I’m using PETSc 3.7.2. I’ll install a another version to check if that’s the problem. OK, it could be a bug on the libmesh side, I have not tested with 3.7.2 extensively yet... As luck would have it I just did a PETSc 3.7.2 build earlier today. Running LIBMESH_OPTIONS='-ksp_monitor' make check -C examples/transient/transient_ex1/ replicates the problem for me. I get to: Solving time step 4, time=0.1250... [0]PETSC ERROR: - Error Message -- [0]PETSC ERROR: Argument out of range [0]PETSC ERROR: Too many KSP monitors set --- Roy-- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi___ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
Re: [Libmesh-users] ksp monitor
On Thu, Nov 3, 2016 at 4:21 PM, Rossi, Simone wrote: > Hey John, > I’m using PETSc 3.7.2. I’ll install a another version to check if that’s > the problem. > OK, it could be a bug on the libmesh side, I have not tested with 3.7.2 extensively yet... -- John -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi ___ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
Re: [Libmesh-users] ksp monitor
Hey John, I’m using PETSc 3.7.2. I’ll install a another version to check if that’s the problem. Thanks, Simone On Nov 3, 2016, at 17:36, John Peterson mailto:jwpeter...@gmail.com>> wrote: On Thu, Nov 3, 2016 at 2:45 PM, Rossi, Simone mailto:sro...@email.unc.edu>> wrote: Dear all, I have been trying to run some of the time dependent examples. Every time I use the -ksp_monitor command line option (with PETSc) to see the output of the linear system, after 4 iterations the simulation crashes saying that there are too many kip_monitors. The same thing happen when running a nonlinear problem where the number of newton iterations is greater than 4. Do you have any suggestion? What version of PETSc are you using and which examples exactly? I am using PETSc 3.6.4 and I ran transient_ex1 with -ksp_monitor, and it worked fine. -- John -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi ___ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
[Libmesh-users] Reading and compying solution from exodus
Dear all,
I’m trying to restart a simulation from an exodus file.
I can read the exodus file, but when I call copy_nodal_solution I get the error
message:
“We’ll never get here”.
The message comes from DofObject::var_to_vg.
{
936 const unsigned int
937 nvg = this->n_var_groups(s);
938
939 for (unsigned int vg=0, vg_end=0; vgn_vars(s,vg);
942 if (var < vg_end) return vg;
943 }
944
945 libmesh_error_msg("We'll never get here!");
946 return 0;
947
}
It happens that nvg = 0, so it does not even enter in the for loop.
Do you have any suggestions?
Thanks,
Simone
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users
Re: [Libmesh-users] ksp monitor
On Thu, Nov 3, 2016 at 2:45 PM, Rossi, Simone wrote: > Dear all, > I have been trying to run some of the time dependent examples. > Every time I use the -ksp_monitor command line option (with PETSc) to see > the output of the linear system, > after 4 iterations the simulation crashes saying that there are too many > kip_monitors. > The same thing happen when running a nonlinear problem where the number of > newton iterations is greater than 4. > Do you have any suggestion? > What version of PETSc are you using and which examples exactly? I am using PETSc 3.6.4 and I ran transient_ex1 with -ksp_monitor, and it worked fine. -- John -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi ___ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
Re: [Libmesh-users] Systems of Equations, Ex4 -- Ex5
I solved the P2 problem in Ex4 and Ex5. Everything was fine, but for nu = 0.49995, the linear solver was not converging. I did not realize that as I was not printing the output of the linear solver on screen. Changing the preconditioner, I was able to solve the nearly-incompressible P2 elasticity problem, getting finally some instabilities in the pressure. Thanks for the help, Simone On Oct 13, 2016, at 13:12, David Knezevic mailto:david.kneze...@akselos.com>> wrote: On Thu, Oct 13, 2016 at 12:34 PM, Rossi, Simone mailto:sro...@email.unc.edu>> wrote: Dear David, thanks for your answer. In this case (nu=0.49995), first order elements typically lock, but second order elements typically do not lock. In fact many use second order lagrangian elements for nearly incompressible materials. I wanted to use this example just to show that second order elements are not inf-sup stable. But the results I get running Ex4 are not "bad": in my opinion, they are nonsense. I wonder if the differences come from a different way of handling the boundary conditions or from a bug in the assembly. Let me know if you have any insight. Thanks, Simone Not sure why that would be the case, I guess you'll need to do more tests to figure out what's happening. Feel free to reach out if you have any specific questions. I doubt there's an issue with the BCs since they use DirichletBoundary code which is widely used, but it wouldn't hurt to check the assembly (I normally use 3D elasticity, and I'd say that this 2D elasticity example has not been widely used so a bug is possible, or alternatively maybe it's a plane strain vs. plane stress issue). David On Oct 13, 2016, at 12:00, David Knezevic mailto:david.kneze...@akselos.com>> wrote: On Thu, Oct 13, 2016 at 11:57 AM, Rossi, Simone mailto:sro...@email.unc.edu>> wrote: Dear all, I’m playing around with the elasticity tests in the system of equations examples (more specifically Ex4 and Ex5). In particular I’m trying to set the poisson ratio to nu = 0.49995. With this choice the solution I get using second order lagrangian elements does not make any sense. For first order elements the solution looks more reasonable, but still different from what I get from FreeFEM++. Does it depend on the enforcement of the Dirichlet boundary conditions? Thanks, Simone nu=0.49995 is almost incompressible. Normally people use special formulations for that type of problem, e.g. a mixed method to enforce almost incompressibility (similar to Stokes in fluids). That probably explains why you get bad results by naively using the simple formulation from ex4 and ex5. David -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi ___ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
Re: [Libmesh-users] Systems of Equations, Ex4 -- Ex5
On Thu, Nov 3, 2016 at 4:49 PM, Rossi, Simone wrote: I solved the P2 problem in Ex4 and Ex5. > Everything was fine, but for nu = 0.49995, the linear solver was not > converging. > I did not realize that as I was not printing the output of the linear > solver on screen. > Changing the preconditioner, I was able to solve the nearly-incompressible > P2 elasticity problem, getting finally some instabilities in the pressure. > Thanks for the help, > Simone > OK, that makes sense. FYI, I often like to use a direct solver to check that everything is set up correctly. I usually use MUMPS via PETSc: "-ksp_type preonly -pc_type lu -pc_factor_mat_solver_package mumps". David > > > On Oct 13, 2016, at 13:12, David Knezevic > wrote: > > On Thu, Oct 13, 2016 at 12:34 PM, Rossi, Simone > wrote: > >> Dear David, >> thanks for your answer. In this case (nu=0.49995), first order elements >> typically lock, but second order elements typically do not lock. >> In fact many use second order lagrangian elements for nearly >> incompressible materials. I wanted to use this example just to show that >> second order elements are not inf-sup stable. >> But the results I get running Ex4 are not "bad": in my opinion, they are >> nonsense. >> I wonder if the differences come from a different way of handling the >> boundary conditions or from a bug in the assembly. >> Let me know if you have any insight. >> Thanks, >> Simone >> > > > Not sure why that would be the case, I guess you'll need to do more tests > to figure out what's happening. Feel free to reach out if you have any > specific questions. I doubt there's an issue with the BCs since they use > DirichletBoundary code which is widely used, but it wouldn't hurt to check > the assembly (I normally use 3D elasticity, and I'd say that this 2D > elasticity example has not been widely used so a bug is possible, or > alternatively maybe it's a plane strain vs. plane stress issue). > > David > > > > >> On Oct 13, 2016, at 12:00, David Knezevic >> wrote: >> >> On Thu, Oct 13, 2016 at 11:57 AM, Rossi, Simone >> wrote: >> >>> Dear all, >>> I’m playing around with the elasticity tests in the system of equations >>> examples (more specifically Ex4 and Ex5). >>> In particular I’m trying to set the poisson ratio to nu = 0.49995. >>> With this choice the solution I get using second order lagrangian >>> elements does not make any sense. >>> For first order elements the solution looks more reasonable, but still >>> different from what I get from FreeFEM++. >>> Does it depend on the enforcement of the Dirichlet boundary conditions? >>> Thanks, >>> Simone >>> >> >> >> nu=0.49995 is almost incompressible. Normally people use special >> formulations for that type of problem, e.g. a mixed method to enforce >> almost incompressibility (similar to Stokes in fluids). That probably >> explains why you get bad results by naively using the simple formulation >> from ex4 and ex5. >> >> David >> >> >> > > -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi ___ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
[Libmesh-users] ksp monitor
Dear all, I have been trying to run some of the time dependent examples. Every time I use the -ksp_monitor command line option (with PETSc) to see the output of the linear system, after 4 iterations the simulation crashes saying that there are too many kip_monitors. The same thing happen when running a nonlinear problem where the number of newton iterations is greater than 4. Do you have any suggestion? Thanks, Simone -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi ___ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
