> It shouldn't "crap out", it should reject the step, shorten it, compute a
> fresh Jacobian (if the Jacobian was being lagged), and try again. Thanks for
> reminding me that this should be done sooner rather than later.
Jed,
For my uses this is a very important feature.
Two questions:
- Wil
s next, hopefully with a
unified interface for user-provided controllers.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110817/c88d0bba/attachment.html>
> The details depend on the adaptive controller. Unfortunately, we haven't yet
> unified the interface for adaptive controllers, so, for example, TSALPHA and
> TSGL have different APIs. But both of them provide adaptive controllers now
> and the rate of increase can be limited.
Is there an exam
BTW, the manual page for TSMonitorSet seems to be out-of-date, as compared with
the usage in src/ts/examples/tutorials/ex18.c
Rich
On 17 Aug 2011, at 15:02, Richard Katz wrote:
>> The details depend on the adaptive controller. Unfortunately, we haven't yet
>> unified the interface for adapti
rpolate_Alpha is missing, will fix).
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110817/2689e884/attachment.html>
- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110817/58110ff3/attachment.html>
Ack my mistake. Was comparing with the wrong function.
Rich
On 17 Aug 2011, at 15:40, Jed Brown wrote:
> On Wed, Aug 17, 2011 at 07:25, Richard Katz
> wrote:
> BTW, the manual page for TSMonitorSet seems to be out-of-date, as compared
> with the usage in src/ts/examples/tutorials/ex18.c
>
aching a tutorial today, so I might be a bit useless on the email front.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110817/a2102dbe/attachment.html>
Hi Jed
Thanks for your help with this.
At the moment, it seems that
-ts_type alpha -ts_alpha_adapt -ts_exact_final_time 0
is not working. Maybe you forgot to push an essential change? Anyway, output
below.
Rich
[magmox:src]$ porbandsim -ts_type alpha -ts_alpha_adapt
--porban
[ 93%] Building CXX object
CMakeFiles/petsc.dir/src/snes/impls/python/ftn-custom/zpythonsf.c.o
In file included from /usr/include/c++/4.4/backward/hash_set:60,
from
/sandbox/petsc/petsc-dev-2/arch-linux-cxx-sieve/include/boost/pending/container_traits.hpp:23,
fr
People are getting sloppy with declaring C variables willy-nilly inside
subroutines in PETSc code. This is not allowed. Variables must be declared
immediately at the beginning of functions or after { they cannot be put after
code.
Thanks
Barry
Some declarations of the form
extern PetscErrorCode SAAddData(SA arr, const PetscInt len, const PetscInt *ia,
const PetscScalar *wa, const PetscInt *ja);
have crept into PETSc. const PetscInt len
Do we want to have such beasties? What purpose do they serve?
My understanding is that it i
Updating the boost tarball might do the trick.
Dmitry.
On Wed, Aug 17, 2011 at 9:57 PM, Barry Smith wrote:
>
> [ 93%] Building CXX object
> CMakeFiles/petsc.dir/src/snes/impls/python/ftn-custom/zpythonsf.c.o
> In file included from /usr/include/c++/4.4/backward/hash_set:60,
> ? ? ? ? ? ? ? ? fro
That's just a typo on my part.
I'm rewriting the whole SA ball of wax, but I can push a quicker fix
for this too,
but, unfortunately, I won't be able to do that untill next Monday.
Dmitry.
On Wed, Aug 17, 2011 at 10:09 PM, Barry Smith wrote:
>
> ? Some declarations of the form
>
> extern PetscE
Satish,
Can you please do this on this machine please?
Thanks
Barry
On Aug 17, 2011, at 1:29 PM, Dmitry Karpeev wrote:
> Updating the boost tarball might do the trick.
> Dmitry.
>
> On Wed, Aug 17, 2011 at 9:57 PM, Barry Smith wrote:
>>
>> [ 93%] Building CXX object
>> CMakeFile
On Aug 17, 2011, at 1:31 PM, Dmitry Karpeev wrote:
> That's just a typo on my part.
> I'm rewriting the whole SA ball of wax, but I can push a quicker fix
> for this too,
What do you mean typo? I fixed the repository so that the declaration and
the prototype match. You don't need to do anyth
testexamples_Fortran in: /sandbox/petsc/petsc-dev-2/src/ts/examples/tests
--Error detected during compile or link!---
See http://www.mcs.anl.gov/petsc/petsc-2/documentation/faq.html
/sandbox/petsc/petsc-dev-2/arch-linux-cxx-sieve/bin/mpif90 -c -Wall
-Wno-unused-va
l/petsc-dev/attachments/20110817/50a6fd5e/attachment.html>
Okay. By "typo" I meant that I never intended to have a "const
PetscInt" argument.
It just got contaminated from the nearby "const PetscInt *".
I'm not sure what meaning "const PetscInt" would have, since C has
pass-by-value
semantics, but I'm not sure whether some C-subtlety might be at play here.
On Aug 17, 2011, at 1:37 PM, Dmitry Karpeev wrote:
> Okay. By "typo" I meant that I never intended to have a "const
> PetscInt" argument.
> It just got contaminated from the nearby "const PetscInt *".
> I'm not sure what meaning "const PetscInt" would have, since C has
> pass-by-value
> semantics
Matt prefers to keep only headers in the PETSc boost tarball.
This means that only a subset of boost should be packaged up.
I'm not sure how to do the right selection, though.
Even then the warnings might stick around, I'm afraid.
Dmitry.
On Wed, Aug 17, 2011 at 10:32 PM, Barry Smith wrote:
>
>
Thanks.
dmitry.
On Wed, Aug 17, 2011 at 10:39 PM, Barry Smith wrote:
>
> On Aug 17, 2011, at 1:37 PM, Dmitry Karpeev wrote:
>
>> Okay. By "typo" I meant that I never intended to have a "const
>> PetscInt" argument.
>> It just got contaminated from the nearby "const PetscInt *".
>> I'm not sure wh
> From: Jed Brown
> Sent: Wednesday, August 17, 2011 12:38 PM
> To: For users of the development version of PETSc
> Subject: Re: [petsc-dev] declaring argument as const basic type in PETSc
>
> On Wed, Aug 17, 2011 at 11:34, Barry Smith wrote:
> > But my question remains, should we const declare f
On Aug 17, 2011, at 2:04 PM, Chetan Jhurani wrote:
>> From: Jed Brown
>> Sent: Wednesday, August 17, 2011 12:38 PM
>> To: For users of the development version of PETSc
>> Subject: Re: [petsc-dev] declaring argument as const basic type in PETSc
>>
>> On Wed, Aug 17, 2011 at 11:34, Barry Smith wr
so it doesn't
belong in the interface. It's not truly meaningless, just meaningless to the
caller.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110817/54f7008e/attachment.html>
> -Original Message-
> From: Barry Smith
> Sent: Wednesday, August 17, 2011 1:09 PM
> To: For users of the development version of PETSc
> Subject: Re: [petsc-dev] declaring argument as const basic type in PETSc
>
>So by the standard a compiler should never bitch if in the function
> d
nst for value
parameters.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110817/10718669/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110817/61e49410/attachment.html>
scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110817/d56b5779/attachment.html>
On Aug 17, 2011, at 2:50 PM, Chetan Jhurani wrote:
> I never meant to say that one must put const ints in the
> declaration.
Our problem is that because one compiler warns if the const is not listed in
both prototype and definition we must put it in both (to avoid tons of warning
messages t
> >
>
>
--
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/20110817/25d6f821/attachment.html>
Because it exposes a completely implementation detail to the public
interface, (unnecessarily at that) So yes it is for philosophical reasons that
we must reject this badly designed C standard.
Barry
On Aug 17, 2011, at 2:58 PM, Matthew Knepley wrote:
> On Wed, Aug 17, 2011 at 9:08 PM,
t; }
> > >
> > > Of course it is more useful for preventing bugs in more complex
> > > functions.
> > >
> > > Chetan
> > >
> > >
> >
> >
> >
> >
> > --
> > 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/20110817/7d359b1b/attachment.html>
On Aug 17, 2011, at 3:08 PM, Matthew Knepley wrote:
> On Wed, Aug 17, 2011 at 10:05 PM, Barry Smith wrote:
>
> Because it exposes a completely implementation detail to the public
> interface, (unnecessarily at that) So yes it is for philosophical reasons
> that we must reject this badly desi
Of course it is more useful for preventing bugs in more complex
> > > > functions.
> > > >
> > > > Chetan
> > > >
> > > >
> > >
> > >
> > >
> > >
> > > --
> > > 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
>
>
--
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/20110817/8b07ffa6/attachment.html>
On Aug 17, 2011, at 3:20 PM, Matthew Knepley wrote:
> On Wed, Aug 17, 2011 at 10:13 PM, Barry Smith wrote:
>
> On Aug 17, 2011, at 3:08 PM, Matthew Knepley wrote:
>
> > On Wed, Aug 17, 2011 at 10:05 PM, Barry Smith wrote:
> >
> > Because it exposes a completely implementation detail to the p
Dear all,
We are trying to add a PETSc dependent package called PDSLin to PETSc as an
external package. PDSLin is a hybrid linear solver and we would like to have it
been imported to PETSc as SuperLU_DIST used to be, and it provides an
alternative way to solving a linear system in parallel.
Ev
ass-by-value
> > > > > and said it is meaningless to use them. I disagree.
> > > > >
> > > > > void f(const int n, int* j)
> > > > > {
> > > > >*j = n;
> > > > >n = 0; // error
> > > > > }
> > > > >
> > > > > Of course it is more useful for preventing bugs in more complex
> > > > > functions.
> > > > >
> > > > > Chetan
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > 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
> >
> >
> >
> >
> > --
> > 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/20110817/e68c3d41/attachment.html>
Dear all,
We are trying to add a PETSc dependent package called PDSLin to PETSc as an
external package. PDSLin is a hybrid linear solver and we would like to have it
been imported to PETSc as SuperLU_DIST used to be, and it provides an
alternative way to solving a linear system in parallel.
Ev
On Aug 17, 2011, at 3:30 PM, Matthew Knepley wrote:
> On Wed, Aug 17, 2011 at 10:24 PM, Barry Smith wrote:
>
> On Aug 17, 2011, at 3:20 PM, Matthew Knepley wrote:
>
> > On Wed, Aug 17, 2011 at 10:13 PM, Barry Smith wrote:
> >
> > On Aug 17, 2011, at 3:08 PM, Matthew Knepley wrote:
> >
> > > O
Rebecca,
It would probably be best if you email to petsc-maint the PDSLin tarball so
we can look at the PDSlin structure and come up with the best way to proceed.
The way to handle the packaging will depend on how PDSLin interacts with PETSc.
Thanks
Barry
On Aug 17, 2011, at 3:1
not sure the right way and steps
> to approach the goal.
> >
> > Thanks very much!
> >
> > Best regards,
> >
> > Rebecca
> >
> > Xuefei (Rebecca) Yuan
> > Postdoctoral Fellow
> > Lawrence Berkeley National Laboratory
> > Tel: 1-510-486-7031
> >
> >
>
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110817/79a5816e/attachment.html>
; > I am not sure if I have stated the problem clearly, in short is that we
> > would like to add some package to PETSc but not sure the right way and
> > steps to approach the goal.
> >
> > Thanks very much!
> >
> > Best regards,
> >
> > Rebecca
> >
> > Xuefei (Rebecca) Yuan
> > Postdoctoral Fellow
> > Lawrence Berkeley National Laboratory
> > Tel: 1-510-486-7031
> >
> >
>
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110817/939a8d8c/attachment.html>
Wow, you take an afternoon off and miss 35 emails on petsc-dev
I'm a big user of const; I use it whenever I can and never thought that it does
not effect the caller for pass by value args, and I'm not sure why anyone would
think of it ... as far as "contaminating the entire code" -- that is
> From: Barry Smith
>
> On Aug 17, 2011, at 2:50 PM, Chetan Jhurani wrote:
>
> > I never meant to say that one must put const ints in the
> > declaration.
>
>Our problem is that because one compiler warns if the const is not listed
> in both prototype and
> definition we must put it in both
You are absolutely correct in that it is violation of encapsulation that does
not harm, it just irks me that such a great language can have a silly flaw.
Barry
On Aug 17, 2011, at 6:27 PM, Chetan Jhurani wrote:
>> From: Barry Smith
>>
>> On Aug 17, 2011, at 2:50 PM, Chetan Jhurani wrote:
On Aug 17, 2011, at 6:18 PM, Mark F. Adams wrote:
> Wow, you take an afternoon off and miss 35 emails on petsc-dev
>
> I'm a big user of const; I use it whenever I can and never thought that it
> does not effect the caller for pass by value args, and I'm not sure why
> anyone would think o
Dear all,
I have a problem for compile PDSLin with PETSc, the configure.log says
--
== Compiling PDSLin; this may take several minutes
==
On Aug 17, 2011, at 8:55 PM, Barry Smith wrote:
>
> On Aug 17, 2011, at 6:18 PM, Mark F. Adams wrote:
>
>> Wow, you take an afternoon off and miss 35 emails on petsc-dev
>>
>> I'm a big user of const; I use it whenever I can and never thought that it
>> does not effect the caller for pass
ew interface.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110817/0c88aa36/attachment.html>
On Aug 17, 2011, at 9:33 PM, Mark F. Adams wrote:
>
> On Aug 17, 2011, at 8:55 PM, Barry Smith wrote:
>
>>
>> On Aug 17, 2011, at 6:18 PM, Mark F. Adams wrote:
>>
>>> Wow, you take an afternoon off and miss 35 emails on petsc-dev
>>>
>>> I'm a big user of const; I use it whenever I can a
Cool, Matt will get his new repo soon.
Barry
On Aug 17, 2011, at 9:37 PM, Jed Brown wrote:
> On Wed, Aug 17, 2011 at 11:36, Barry Smith wrote:
>
> testexamples_Fortran in: /sandbox/petsc/petsc-dev-2/src/ts/examples/tests
> --Error detected during compile or link!--
hod(args)
instead of ClassMethod(object,args).
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110817/9de0950b/attachment.html>
53 matches
Mail list logo
