On 12/7/07, Matthew Knepley knepley at gmail.com wrote:
On Dec 6, 2007 9:00 PM, Barry Smith bsmith at mcs.anl.gov wrote:
I am very nervous about mixing a catastrophic error handling system
WITH an exception system. I'd like to go back to the model:
once seterrq() is called ANYWHERE there
I'm on Matt's side. Have you ever considered C++ for implementing
PETSc internals?
Python?
On Dec 7, 2007, at 7:28 AM, Lisandro Dalcin wrote:
On 12/7/07, Matthew Knepley knepley at gmail.com wrote:
On Dec 6, 2007 9:00 PM, Barry Smith bsmith at mcs.anl.gov wrote:
I am very nervous
On Dec 7, 2007 9:18 AM, Barry Smith bsmith at mcs.anl.gov wrote:
I'm on Matt's side. Have you ever considered C++ for implementing
PETSc internals?
Python?
Portability here is a tricky concept. Python is portable in the sense that
it rnus jsut about everywhere. However, there is
On 12/7/07, Barry Smith bsmith at mcs.anl.gov wrote:
I'm on Matt's side. Have you ever considered C++ for implementing
PETSc internals?
Python?
Not sure if that was a joke, but in any case, definitely no. For PETSc
internals, and for many reasons, a C++ code using simple features
On 12/7/07, Matthew Knepley knepley at gmail.com wrote:
On Dec 7, 2007 9:18 AM, Barry Smith bsmith at mcs.anl.gov wrote:
However, Python objects
do not play well with C++ objects (which has given us a lot of grief in
the PyLith project).
Could you coment briefly the kind of problems you had
Actually it was not a joke. Currently PETSc has pretty dynamic
ways of dispatching methods that I don't think could be
accomplished easily/cleanly using simple features (basic classes
and inheritance) of C++. And as soon
we start using complicated features of C++ we get a huge
hairball that
On Friday 07 December 2007, Lisandro Dalcin wrote:
On 12/7/07, Matthew Knepley knepley at gmail.com wrote:
On Dec 7, 2007 9:18 AM, Barry Smith bsmith at mcs.anl.gov wrote:
However, Python objects
do not play well with C++ objects (which has given us a lot of grief in
the PyLith project).
When we started PETSc 2 I thought of PETSc errors as ALWAYS being
catastrophic: that is the program could NOT continue running.
Later we started to play with possibly recovering from some errors
and I added the crude PetscException mechanism. For example
I used it to allow the user in
On Dec 6, 2007 9:00 PM, Barry Smith bsmith at mcs.anl.gov wrote:
When we started PETSc 2 I thought of PETSc errors as ALWAYS being
catastrophic: that is the program could NOT continue running.
Later we started to play with possibly recovering from some errors
and I added the crude
On 11/24/07, Barry Smith bsmith at mcs.anl.gov wrote:
To minor question about this message:
* What means 'to rapid calls'? Is it a typo? Should be 'too rapid
calls' ?
Yup
* Perhaps a newline could be added after the warn mesage?
Yup
Then I'll fix the formating.
I hate this message
Lisandro,
Unfortunately, I see the same negative timings problem on the Cray XT3/4
systems when I configure PETSc to use MPI_Wtime() for all its timings. So
that doesn't necessarily fix anything...
--Richard
Lisandro Dalcin wrote:
Perhaps PETSc should use MPI_Wtime as default timer. If a
On 11/26/07, Richard Tran Mills rmills at ornl.gov wrote:
Lisandro,
Unfortunately, I see the same negative timings problem on the Cray XT3/4
systems when I configure PETSc to use MPI_Wtime() for all its timings. So
that doesn't necessarily fix anything...
Could you please try the small
I even get consistent time deltas using 'gettimeofday' on my box!!
Perhaps PETSc has some bug somewere?? What do you think??
On 11/26/07, Richard Tran Mills rmills at ornl.gov wrote:
Lisandro,
Unfortunately, I see the same negative timings problem on the Cray XT3/4
systems when I configure
I've looked long and hard for a PETSc bug that would cause this
problem.
No luck. It seems to happen mostly (only?) on certain machines.
Barry
On Nov 26, 2007, at 11:03 AM, Lisandro Dalcin wrote:
I even get consistent time deltas using 'gettimeofday' on my box!!
Perhaps PETSc has
On 11/26/07, Barry Smith bsmith at mcs.anl.gov wrote:
I've looked long and hard for a PETSc bug that would cause this
problem.
No luck. It seems to happen mostly (only?) on certain machines.
Ups! I've found a possilbe source of the problem, at least for my
case! Those negative times I got
On Nov 26, 2007 4:19 PM, Lisandro Dalcin dalcinl at gmail.com wrote:
On 11/26/07, Barry Smith bsmith at mcs.anl.gov wrote:
I've looked long and hard for a PETSc bug that would cause this
problem.
No luck. It seems to happen mostly (only?) on certain machines.
Ups! I've found a possilbe
That seems fine.
Matt
On Nov 26, 2007 4:56 PM, Lisandro Dalcin dalcinl at gmail.com wrote:
On 11/26/07, Matthew Knepley knepley at gmail.com wrote:
On Nov 26, 2007 4:19 PM, Lisandro Dalcin dalcinl at gmail.com After
surfing the code and hacked PetscLogPrintSummary(), I added a
After running some unittest for my new Mat Python type, I get
WARNING!!! Minimum time -1.19595e+09 over all processors for MatMult
is negative! This happens
on some machines whose times cannot handle to rapid calls.!
artificially changing minimum to zero.MatMult 185 1.0
-1.1959e+09
On Nov 24, 2007, at 5:25 PM, Lisandro Dalcin wrote:
After running some unittest for my new Mat Python type, I get
WARNING!!! Minimum time -1.19595e+09 over all processors for MatMult
is negative! This happens
on some machines whose times cannot handle to rapid calls.!
artificially changing
19 matches
Mail list logo
