On Thu, May 24, 2012 at 10:25 PM, Jed Brown jedbrown at mcs.anl.gov wrote:
On Thu, May 24, 2012 at 9:17 PM, Barry Smith bsmith at mcs.anl.gov wrote:
Sarcasm on --
Yes, of course. It is essentially done, write it up and I want it on my
desk by 8 AM Friday.
-- Sarcasm off
So what if
On May 24, 2012, at 11:35 PM, Jed Brown wrote:
On Thu, May 24, 2012 at 10:19 PM, Barry Smith bsmith at mcs.anl.gov wrote:
I think I've fixed PCPre/PostSolve_Eisenstat() to work properly with kspest
but seems to be with ex19 a much worse smoother than SOR (both with Cheby).
I'm not sure
On May 24, 2012, at 10:35 PM, Jed Brown wrote:
On Thu, May 24, 2012 at 10:19 PM, Barry Smith bsmith at mcs.anl.gov wrote:
I think I've fixed PCPre/PostSolve_Eisenstat() to work properly with kspest
but seems to be with ex19 a much worse smoother than SOR (both with Cheby).
I'm not sure
On Fri, May 25, 2012 at 1:07 AM, Mark F. Adams mark.adams at
columbia.eduwrote:
And, I've never seen Gauss-Siedel used with Cheby because G-S has the
correct damping properties, as is, for the Laplacian.
The point is to have something adequate for things that are not Laplacians.
I tried
On May 25, 2012, at 8:59 AM, Jed Brown wrote:
On Fri, May 25, 2012 at 1:07 AM, Mark F. Adams mark.adams at columbia.edu
wrote:
And, I've never seen Gauss-Siedel used with Cheby because G-S has the correct
damping properties, as is, for the Laplacian.
The point is to have something
Fair point for large subdomains, but two additive have two comm steps
instead of one.
On May 25, 2012 8:24 AM, Mark F. Adams mark.adams at columbia.edu wrote:
On May 25, 2012, at 8:59 AM, Jed Brown wrote:
On Fri, May 25, 2012 at 1:07 AM, Mark F. Adams mark.adams at
columbia.eduwrote:
And,
I like to compartmetnalize: deal with the math and computer science separately.
And you (or someone) decided to only do one comm for SSOR. You could, and
maybe should, communicate between SOR steps.
On May 25, 2012, at 9:33 AM, Jed Brown wrote:
Fair point for large subdomains, but two
The high end of the GS preconditioned operator is still high frequency. If
it wasn't, then GS would be a spectrally equivalent preconditioner.
There is work on optimizing polynomials for damping on a chosen part of the
spectrum. I think what we really want is to take estimates of a few
extremal
It's easy to experiment, but I don't think it pays off.
On May 25, 2012 8:41 AM, Mark F. Adams mark.adams at columbia.edu wrote:
I like to compartmetnalize: deal with the math and computer science
separately.
And you (or someone) decided to only do one comm for SSOR. You could, and
maybe
Now perhaps it would be better to use variable damping inside SOR instead
of just on the outside, but I don't know how to select that.
On May 25, 2012 8:42 AM, Jed Brown five9a2 at gmail.com wrote:
The high end of the GS preconditioned operator is still high frequency. If
it wasn't, then GS
On May 25, 2012, at 9:42 AM, Jed Brown wrote:
The high end of the GS preconditioned operator is still high frequency. If it
wasn't, then GS would be a spectrally equivalent preconditioner.
Huh? If I damp Jacobi on the 3-point stencil with 0.5 then the high frequency
is _not_ the high end
Yes, I agree. Damping is something that is local and there is no real reason
to use a global quantity like an eigenvalue other than its what we know how to
do. I think Ray Tuminaro has looked at pointwise damping parameters. One
could image a Gershgorin bound but that is pessimistic and I'm
On Fri, May 25, 2012 at 9:06 AM, Mark F. Adams mark.adams at
columbia.eduwrote:
On May 25, 2012, at 9:42 AM, Jed Brown wrote:
The high end of the GS preconditioned operator is still high frequency. If
it wasn't, then GS would be a spectrally equivalent preconditioner.
Huh? If I damp
Yes your are right, simply scaling the PC will result in scaling the
eigenvalues and hence the Cheby factors.
On May 25, 2012, at 11:54 AM, Jed Brown wrote:
On Fri, May 25, 2012 at 9:06 AM, Mark F. Adams mark.adams at columbia.edu
wrote:
On May 25, 2012, at 9:42 AM, Jed Brown wrote:
The
On Fri, May 25, 2012 at 3:16 PM, Mark F. Adams mark.adams at
columbia.eduwrote:
Yes your are right, simply scaling the PC will result in scaling the
eigenvalues and hence the Cheby factors.
But that isn't the significant result, it's that even if a preconditioner
selectively and perfectly
On May 25, 2012, at 4:20 PM, Jed Brown wrote:
On Fri, May 25, 2012 at 3:16 PM, Mark F. Adams mark.adams at columbia.edu
wrote:
Yes your are right, simply scaling the PC will result in scaling the
eigenvalues and hence the Cheby factors.
But that isn't the significant result, it's that
On Fri, May 25, 2012 at 4:59 PM, Mark F. Adams mark.adams at
columbia.eduwrote:
On May 25, 2012, at 4:20 PM, Jed Brown wrote:
On Fri, May 25, 2012 at 3:16 PM, Mark F. Adams mark.adams at
columbia.eduwrote:
Yes your are right, simply scaling the PC will result in scaling the
eigenvalues
On May 25, 2012, at 7:16 PM, Jed Brown wrote:
On Fri, May 25, 2012 at 4:59 PM, Mark F. Adams mark.adams at columbia.edu
wrote:
On May 25, 2012, at 4:20 PM, Jed Brown wrote:
On Fri, May 25, 2012 at 3:16 PM, Mark F. Adams mark.adams at columbia.edu
wrote:
Yes your are right, simply
On Fri, May 25, 2012 at 6:57 PM, Mark F. Adams mark.adams at
columbia.eduwrote:
Yes, I forgot what we were arguing about there for a minute :)
My thinking was that Cheby _could_ degrade performance over Richardson
(for G-S in particular). That is that I could construct a
smoother/operator
On Wed, May 23, 2012 at 2:52 PM, Jed Brown jedbrown at mcs.anl.gov wrote:
On Wed, May 23, 2012 at 2:26 PM, Barry Smith bsmith at mcs.anl.gov wrote:
Note that you could use -pc_type eisenstat perhaps in this case instead.
Might save lots of flops? I've often wondered about doing Mark's
On May 24, 2012, at 1:20 PM, Jed Brown wrote:
On Wed, May 23, 2012 at 2:52 PM, Jed Brown jedbrown at mcs.anl.gov wrote:
On Wed, May 23, 2012 at 2:26 PM, Barry Smith bsmith at mcs.anl.gov wrote:
Note that you could use -pc_type eisenstat perhaps in this case instead.
Might save lots of
Is Eisenstat really worth it?
Given a memory centric future and that Jed, even now, is not seeing a win ..
maybe with a regular grid and R/B ordering you can skip a whole pass through
the data but for AIJ (I assume that is what ex5 uses) lexagraphic ordering is
probably a better model and its
On Thu, May 24, 2012 at 2:16 PM, Mark F. Adams mark.adams at
columbia.eduwrote:
Is Eisenstat really worth it?
Given a memory centric future and that Jed, even now, is not seeing a win
.. maybe with a regular grid and R/B ordering you can skip a whole pass
through the data but for AIJ (I
On May 24, 2012, at 3:30 PM, Jed Brown wrote:
On Thu, May 24, 2012 at 2:16 PM, Mark F. Adams mark.adams at columbia.edu
wrote:
Is Eisenstat really worth it?
Given a memory centric future and that Jed, even now, is not seeing a win ..
maybe with a regular grid and R/B ordering you can
On May 24, 2012, at 2:37 PM, Mark F. Adams wrote:
On May 24, 2012, at 3:30 PM, Jed Brown wrote:
On Thu, May 24, 2012 at 2:16 PM, Mark F. Adams mark.adams at columbia.edu
wrote:
Is Eisenstat really worth it?
Given a memory centric future and that Jed, even now, is not seeing a win ..
On Thu, May 24, 2012 at 3:10 PM, Barry Smith bsmith at mcs.anl.gov wrote:
Absolutely. And if it turns out to be too much of a pain to write and
maintain such a kernel there is something wrong with our programming model
and code development system. The right system should make all the
On Thu, May 24, 2012 at 4:16 PM, Jed Brown jedbrown at mcs.anl.gov wrote:
On Thu, May 24, 2012 at 3:10 PM, Barry Smith bsmith at mcs.anl.gov wrote:
Absolutely. And if it turns out to be too much of a pain to write and
maintain such a kernel there is something wrong with our programming model
On May 24, 2012, at 4:10 PM, Barry Smith wrote:
On May 24, 2012, at 2:37 PM, Mark F. Adams wrote:
On May 24, 2012, at 3:30 PM, Jed Brown wrote:
On Thu, May 24, 2012 at 2:16 PM, Mark F. Adams mark.adams at columbia.edu
wrote:
Is Eisenstat really worth it?
Given a memory centric
Okay, I pushed Cheby(2)+SOR as the default smoother, with Cheby targeting
the interval [0.1*emax, 1.1*emax].
http://petsc.cs.iit.edu/petsc/petsc-dev/rev/234274ab894d
http://petsc.cs.iit.edu/petsc/petsc-dev/rev/3212aa40b0ef (updating tests)
Its effect on convergence is varied. For smooth
On May 24, 2012, at 3:39 PM, Matthew Knepley wrote:
On Thu, May 24, 2012 at 4:16 PM, Jed Brown jedbrown at mcs.anl.gov wrote:
On Thu, May 24, 2012 at 3:10 PM, Barry Smith bsmith at mcs.anl.gov wrote:
Absolutely. And if it turns out to be too much of a pain to write and
maintain such a
On Thu, May 24, 2012 at 6:26 PM, Barry Smith bsmith at mcs.anl.gov wrote:
So do we manage blocks using internal C++ templates, templates in C, C
generated using some other system (m4 anyone?), or something else entirely?
Yes! Finally, we acknowledge that this a problem.
1) C++
On May 24, 2012, at 6:45 PM, Jed Brown wrote:
On Thu, May 24, 2012 at 6:26 PM, Barry Smith bsmith at mcs.anl.gov wrote:
So do we manage blocks using internal C++ templates, templates in C, C
generated using some other system (m4 anyone?), or something else entirely?
Yes! Finally, we
On Thu, May 24, 2012 at 9:17 PM, Barry Smith bsmith at mcs.anl.gov wrote:
Sarcasm on --
Yes, of course. It is essentially done, write it up and I want it on my
desk by 8 AM Friday.
-- Sarcasm off
So what if we know the primatives. How does it give us the language to
express these
On Thu, May 24, 2012 at 10:05 PM, Matthew Knepley knepley at gmail.com wrote:
I think its wrong, but not for the obvious reason. You can do very elegant
things with macros, but
they always end up being thrown away when you have to maintain them and
have others understand
them.
Perhaps, I'm
I think I've fixed PCPre/PostSolve_Eisenstat() to work properly with kspest
but seems to be with ex19 a much worse smoother than SOR (both with Cheby). I'm
not sure why. With SOR we are essentially doing a few Chebyshev iterations with
(U+D)^-1 (L+D)^-1 A x = b while with Eisenstat it is
On Thu, May 24, 2012 at 10:19 PM, Barry Smith bsmith at mcs.anl.gov wrote:
I think I've fixed PCPre/PostSolve_Eisenstat() to work properly with
kspest but seems to be with ex19 a much worse smoother than SOR (both with
Cheby). I'm not sure why. With SOR we are essentially doing a few
On May 22, 2012, at 11:09 PM, Barry Smith wrote:
On May 22, 2012, at 9:58 PM, Jed Brown wrote:
On Tue, May 22, 2012 at 9:52 PM, Barry Smith bsmith at mcs.anl.gov wrote:
How about a default nonlinear Krylov accelerator? fgrmes is not much more
expensive than gmres under causal
If ex19 is what matters...
$ base='mpiexec.hydra -n 4 ./ex19 -da_refine 3 -lidvelocity 100 -grashof
1e4 -pc_type mg -ksp_type fgmres -pc_mg_type full -ksp_converged_reason'
$ $base
lid velocity = 100, prandtl # = 1, grashof # = 1
Linear solve converged due to CONVERGED_RTOL iterations 23
On May 23, 2012, at 9:23 AM, Mark F. Adams wrote:
On May 22, 2012, at 11:09 PM, Barry Smith wrote:
On May 22, 2012, at 9:58 PM, Jed Brown wrote:
On Tue, May 22, 2012 at 9:52 PM, Barry Smith bsmith at mcs.anl.gov wrote:
How about a default nonlinear Krylov accelerator? fgrmes is not
This looks good:
$ $base -mg_levels_ksp_type chebyshev
-mg_levels_ksp_chebyshev_estimate_eigenvalues 0.1,1.1 -mg_levels_ksp_max_it 2
-mg_levels_pc_type sor
lid velocity = 100, prandtl # = 1, grashof # = 1
Linear solve converged due to CONVERGED_RTOL iterations 10
Linear solve
~/petsc/src/snes/examples/tutorials$ ./ex5 -da_refine 4
-ksp_monitor_true_residual -pc_type mg -snes_max_it 1 -ksp_rtol 1e-8
0 KSP preconditioned resid norm 5.024049081009e+00 true resid norm
1.141253746897e+00 ||r(i)||/||b|| 1.e+00
1 KSP preconditioned resid norm
How about a default nonlinear Krylov accelerator? fgrmes is not much more
expensive than gmres under causal circumstances.
Barry
On May 22, 2012, at 7:54 PM, Jed Brown wrote:
~/petsc/src/snes/examples/tutorials$ ./ex5 -da_refine 4
-ksp_monitor_true_residual -pc_type mg -snes_max_it 1
On Tue, May 22, 2012 at 9:52 PM, Barry Smith bsmith at mcs.anl.gov wrote:
How about a default nonlinear Krylov accelerator? fgrmes is not much more
expensive than gmres under causal circumstances.
I could handle that. The extra storage concerns me more than time.
I'd eventually like to make
On May 22, 2012, at 9:58 PM, Jed Brown wrote:
On Tue, May 22, 2012 at 9:52 PM, Barry Smith bsmith at mcs.anl.gov wrote:
How about a default nonlinear Krylov accelerator? fgrmes is not much more
expensive than gmres under causal circumstances.
I could handle that. The extra storage
44 matches
Mail list logo
