> On Sep 21, 2015, at 11:03 PM, David Knezevic
> wrote:
>
> On Tue, Sep 22, 2015 at 9:45 AM, Barry Smith wrote:
>
>
> https://bitbucket.org/petsc/petsc/issues/107/allow-recovery-from-certain-errors-in
>
>
> This sounds like the ideal fix. Would you plan to
https://bitbucket.org/petsc/petsc/issues/107/allow-recovery-from-certain-errors-in
> On Sep 21, 2015, at 8:31 PM, David Knezevic
> wrote:
>
> On Tue, Sep 22, 2015 at 9:30 AM, Roy Stogner wrote:
>
> On Tue, 22 Sep 2015, David Knezevic wrote:
>
> I think it'd be good to make this easier t
If you want to skip the new factorization you can simply call
KSPSetReusePreconditioner() appropriate in the #else case below
Barry
> On Jan 7, 2015, at 10:16 PM, David Knezevic
> wrote:
>
> I notice that in PetscLinearSolver::solve we have:
>
> --
>
> #if PETSC
Uncrustify has much more fine scale control than astyle. It is not perfect,
but can match "most" of the many documented PETSc formatting rules.
My dream is to required processing each source file through crustify
"automatically" before any source code is committed to the repository (so it
On Nov 29, 2012, at 3:59 PM, John Peterson
wrote:
> On Wed, Nov 28, 2012 at 2:08 PM, Barry Smith wrote:
>>
>> On Nov 28, 2012, at 3:00 PM, Michael Povolotskyi wrote:
>>
>>> Thank you.
>>> Looks like also others treated this parameter err
elta x + x
and once delta x is sufficiently smaller than x, delta x + x == x (in
floating point) so we don't want to iterate past the point where x is not being
changed.
Barry
> Michael.
>
> On 11/28/2012 03:55 PM, Barry Smith wrote:
>> On Nov 28, 2012,
On Mar 24, 2012, at 2:33 PM, Roy Stogner wrote:
>
> On Sat, 24 Mar 2012, Derek Gaston wrote:
>
>> Yep - we've known about this for a while. We have special
>> preallocation routines that spew zeros into the matrix for stuff like
>> future contact interactions before the first matassemblybegin/
On Mar 22, 2012, at 2:42 PM, Roy Stogner wrote:
>
> Did you know that MatAssemblyBegin/End() wipes any
> not-already-assembled entries from the matrix, forcing them to be
> reallocated if they're part of a future assembly? Nice optimization
> in most cases, but I wish I knew how to turn it off.
On Feb 1, 2012, at 1:05 PM, Dmitry Karpeev wrote:
> PETSc isn't shy about changing the API every release :-)
> We tend to thing it's the right thing to do, if used sparingly.
>
> Dmitry.
>
> On Wed, Feb 1, 2012 at 12:57 PM, Derek Gaston wrote:
> I think so. Libmesh doesn't have so many users
On Dec 21, 2010, at 2:21 PM, Jed Brown wrote:
> On Tue, Dec 21, 2010 at 14:42, Jan Biermann wrote:
> first, I sent the stuff to Petsc and they want to include it (otherwise it
> would not make any sense to make the changes in libmesh I guess).
>
> Okay, I asked because I hadn't seen it go by a
On Nov 9, 2010, at 4:35 PM, Cody Permann wrote:
> There are other issues with using prefix installs of PETSc. It turns out
> that there are links back to the source directory where you build PETSc for
> any external libraries you use. At least this is the case with the newest
> version of PE
11 matches
Mail list logo