On Sep 12, 2018, at 4:23 PM, Matthew Knepley <[email protected]<mailto:[email protected]>> wrote:
On Wed, Sep 12, 2018 at 5:16 PM Smith, Barry F. <[email protected]<mailto:[email protected]>> wrote: The function norm given by the -snes_monitor is the function norm for the DVI problem (which depends on where the solution is constrained) while FormFunction() norm you compute is for the original unconstrained problem. I am still not sure why you solve this as a DVI. If you solve it without the constraints do you get the "wrong" answer? If this is a variational crack problem, you can solve it unconstrained if you use a quadratic penalty term. However, that induces spurious long range communication between crack tips. If you bound the phase field between 0 and 1, you can use a linear penalty which has physical behavior. Not really, you still need the growth constraint from iteration to iteration or you could get healing in unloading cycles, or cack path that change over time. A classical and easy to reproduce examples is to look at a crack tip with two small inclusion at different directions and different orientation relative to the tip. As the loading increase, you could have a crack that goes from tip to inclusion 1, then later from tip to inclusion 2 without going through inclusion 1... @Josh: are you alternating solves in displacement and phase field or trying to implement a monolithic approach? Convergence of monolithic approaches is elusive, and they do not necessarily give you physical path (that is paths that can be interpolated along a path of monotonically decreasing energy) With a staggered (alternate directions) approach, there is no excuse for not using SNESVI. As you mentioned, since you are propagating a crack tip, most of the constraints are saturated and the active set changes very little from step to step. In my experience, SNESVI is very fast in this situation (2-3 iterations), and its cost still negligible compared to the cost of the computation of the equilibrium displacement. In addition, once you can handle growth through SNESVI, you have no excuse not to use a linear damage dissipation potential, which is physically much reasonable (finite support often damage localisation, existence of an elastic limit, and correct nucleation in a wide range of situation as shown in my recent paper (Tanné et al JMPS 2018) My implementation of phase field fracture is available at https://bitbucket.org/bourdin/mef90-sieve It is still based on an old petsc because I can never find the time to catch up with the release, and because I needed some form of I/O in “natural ordering” that only came in recently. Feel free to ping me directly if you need more details Blaise Bourdin Matt Barry > On Sep 12, 2018, at 3:32 PM, Josh L > <[email protected]<mailto:[email protected]>> wrote: > > Hi, > > my solution is mostly very close to 1. only for a very small area where > solution goes from 0 to 1(a smeared crack). > > I set -snes_atol 1e-7 and it is converging. > > I've noticed the following: > > There is a difference between the function norm. > > I calculate the function norm in FormFunction, so every time it is called it > gives the function norm > , and the result is different from the function norm given by -snes_monitor > if i set > > SNESSetType(snes,SNESVINEWTONRSLS,ierr) > SNESVISetVariableBounds(snes,xl,xu,ierr) > > The function norm calculated in FromFunction is NOT reducing, however, the > function norm given by -snes_monitor is reducing > They are the same if I just use regular SNES without setting variable bounds. > > > Thanks, > Josh > > 2018-09-12 12:02 GMT-05:00 Smith, Barry F. > <[email protected]<mailto:[email protected]>>: > > You have too tight a convergence tolerance for your problem. You can't > expect to get more than 1.e-12 as the minimum residual norm or even less. > > How close is your solution to 1 and -1? > > If you really need much higher convergence you can try ./configure > --with-precision=__float128 > > > Barry > > > On Sep 11, 2018, at 11:53 PM, Josh L > > <[email protected]<mailto:[email protected]>> wrote: > > > > Yes, I initialize all u_i to 1.0 > > > > > > > > 2018-09-11 23:37 GMT-05:00 Smith, Barry F. > > <[email protected]<mailto:[email protected]>>: > > > > Do you start with initial conditions of 0 <= u_i <= 1 ? > > > > Run with -snes_monitor -snes_converged_reason > > -ksp_monitor_true_residual -info -snes_linesearch_monitor and send all the > > output > > > > Barry > > > > > > > On Sep 11, 2018, at 11:33 PM, Josh L > > > <[email protected]<mailto:[email protected]>> wrote: > > > > > > Hi, > > > > > > I am using SNES to solve an nonlinear equation f(u), and I know all the > > > u_i should be 0 and 1. > > > > > > First, I use SNES without constraint, and it converges. > > > > > > But, If I set > > > SNESSetType(snes,SNESVINEWTONRSLS,ierr) > > > SNESVISetVariableBounds(snes,xl,xu,ierr) > > > > > > where xl and xu is vector, and xl_i=0 and xu_i=1 > > > > > > then SNES fails to converge, because linesearch fails(snes reason = -6), > > > and the norm of residual is not reducing(the norm of incremental solution > > > is reducing) > > > > > > The reason to add constraint is that I want to implement some > > > irreversibility. > > > > > > > > > Thanks, > > > Josh > > > > > > > > > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener https://www.cse.buffalo.edu/~knepley/<http://www.cse.buffalo.edu/~knepley/> -- Department of Mathematics and Center for Computation & Technology Louisiana State University, Baton Rouge, LA 70803, USA Tel. +1 (225) 578 1612, Fax +1 (225) 578 4276 http://www.math.lsu.edu/~bourdin
