Re: [Libmesh-users] Newton iteration

I have noticed that the default line search type used by petsc fails quite regularly (at least for the problem that I am solving) . I would suggest doing "-snes_linesearch_type basic" . This works for the latest version of petsc. I think this option used to be "-snes_ls_type" for the older versi

Re: [Libmesh-users] Newton iteration

I get convergence only using the preconditioning option "-pre". If I set a direct solver for the linear system - as I usually do - with the option "-ksp_type preonly -pc_type lu", I get instead a failure message: Nonlinear solve did not converge due to DIVERGED_LS_FAILURE I think there's still

Re: [Libmesh-users] Limited timestep size in MemorySolutionHistory

On Wed, 6 Mar 2013, Vikram Garg wrote: > The memory solution history class and associated functions are still in the > experimental stage, so we might change TOLERANCE to some other default > value in the future. The correct thing to do here is a relative tolerance, don't you think? Multiplying

[Libmesh-users] AMR with transient analysis

Gentlemen, I wanted to followup on some of my previous messages about using AMR with a nonlinear transient analysis. The problem I faced was that following each AMR, once the system and solvers were reinitialized to the new dof size, the previous solution of the unsteady solver was set to z

Re: [Libmesh-users] Limited timestep size in MemorySolutionHistory

Hey Robert, Sorry for this late response, was first busy with the SIAM conference and then some travel. I think changing TOLERANCE to TOLERANCE*TOLERANCE in your local copy of /src/solvers/memory_solution_history.C should do the job for now. The memory solution history class and a

Re: [Libmesh-users] compiling with complex support

On Mar 6, 2013, at 9:42 AM, Manav Bhatia wrote: > Does libMesh prefer one or the other? libMesh requires the C++ std::complex implementation. -Ben -- Symantec Endpoint Protection 12 positioned as A LEADER in The F

[Libmesh-users] IO support across real and complex builds

Hi, I am curious if I can write the equation system (mesh, variables, solution, etc.) in a real-number build of the library and read it without issues in a complex-number build. If so, which IO class would be the best to do so? If not, perhaps IO of only the mesh would be doable from wi

Re: [Libmesh-users] compiling with complex support

On Wed, 6 Mar 2013, Manav Bhatia wrote: > When compiling with complex support, Petsc has an option of C vs C++ > support, and I guess they choose between the std::complex (for C++) and some > other implementation of complex. > >Does libMesh prefer one or the other? We only test against t

Re: [Libmesh-users] Newton iteration

I would also recommend using -ksp_monitor so you can see how the linear solve is going. I suspect that it's going nowhere and therefore the solve is failing... Derek On Wed, Mar 6, 2013 at 7:11 AM, Subramanya Gautam Sadasiva < ssada...@purdue.edu> wrote: > Hi, > If you are using petsc, I'd sug

[Libmesh-users] compiling with complex support

Hi, When compiling with complex support, Petsc has an option of C vs C++ support, and I guess they choose between the std::complex (for C++) and some other implementation of complex. Does libMesh prefer one or the other? Thanks, Manav --

Re: [Libmesh-users] Newton iteration

Hi, If you are using petsc, I'd suggest running with -snes_converged_reason. It looks to me that your problem is diverging for some reason. The reasons could be that the line-search or the solver is failing , which can also be changed with command line options. Subramanya Sadasiva "But mem

[Libmesh-users] Newton iteration

Hello, I'm modifying miscellaneous_ex3.C (2D Laplace-Young Problem Using Nonlinear Solvers, in my current libmesh version). After adapting residual and jacobian to my own problem, although the tolerance is not met, the Newton solver stops after one iteration with an all-zero (incorrect) solutio