On Thu, Jul 23, 2009 at 8:15 AM, Jed Brown jed at 59a2.org wrote:
Matthew Knepley wrote:
On Wed, Jul 22, 2009 at 3:57 PM, Jed Brown jed at 59a2.org wrote:
Matthew Knepley wrote:
No comments? Not even This is complete shit!?
Heh, it might be overkill and, if I understand you correctly,
Matthew Knepley wrote:
MatExecute()? What about MatGetXXX() before MatExecute()?
It will reregister that function, so you would need another SetUp()
call, exactly the same interface we have now.
But the user wants to call MatGetXXX() and use the result right away
(instead of getting a
On Thu, Jul 23, 2009 at 9:45 AM, Jed Brown jed at 59a2.org wrote:
Matthew Knepley wrote:
MatExecute()? What about MatGetXXX() before MatExecute()?
It will reregister that function, so you would need another SetUp()
call, exactly the same interface we have now.
But the user wants to
Matthew Knepley wrote:
It would be impossible for me to disagree more strongly. A user cannot
get information that is not setup in the current model. I really do not
understand your objection, and the Haskell discussion is bizarre. All I am
suggestion is that we use a better model for
On Thu, Jul 23, 2009 at 10:21 AM, Jed Brown jed at 59a2.org wrote:
Matthew Knepley wrote:
It would be impossible for me to disagree more strongly. A user cannot
get information that is not setup in the current model. I really do not
understand your objection, and the Haskell discussion is
Matthew Knepley wrote:
There is no way we would be doing conintuations. Why even bring this up?
This just complicates the discussion and distracts from the main issues.
The answer is incredibly easy and straightforward. Just like MANY
functions in PETSc, you will not get the correct answer
If I get a matrix from a DM, I usually do something like
PetscOptionsGetString(NULL,-q1_mat_type,mtype,sizeof(mtype),NULL);
DMGetMatrix(dm,mtype,Jp);
so that the type can be changed on the command line (I frequently switch
between preconditioners that can use BAIJ and those that cannot).
Barry Smith wrote:
My eventual goal is to remove all hidden MatCreate()'s and
instead have Mat's passed in as arguments. So MatLoad() would take a
Mat as an argument, as would DAGetMatrix() One could then set as much
or a as little as a Mat as they like before passing it in. They could
Barry Smith wrote:
Could you call MatSetFromOptions() twice, once before the
DAGetMatrix() call to set the type and then after the DAGetMatrix() to
set particular options for what you set?
This is okay as long as we don't get more global matrix options (this
state appears to be stable).
On Wed, Jul 22, 2009 at 12:20 AM, Barry Smithbsmith at mcs.anl.gov wrote:
On Jul 21, 2009, at 7:47 PM, Jed Brown wrote:
Barry Smith wrote:
? ?This is just a limitation of the current implementation due to the way
the design evolved over time.
There is nothing intrinsic to the abstract
On Jul 22, 2009, at 9:56 AM, Lisandro Dalcin wrote:
On Wed, Jul 22, 2009 at 12:20 AM, Barry Smithbsmith at mcs.anl.gov
wrote:
On Jul 21, 2009, at 7:47 PM, Jed Brown wrote:
Barry Smith wrote:
This is just a limitation of the current implementation due to
the way
the design
On Wed, Jul 22, 2009 at 12:19 PM, Barry Smithbsmith at mcs.anl.gov wrote:
On Jul 22, 2009, at 9:56 AM, Lisandro Dalcin wrote:
On Wed, Jul 22, 2009 at 12:20 AM, Barry Smithbsmith at mcs.anl.gov wrote:
On Jul 21, 2009, at 7:47 PM, Jed Brown wrote:
Barry Smith wrote:
? This is just a
Lisandro Dalcin wrote:
If you do MatSetType(A, MATAIJ), you end-up having a MATSEQAIJ or a
MPIMPIAIJ... Vec does not have such aliasing on type names ...
How is this a problem? You aren't matching type names, you're just
setting a function to be called after the sizes are known. Since this
No comments? Not even This is complete shit!?
Matt
On Tue, Jul 21, 2009 at 8:56 PM, Matthew Knepley knepley at gmail.com wrote:
Actually, this seems like the same problem that Lisandro is having, just
with
different functions. I propose making data structures do the work for us
rather
Matthew Knepley wrote:
No comments? Not even This is complete shit!?
Heh, it might be overkill and, if I understand you correctly, I think it
could be a headache. There is a reasonable amount of code in the
various interfaces to ensure some sequencing, but delayed evaluation is
tough to reason
My eventual goal is to remove all hidden MatCreate()'s and
instead have Mat's passed in
as arguments. So MatLoad() would take a Mat as an argument, as would
DAGetMatrix()
One could then set as much or a as little as a Mat as they like before
passing it in.
They could set the type, they
On Jul 21, 2009, at 7:00 PM, Jed Brown wrote:
Barry Smith wrote:
My eventual goal is to remove all hidden MatCreate()'s and
instead have Mat's passed in as arguments. So MatLoad() would take a
Mat as an argument, as would DAGetMatrix() One could then set as much
or a as little as a Mat
Actually, this seems like the same problem that Lisandro is having, just
with
different functions. I propose making data structures do the work for us
rather than complicated organization in an imperative program.
We could use the same mechanism we use in configure to handle issues of
object
On Jul 21, 2009, at 7:47 PM, Jed Brown wrote:
Barry Smith wrote:
Could you call MatSetFromOptions() twice, once before the
DAGetMatrix() call to set the type and then after the DAGetMatrix()
to
set particular options for what you set?
This is okay as long as we don't get more global
19 matches
Mail list logo
