Hello dev-team,
I use the same code to output MPIAIJ and MPISBAIJ matrices, however with
latter program hangs somewhere in MatView.
The code is:
call PetscViewerBinaryOpen(comm,'out',FILE_MODE_WRITE,viewer,ierr);
CHKERRQ(ierr)
...
call PetscViewerFileSetName(viewer,'A.dat',ierr)
call MatView(A,v
bbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20111214/5ccf41c0/attachment.html>
I have a nonlinear problem and am finding the the convergence test for the
interior PETSc linear solver is apparently testing against the norm of the
first linear solve (see appended). This is clearly not what anyone would want,
is this the intended semantics? Is there perhaps a method to rese
lve converged due to CONVERGED_RTOL iterations 0
>
>
--
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
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20111214/c27d1599/attachment.html>
g than any results to which their experiments
> lead.
> -- Norbert Wiener
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20111214/22da4021/attachment.html>
-- next part
TOL iterations 0
>>
>>
>
>
> --
> 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
>
>
>
>
--
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
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20111214/01e28ee0/attachment.html>
m I doing wrong?
Thanks,
John
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20111214/88a71bb4/attachment.html>
;
>
--
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
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20111214/f0b29551/attachment.html>
On Dec 14, 2011, at 12:45 PM, Mark F. Adams wrote:
> I have a nonlinear problem and am finding the the convergence test for the
> interior PETSc linear solver is apparently testing against the norm of the
> first linear solve (see appended).
No it is || r = b - Ax ||/|| b|| with a B in th
.cu because the vector type is
>> not VECSEQCUSP. What am I doing wrong?
>>
>
> You might need -vec_type cusp (should give seqcusp on 1 proc)
>
Ok, I tried using -vec_type cusp, same error. I'm running on 2 procs, so
this still results in mpicusp doesn't it?
John
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20111214/ad2ed601/attachment.html>
On Wed, 14 Dec 2011, John Fettig wrote:
> On Tue, Sep 20, 2011 at 12:58 PM, Barry Smith wrote:
>
> >
> > On Sep 20, 2011, at 11:54 AM, Brad Aagaard wrote:
> >
> > > I tried running a PyLith simulation using the sacusp preconditioner
> > rather than ml. If I have the mat_type set to mpiaijcusp, I
sounds like a bug, please fix.
barry
On Dec 14, 2011, at 2:47 PM, Satish Balay wrote:
> On Wed, 14 Dec 2011, John Fettig wrote:
>
>> On Tue, Sep 20, 2011 at 12:58 PM, Barry Smith wrote:
>>
>>>
>>> On Sep 20, 2011, at 11:54 AM, Brad Aagaard wrote:
>>>
I tried running a PyLith simu
On Dec 14, 2011, at 3:44 PM, Barry Smith wrote:
>
> On Dec 14, 2011, at 12:45 PM, Mark F. Adams wrote:
>
>> I have a nonlinear problem and am finding the the convergence test for the
>> interior PETSc linear solver is apparently testing against the norm of the
>> first linear solve (see appen
onverged due to CONVERGED_RTOL iterations 1
> >> Picard iteration 5 max(resid) = 5723.21 --- Rate = 4.38264
> >> 0 KSP Residual norm 2.211945822133e+04
> >> Linear solve converged due to CONVERGED_RTOL iterations 0
> >>
> >
> >
>
>
--
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
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20111214/eea87fe9/attachment.html>
ed due to CONVERGED_RTOL iterations 1
> >> Picard iteration 5 max(resid) = 5723.21 --- Rate = 4.38264
> >> 0 KSP Residual norm 2.211945822133e+04
> >> Linear solve converged due to CONVERGED_RTOL iterations 0
> >>
> >
> >
>
>
>
>
> --
> 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
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20111214/0ed19a68/attachment.html>
On Dec 14, 2011, at 3:13 PM, Mark F. Adams wrote:
>
> On Dec 14, 2011, at 3:44 PM, Barry Smith wrote:
>
>>
>> On Dec 14, 2011, at 12:45 PM, Mark F. Adams wrote:
>>
>>> I have a nonlinear problem and am finding the the convergence test for the
>>> interior PETSc linear solver is apparently te
ual norm 7.285359985607e+05
> >>> 1 KSP Residual norm 9.132700545850e+04
> >>> 2 KSP Residual norm 6.834608381922e+03
> >>> Linear solve converged due to CONVERGED_RTOL iterations 2
> >>> Picard iteration 4 max(resid) = 25082.7 --- Rate = 5.47582
> >>> 0 KSP Residual norm 1.207523847817e+05
> >>> 1 KSP Residual norm 1.286174706329e+04
> >>> Linear solve converged due to CONVERGED_RTOL iterations 1
> >>> Picard iteration 5 max(resid) = 5723.21 --- Rate = 4.38264
> >>> 0 KSP Residual norm 2.211945822133e+04
> >>> Linear solve converged due to CONVERGED_RTOL iterations 0
> >>>
> >>
> >>
> >
>
>
--
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
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20111214/7bb72626/attachment.html>
Hi:
When doing the following operation in PETSc using FD approximations to a
Jacobian vector product
J'(u)*a = [J(u+h*a) - J(u)]/h
is there a way for the user to specify that the entries of u+h*a cannot be
negative for example?
Browsing the PETSc documentation it was not obvious whether I c
was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20111214/b431a8d7/attachment.html>
85359985607e+05
> >>> 1 KSP Residual norm 9.132700545850e+04
> >>> 2 KSP Residual norm 6.834608381922e+03
> >>> Linear solve converged due to CONVERGED_RTOL iterations 2
> >>> Picard iteration 4 max(resid) = 25082.7 --- Rate = 5.47582
> >>> 0 KSP Residual norm 1.207523847817e+05
> >>> 1 KSP Residual norm 1.286174706329e+04
> >>> Linear solve converged due to CONVERGED_RTOL iterations 1
> >>> Picard iteration 5 max(resid) = 5723.21 --- Rate = 4.38264
> >>> 0 KSP Residual norm 2.211945822133e+04
> >>> Linear solve converged due to CONVERGED_RTOL iterations 0
> >>>
> >>
> >>
> >
>
>
>
>
> --
> 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
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20111214/df783d43/attachment.html>
eriments is
infinitely more interesting than any results to which their experiments lead.
-- Norbert Wiener
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20111214/fbd4c521/attachment.html>
s is infinitely more interesting than any results to which their
> experiments lead.
> -- Norbert Wiener
>
--
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
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20111214/42474124/attachment.html>
Bobby,
What Matt is trying to tell you is that changing values at this level to
prevent function evaluations outside of the function domain inside Newton is a
total hack that rarely works well and should be avoided. You really don't want
to do this.
PETSc 3.2 introduced the ability
Barry:
Thanks. I will take a look at this. I agree that in Newton itself this can end
up being a total hack depending on what you choose to implement, however the
matvec itself would seem to be a different case though there too the
opportunity exists to make a mess of it. Correct me if I am wro
---
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20111214/174a8206/attachment.html>
n HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20111214/4cef83c9/attachment.html>
On Dec 14, 2011, at 9:22 PM, Jed Brown wrote:
> On Wed, Dec 14, 2011 at 17:55, Barry Smith wrote:
> What Matt is trying to tell you is that changing values at this level to
> prevent function evaluations outside of the function domain inside Newton is
> a total hack that rarely works well and
BTW: petsc-dev has the new option SNESSetPicard() which can be used to to
make SNES a Picard solver and it always uses the Jed-correct defect correction
approach so there is no reason to over solve the linear system. See its manual
page.
Barry
On Dec 14, 2011, at 9:29 PM, Jed Brown wrote
>
> Barry
>
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20111214/16e69225/attachment.html>
re) in order to impose those constraints with SNESVI. I wonder if
there is a way to eliminate these constraints earlier so that the systems
don't grow so much.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/
and is used by PCFieldSplit.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20111214/f2988e41/attachment.html>
ouble is that the constraints can get "eliminated" only when they
become active.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20111214/7848e0a6/attachment.html>
n HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20111214/b1ce332b/attachment.html>
a bound
constraint on it and use it to monitor for departures from the feasible
set. If you want to eliminate it, you are better off not adding it in the
first place, it seems to me.
Dmitry.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20111214/2c59019f/attachment.html>
would thus
break the block structure satisfied by the conservative variables. This
likely also makes it more difficult to eliminate (while using to impose
constraints).
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev
e structure and all. I'm thinking about adding "bounded variables" to
libMesh in that way.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20111214/98bbb829/attachment.html>
r to get to a computationally convenient form. I
wonder if with some thought, we could do the same for SNESVI.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20111214/c4e39495/attachment.html>
37 matches
Mail list logo
