[petsc-users] Suggestions for code with dof >> 1 ?

Christophe Ortiz christophe.ortiz at ciemat.es
Tue Oct 15 10:40:35 CDT 2013


On Tue, Oct 15, 2013 at 4:36 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> Christophe Ortiz <christophe.ortiz at ciemat.es> writes:
> > Before I go on implementing all the coupling between all the dof, I am
> > doing some tests with the system described above and I see some strange
> > behavior...
> > To do some tests, as initial conditions I set two gaussian distributions
> > for u and v. When the peak value of the gaussians is in the order of
> unity,
> > no problem, ARKIMEX as well as ROSW work fine. However, when I use peak
> > values in the order of 1e15-1e20 (which is of interest for me), then
> > troubles arise. I see it takes much more time to do one timestep for
> > ARKIMEX. This, even when I switch off the coupling and there is only
> > diffusion. It takes too long.
> >  I tried KSPCG and KSPGMRES and PCNONE/PCILU.
> >
> > - is it due to some problem with ARKIMEX and large values ?
>
> Error control should be the same.  Run with -ts_adapt_monitor and send
> output if you don't understand it.
>
> > - How do you use ts_adapt_basic_clip in the run command to decrease the
> > fastest increase of timestep ? I would like to set 1.5 for the fastest
> > increase instead of 10, which is the default. I tried but PETSc complains
> > saying:
> >
> > [0]PETSC ERROR: Argument out of range!
> > [0]PETSC ERROR: Must give exactly two values to -ts_adapt_basic_clip!
>
> -ts_adapt_basic_clip 0.1,1.5
>
> The first number is the fastest decrease that will be allowed.
>

Great, it works now.


>
> > - ARKIMEX seems to work better if I decrease the number of nodes, ie if I
> > increase the dx.
>
> Then you'll be swamped with spatial error.
>
> > - I found out with ts_view that the ARKIMEX type is always ARKIMEX3, even
> > when I use
> >
> >    ierr = TSARKIMEXSetType(ts,TSARKIMEX1BEE);
>
> Maybe you call this before the type has been set, e.g., before
> TSSetFromOptions().  Use -ts_arkimex_type 1bee.
>

Yes ! Actually, that was the problem ! Now I set ARKIMEX1BEE after
TSSetFromOptions() and it is much faster ! ARKIMEXA2 seems even faster.
Thanks Jed !

Now I see that the convergence speed of ARKIMEX depends on where I put
TSSetFromOptions().

If I do:
TSCreate();
TSSetFromOptions();
TSSetProblemType();
TSSetType();
TSARKIMEXSetType();

then ARKIMEXA2 is very fast.

Instead, if I put TSSetFromOptions() somewhere else:
TSCreate();

TSSetProblemType();
TSSetType();
*TSSetFromOptions();*
TSARKIMEXSetType();

ARKIMEXA2 slows down significantly. I guess that TSSetFromOptions overrides
something...Any idea ?


>
> > - With TSROSW, much better. Any idea why ?
>
> Default TSROSW method (ra34pw2) has a good error estimate.  It's
> probably faster because it only does linear solves.  If your problem is
> linear (or weakly nonlinear), TSROSW is usually better than ARKIMEX, at
> least unless you tell the SNES to compute the Jacobian only once.
>

Good to know.


>
> > - Do you recommend a particular KSP/PC for this type of problem ?
>
> Use a direct solver until you understand what is happening in the outer
> levels.  Then use multigrid because it is the right way to solve the
> problem.
>

Christophe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20131015/9ed1b142/attachment.html>


More information about the petsc-users mailing list