[petsc-users] SNESVI convergence spped

[Barry Smith]

   Ata,

     Sorry for the delay in responding.

     It looks like you are using petsc-3.2, is that correct? You should switch to petsc-dev and rerun. The vi solvers are actively being developed and have some improvements since the release.   Please send the same convergence information (just the text file of output) when running with -ksp_monitor_true_residual -snes_vi_monitor (not the binary files).


   Barry

On Jan 18, 2012, at 9:40 AM, Ataollah Mesgarnejad wrote:

> Dear all,
> 
> Just realized that my email didn't go through because of my attachments, so here it is:
> 
> Sorry if it took a bit long to do the runs, I wasn't feeling well yesterday. 
> 
> I attached the output I get from a small problem (90elements, 621 DOFs )  with different SNESVI types (exodusII and command line outputs). As you can see rsaug exits with an error but ss and rs run (and their results are similar). However, after V goes to zero at a cross section line searches for both of them (rs,ss) fail?! Also as you can see KSP converges for every step.
> 
> These are the tolerances I pass to SNES:
>        user->KSP_default_rtol	= 1e-12;
> 	user->KSP_default_atol	= 1e-12;
> 	user->KSP_default_dtol	= 1e3;
> 	user->KSP_default_maxit   = 50000;
> 	user->psi_default_frtol        = 1e-8;   // snes_frtol
> 	user->psi_default_fatol        = 1e-8;  //snes_fatol
> 	user->psi_maxit 		= 500;   //snes_maxit
> 	user->psi_max_funcs 	= 1000; //snes_max_func_its
> 
> Ps: files are here: http://cl.ly/0Z001Z3y1k0Q0g0s2F2R
> 
> thanks,
> Ata
> 
> 
> On Jan 17, 2012, at 8:16 AM, Barry Smith wrote:
> 
>> 
>>  Blaise,
>> 
>>   Let's not solve the problem until we know what the problem is.  -snes_vi_monitor first then think about the cure
>> 
>>   Barry
>> 
>> On Jan 16, 2012, at 8:49 PM, Blaise Bourdin wrote:
>> 
>>> Hi,
>>> 
>>> Ata and I are working together on this. The problem he describes is 1/2 of the iteration of our variational fracture code. 
>>> In our application, E is position dependant, and typically becomes very large along very thin bands with width of the order of epsilon in the domain. Essentially, we expect that V will remain exactly equal to 1 almost everywhere, and will transition to 0 on these bands. Of course, we are interested in the limit as epsilon goes to 0. 
>>> 
>>> If the problem indeed is that it takes many steps to add the degrees of freedom. Is there any way to initialize manually the list of active constraints? To give you an idea, here is a link to a picture of the type of solution we expect. blue=1
>>> https://www.math.lsu.edu/~bourdin/377451-0000.png
>>> 
>>> Blaise
>>> 
>>> 
>>> 
>>>> It seems to me that the problem is that ultimately ALL of the degrees of freedom are in the active set,
>>>> but they get added to it a few at a time -- and there may even be some "chatter" there -- necessitating many SNESVI steps. 
>>>> Could it be that the regularization makes things worse? When \epsilon \ll 1, the unconstrained solution is highly oscillatory, possibly further exacerbating the problem. It's possible that it would be better if V just diverged uniformly.  Then nearly all of the degrees of freedom would bump up against the upper obstacle all at once.  
>>>> 
>>>> Dmitry.
>>>> 
>>>> On Mon, Jan 16, 2012 at 8:05 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
>>>> 
>>>> What do you get with -snes_vi_monitor   it could be it is taking a while to get the right active set.
>>>> 
>>>>  Barry
>>>> 
>>>> On Jan 16, 2012, at 6:20 PM, Ataollah Mesgarnejad wrote:
>>>> 
>>>>> Dear all,
>>>>> 
>>>>> I'm trying to use SNESVI to solve a quadratic problem with box constraints. My problem in FE context reads:
>>>>> 
>>>>> (\int_{Omega} E phi_i phi_j + \alpha \epsilon dphi_i dphi_j dx) V_i - (\int_{Omega} \alpha \frac{phi_j}{\epsilon} dx) = 0 , 0<= V <= 1
>>>>> 
>>>>> or:
>>>>> 
>>>>> [A]{V}-{b}={0}
>>>>> 
>>>>> here phi is the basis function, E and \alpha are positive constants, and \epsilon is a positive regularization parameter  in order of mesh resolution. In this problem we expect V  =1 a.e. and go to zero very fast at some places.
>>>>> I'm running this on a rather small problem (<500000 DOFS) on small number of processors (<72). I expected SNESVI to converge in couple of iterations (<10) since my A matrix doesn't change, however I'm experiencing a slow convergence (~50-70 iterations). I checked KSP solver for SNES and it converges with a few iterations.
>>>>> 
>>>>> I would appreciate  any suggestions or observations to increase the convergence speed?
>>>>> 
>>>>> Best,
>>>>> Ata
>>>> 
>>>> 
>>> 
>>> -- 
>>> 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
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>