an small and perhaps unimportant gotcha
Yup, this comes from trying to patch more and more flexibility on
a system
that wasn't originally designed for that particular flexibility. The
matrix and vector
are in a strange state at this point that is not defined by our
original design.
One way we can mangle our minds around this is to say the TYPE of
the
Vec/Mat has not been set yet, we have merely changed the default type
it will become. This isn't completely accurate but that's what
happens when
you pretend there is dark matter to explain why some observation doesn't
match relativity theory and it sounds real cool.
At this point I think we just have to live with this weirdness,
unless
you have a solution.
Barry
On Dec 2, 2008, at 9:12 AM, Lisandro Dalcin wrote:
Other (really nice!) change I've noticed is that now we can call
{Vec|Mat}Create() and next {Vec|Mat}SetType() and it works!
However, see this.
In [1]: from petsc4py import PETSc
In [2]: x = PETSc.Vec().create()
In [3]: x.setType('seq')
In [4]: print x.getType()
None
In [5]: A = PETSc.Mat().create()
In [6]: A.setType('seqaij')
In [7]: print A.getType()
None
Internally, the type_name field is never set, it still is NULL (then
petsc4y returns None).
The problem is that forcing the type_name to be set will be really
dangerous (rmember PetscValidType macro).
Any comments?
--
Lisandro Dalc?n
---
Centro Internacional de M?todos Computacionales en Ingenier?a (CIMEC)
Instituto de Desarrollo Tecnol?gico para la Industria Qu?mica (INTEC)
Consejo Nacional de Investigaciones Cient?ficas y T?cnicas (CONICET)
PTLC - G?emes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594
Inner KSP never created on SNES
I've just noticed that now SNES does not create the inner KSP at the
time SNESCreate() is called. Then I could easily manage to break
things (basically, if SNESSetFromOptions() is never called)
Does it make sense to add:
if (!snes-ksp) { SNESGetKSP(snes, snes-ksp);}
near the begining of SNESSetUp() ??
--
Lisandro Dalc?n
---
Centro Internacional de M?todos Computacionales en Ingenier?a (CIMEC)
Instituto de Desarrollo Tecnol?gico para la Industria Qu?mica (INTEC)
Consejo Nacional de Investigaciones Cient?ficas y T?cnicas (CONICET)
PTLC - G?emes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594
Inner KSP never created on SNES
I am not against requiring SetFromOptions() to create default objects. We
already require it to set a default type.
Matt
On Tue, Dec 2, 2008 at 8:08 AM, Lisandro Dalcin dalcinl at gmail.com wrote:
I've just noticed that now SNES does not create the inner KSP at the
time SNESCreate() is called. Then I could easily manage to break
things (basically, if SNESSetFromOptions() is never called)
Does it make sense to add:
if (!snes-ksp) { SNESGetKSP(snes, snes-ksp);}
near the begining of SNESSetUp() ??
--
Lisandro Dalc?n
---
Centro Internacional de M?todos Computacionales en Ingenier?a (CIMEC)
Instituto de Desarrollo Tecnol?gico para la Industria Qu?mica (INTEC)
Consejo Nacional de Investigaciones Cient?ficas y T?cnicas (CONICET)
PTLC - G?emes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594
--
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/20081202/b284bade/attachment.html
Inner KSP never created on SNES
I still fu**ing hate hg. There is no trivial way I know to
determine
when this happened. i.e. when I was so f**ing stupid!
This is seriously, seriously, seriously bad! We do not/cannot
require
that SNESSetFromOptions() be called.
I will fix this inconceivably stupid design change that was made.
SNESCreate() WILL create the KSP and KSPCreate() will create the
PC.
This will result in many changes in the source
Barry
On Dec 2, 2008, at 8:08 AM, Lisandro Dalcin wrote:
I've just noticed that now SNES does not create the inner KSP at the
time SNESCreate() is called. Then I could easily manage to break
things (basically, if SNESSetFromOptions() is never called)
Does it make sense to add:
if (!snes-ksp) { SNESGetKSP(snes, snes-ksp);}
near the begining of SNESSetUp() ??
--
Lisandro Dalc?n
---
Centro Internacional de M?todos Computacionales en Ingenier?a (CIMEC)
Instituto de Desarrollo Tecnol?gico para la Industria Qu?mica (INTEC)
Consejo Nacional de Investigaciones Cient?ficas y T?cnicas (CONICET)
PTLC - G?emes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594
Inner KSP never created on SNES
Matt,
You are wrong!
I will fix this today.
Barry
On Dec 2, 2008, at 8:29 AM, Matthew Knepley wrote:
I am not against requiring SetFromOptions() to create default
objects. We
already require it to set a default type.
Matt
On Tue, Dec 2, 2008 at 8:08 AM, Lisandro Dalcin dalcinl at gmail.com
wrote:
I've just noticed that now SNES does not create the inner KSP at the
time SNESCreate() is called. Then I could easily manage to break
things (basically, if SNESSetFromOptions() is never called)
Does it make sense to add:
if (!snes-ksp) { SNESGetKSP(snes, snes-ksp);}
near the begining of SNESSetUp() ??
--
Lisandro Dalc?n
---
Centro Internacional de M?todos Computacionales en Ingenier?a (CIMEC)
Instituto de Desarrollo Tecnol?gico para la Industria Qu?mica (INTEC)
Consejo Nacional de Investigaciones Cient?ficas y T?cnicas (CONICET)
PTLC - G?emes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594
--
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
Inner KSP never created on SNES
On Tue, Dec 2, 2008 at 8:41 AM, Barry Smith bsmith at mcs.anl.gov wrote:
Matt,
You are wrong!
I will fix this today.
Okay, thats fine. For hg, you can do annotate on the file to see what lines
come from what version, and also log to see which sets changed it. You can
also search in hg view.
Matt
Barry
On Dec 2, 2008, at 8:29 AM, Matthew Knepley wrote:
I am not against requiring SetFromOptions() to create default objects. We
already require it to set a default type.
Matt
On Tue, Dec 2, 2008 at 8:08 AM, Lisandro Dalcin dalcinl at gmail.com
wrote:
I've just noticed that now SNES does not create the inner KSP at the
time SNESCreate() is called. Then I could easily manage to break
things (basically, if SNESSetFromOptions() is never called)
Does it make sense to add:
if (!snes-ksp) { SNESGetKSP(snes, snes-ksp);}
near the begining of SNESSetUp() ??
--
Lisandro Dalc?n
---
Centro Internacional de M?todos Computacionales en Ingenier?a (CIMEC)
Instituto de Desarrollo Tecnol?gico para la Industria Qu?mica (INTEC)
Consejo Nacional de Investigaciones Cient?ficas y T?cnicas (CONICET)
PTLC - G?emes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594
--
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/20081202/3ba0456a/attachment.html
Inner KSP never created on SNES
On Dec 2, 2008, at 8:43 AM, Matthew Knepley wrote:
On Tue, Dec 2, 2008 at 8:41 AM, Barry Smith bsmith at mcs.anl.gov
wrote:
Matt,
You are wrong!
I will fix this today.
Okay, thats fine. For hg, you can do annotate on the file to see
what lines
come from what version,
I want to find when lines DISAPPEARED, not appeared! And I want a
simple
search mechanism to find it not, not to have to manually hunt through
a bunch of
annotated files till I see it gone.
The search in hg view seems like useless garbage.
Barry
and also log to see which sets changed it. You can
also search in hg view.
Matt
Barry
On Dec 2, 2008, at 8:29 AM, Matthew Knepley wrote:
I am not against requiring SetFromOptions() to create default
objects. We
already require it to set a default type.
Matt
On Tue, Dec 2, 2008 at 8:08 AM, Lisandro Dalcin dalcinl at gmail.com
wrote:
I've just noticed that now SNES does not create the inner KSP at the
time SNESCreate() is called. Then I could easily manage to break
things (basically, if SNESSetFromOptions() is never called)
Does it make sense to add:
if (!snes-ksp) { SNESGetKSP(snes, snes-ksp);}
near the begining of SNESSetUp() ??
--
Lisandro Dalc?n
---
Centro Internacional de M?todos Computacionales en Ingenier?a (CIMEC)
Instituto de Desarrollo Tecnol?gico para la Industria Qu?mica (INTEC)
Consejo Nacional de Investigaciones Cient?ficas y T?cnicas (CONICET)
PTLC - G?emes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594
--
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
an small and perhaps unimportant gotcha
Other (really nice!) change I've noticed is that now we can call
{Vec|Mat}Create() and next {Vec|Mat}SetType() and it works!
However, see this.
In [1]: from petsc4py import PETSc
In [2]: x = PETSc.Vec().create()
In [3]: x.setType('seq')
In [4]: print x.getType()
None
In [5]: A = PETSc.Mat().create()
In [6]: A.setType('seqaij')
In [7]: print A.getType()
None
Internally, the type_name field is never set, it still is NULL (then
petsc4y returns None).
The problem is that forcing the type_name to be set will be really
dangerous (rmember PetscValidType macro).
Any comments?
--
Lisandro Dalc?n
---
Centro Internacional de M?todos Computacionales en Ingenier?a (CIMEC)
Instituto de Desarrollo Tecnol?gico para la Industria Qu?mica (INTEC)
Consejo Nacional de Investigaciones Cient?ficas y T?cnicas (CONICET)
PTLC - G?emes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594
an small and perhaps unimportant gotcha
This is strange. I just tried KSP ex2 and after MatSetType() the type_name
is
set. What does *.setType() call?
Matt
On Tue, Dec 2, 2008 at 9:12 AM, Lisandro Dalcin dalcinl at gmail.com wrote:
Other (really nice!) change I've noticed is that now we can call
{Vec|Mat}Create() and next {Vec|Mat}SetType() and it works!
However, see this.
In [1]: from petsc4py import PETSc
In [2]: x = PETSc.Vec().create()
In [3]: x.setType('seq')
In [4]: print x.getType()
None
In [5]: A = PETSc.Mat().create()
In [6]: A.setType('seqaij')
In [7]: print A.getType()
None
Internally, the type_name field is never set, it still is NULL (then
petsc4y returns None).
The problem is that forcing the type_name to be set will be really
dangerous (rmember PetscValidType macro).
Any comments?
--
Lisandro Dalc?n
---
Centro Internacional de M?todos Computacionales en Ingenier?a (CIMEC)
Instituto de Desarrollo Tecnol?gico para la Industria Qu?mica (INTEC)
Consejo Nacional de Investigaciones Cient?ficas y T?cnicas (CONICET)
PTLC - G?emes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594
--
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/20081202/7173c780/attachment.html
an small and perhaps unimportant gotcha
On Tue, Dec 2, 2008 at 2:06 PM, Matthew Knepley knepley at gmail.com wrote:
This is strange. I just tried KSP ex2 and after MatSetType() the type_name
is
set. What does *.setType() call?
It's a plain call to {Vec|Mat}SetType() . Matt, look at the actual
functions in core PETSc. If the sizes are not set, the create rutine
is saved in the ops table. Then the create rutine is acutally called
when VecSetSizes() is called.
Matt
On Tue, Dec 2, 2008 at 9:12 AM, Lisandro Dalcin dalcinl at gmail.com wrote:
Other (really nice!) change I've noticed is that now we can call
{Vec|Mat}Create() and next {Vec|Mat}SetType() and it works!
However, see this.
In [1]: from petsc4py import PETSc
In [2]: x = PETSc.Vec().create()
In [3]: x.setType('seq')
In [4]: print x.getType()
None
In [5]: A = PETSc.Mat().create()
In [6]: A.setType('seqaij')
In [7]: print A.getType()
None
Internally, the type_name field is never set, it still is NULL (then
petsc4y returns None).
The problem is that forcing the type_name to be set will be really
dangerous (rmember PetscValidType macro).
Any comments?
--
Lisandro Dalc?n
---
Centro Internacional de M?todos Computacionales en Ingenier?a (CIMEC)
Instituto de Desarrollo Tecnol?gico para la Industria Qu?mica (INTEC)
Consejo Nacional de Investigaciones Cient?ficas y T?cnicas (CONICET)
PTLC - G?emes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594
--
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
--
Lisandro Dalc?n
---
Centro Internacional de M?todos Computacionales en Ingenier?a (CIMEC)
Instituto de Desarrollo Tecnol?gico para la Industria Qu?mica (INTEC)
Consejo Nacional de Investigaciones Cient?ficas y T?cnicas (CONICET)
PTLC - G?emes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594
some problems with 'make install'
On Mon, 1 Dec 2008, Lisandro Dalcin wrote:
I'm testing configure passing '--prefix=', and after building, I do
$ su -c 'make install'
But then, some files ('configure.log', 'RDict.db') are left with
'root:root' owner and group. If you want to build/rebuild again, this
fails bad.
And you know, using 'sudo' is not always a chance, as depending on
'sudo' configuration, it does not preserve the environment.
I don't see configure.log - but I see build.log and default.log. These
should not cause conflict - but RDict.db does.
Matt would have to check this issue. Ideally most of these files
should not be created during 'make install'
As a hack - I can add os.remove('RDict.db') in config/installer.py
Satish
some problems with 'make install'
On Tue, Dec 2, 2008 at 1:31 PM, Satish Balay balay at mcs.anl.gov wrote:
On Mon, 1 Dec 2008, Lisandro Dalcin wrote:
I'm testing configure passing '--prefix=', and after building, I do
$ su -c 'make install'
But then, some files ('configure.log', 'RDict.db') are left with
'root:root' owner and group. If you want to build/rebuild again, this
fails bad.
And you know, using 'sudo' is not always a chance, as depending on
'sudo' configuration, it does not preserve the environment.
I don't see configure.log - but I see build.log and default.log. These
should not cause conflict - but RDict.db does.
Matt would have to check this issue. Ideally most of these files
should not be created during 'make install'
As a hack - I can add os.remove('RDict.db') in config/installer.py
I am for this.
Matt
Satish
--
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/20081202/d0e1aeec/attachment.html
some problems with 'make install'
On Tue, 2 Dec 2008, Matthew Knepley wrote:
As a hack - I can add os.remove('RDict.db') in config/installer.py
I am for this.
ok - I pushed the hack [deletes more than RDict.db - as I see
different files created in different situations..]
Satish
an small and perhaps unimportant gotcha
On Tue, Dec 2, 2008 at 4:46 PM, Barry Smith bsmith at mcs.anl.gov wrote:
Yup, this comes from trying to patch more and more flexibility on a system
that wasn't originally designed for that particular flexibility. The matrix
and vector
are in a strange state at this point that is not defined by our original
design.
Of course, but this enhacement was one I wanted forever! So very welcome!
At this point I think we just have to live with this weirdness, unless
you have a solution.
At MatGetType we could traverse the MatList to find the type_name, but
that would not work in the case of --with-dynamic=1 (and perhaps other
scenarios)
In short, yes, we have to live with it (at least for 2.4.0).
On Dec 2, 2008, at 9:12 AM, Lisandro Dalcin wrote:
Other (really nice!) change I've noticed is that now we can call
{Vec|Mat}Create() and next {Vec|Mat}SetType() and it works!
However, see this.
In [1]: from petsc4py import PETSc
In [2]: x = PETSc.Vec().create()
In [3]: x.setType('seq')
In [4]: print x.getType()
None
In [5]: A = PETSc.Mat().create()
In [6]: A.setType('seqaij')
In [7]: print A.getType()
None
Internally, the type_name field is never set, it still is NULL (then
petsc4y returns None).
The problem is that forcing the type_name to be set will be really
dangerous (rmember PetscValidType macro).
Any comments?
--
Lisandro Dalc?n
---
Centro Internacional de M?todos Computacionales en Ingenier?a (CIMEC)
Instituto de Desarrollo Tecnol?gico para la Industria Qu?mica (INTEC)
Consejo Nacional de Investigaciones Cient?ficas y T?cnicas (CONICET)
PTLC - G?emes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594
--
Lisandro Dalc?n
---
Centro Internacional de M?todos Computacionales en Ingenier?a (CIMEC)
Instituto de Desarrollo Tecnol?gico para la Industria Qu?mica (INTEC)
Consejo Nacional de Investigaciones Cient?ficas y T?cnicas (CONICET)
PTLC - G?emes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594
Inner KSP never created on SNES
Ugg, I have added this check.
Barry
This bug came from another design extension that was slightly
half-assed.
Originally SNESCreate() always created a KSP and KSPCreate() always
created
a PC and one could not change them. But I realized that PCCreate()
did not
automatically have a Mat in it, you had to add one with PCSetOperators()
[which really should be called PCSetMats()!] One could also change
it later with another call to PCSetOperators(). By symmetry one should
also be able to replace the KSP in a SNES and the PC in a KSP, hence
SNESSetKSP(), KSPSetPC().
But still PC's PCGetOperator() was different
because it returned nothing if PCSetOperators() had not yet been set. So
I had PCGetOperators() automatically return a new Mat if one had never
set
it. I then changed SNESGetKSP() and KSPGetPC() to automatically create
one if it did not already exist and SNESSetKSP() had never been called.
This meant I had to add a bunch of checks if (!snes-ksp) to make
sure SNES had a proper KSP when needed.
An alternative approach was to have SNESCreate() and KSPCreate()
continue to create the KSP and PC and change the PCCreate() to
automatically
have a Mat (then PCSetOperators() would just overwrite the one already
there). The reason I didn't take this route is that PC hast TWO slots
for
mat and pmat, sometimes they are the same and sometimes they are
different. Should PCCreate() create one and put it in both slots or
create
two, one for each slot. I could avoid that decision by having the
creation
of those mats until PCGetOperators() when the user decides they want
two or
one matrices by passing the same address in for mat and pmat or
different
addresses.
So a bunch of design decisions over time lead to the current
undesirable
need for if (!snes-ksp)
On Dec 2, 2008, at 8:08 AM, Lisandro Dalcin wrote:
I've just noticed that now SNES does not create the inner KSP at the
time SNESCreate() is called. Then I could easily manage to break
things (basically, if SNESSetFromOptions() is never called)
Does it make sense to add:
if (!snes-ksp) { SNESGetKSP(snes, snes-ksp);}
near the begining of SNESSetUp() ??
--
Lisandro Dalc?n
---
Centro Internacional de M?todos Computacionales en Ingenier?a (CIMEC)
Instituto de Desarrollo Tecnol?gico para la Industria Qu?mica (INTEC)
Consejo Nacional de Investigaciones Cient?ficas y T?cnicas (CONICET)
PTLC - G?emes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594
Inner KSP never created on SNES
However, the argument (at source code) that PCGetOperators should
return new Mat's if they were never set never, never convinced me. For
me, Mat's are to KSP/PC like Function/Jacobian to SNES. Stuff that the
user has to provide. Supose you call PCGetOperators(), and then that
call returns a just created Mat, with no sizes and not type, almost
empty. What those returned Mat's would be good for?? Just to save
users from a MatCreate() call ?? However, creating 'on-demand' inner
PC on KSP, or inner KSP on SNES is a completelly different matter, as
we can provide meaningful defaults for SNESType/KSPType/PCType.
On Tue, Dec 2, 2008 at 6:53 PM, Barry Smith bsmith at mcs.anl.gov wrote:
Ugg, I have added this check.
Barry
This bug came from another design extension that was slightly
half-assed.
Originally SNESCreate() always created a KSP and KSPCreate() always created
a PC and one could not change them. But I realized that PCCreate() did not
automatically have a Mat in it, you had to add one with PCSetOperators()
[which really should be called PCSetMats()!] One could also change
it later with another call to PCSetOperators(). By symmetry one should
also be able to replace the KSP in a SNES and the PC in a KSP, hence
SNESSetKSP(), KSPSetPC().
But still PC's PCGetOperator() was different
because it returned nothing if PCSetOperators() had not yet been set. So
I had PCGetOperators() automatically return a new Mat if one had never set
it. I then changed SNESGetKSP() and KSPGetPC() to automatically create
one if it did not already exist and SNESSetKSP() had never been called.
This meant I had to add a bunch of checks if (!snes-ksp) to make
sure SNES had a proper KSP when needed.
An alternative approach was to have SNESCreate() and KSPCreate()
continue to create the KSP and PC and change the PCCreate() to automatically
have a Mat (then PCSetOperators() would just overwrite the one already
there). The reason I didn't take this route is that PC hast TWO slots for
mat and pmat, sometimes they are the same and sometimes they are
different. Should PCCreate() create one and put it in both slots or create
two, one for each slot. I could avoid that decision by having the creation
of those mats until PCGetOperators() when the user decides they want two or
one matrices by passing the same address in for mat and pmat or different
addresses.
So a bunch of design decisions over time lead to the current undesirable
need for if (!snes-ksp)
On Dec 2, 2008, at 8:08 AM, Lisandro Dalcin wrote:
I've just noticed that now SNES does not create the inner KSP at the
time SNESCreate() is called. Then I could easily manage to break
things (basically, if SNESSetFromOptions() is never called)
Does it make sense to add:
if (!snes-ksp) { SNESGetKSP(snes, snes-ksp);}
near the begining of SNESSetUp() ??
--
Lisandro Dalc?n
---
Centro Internacional de M?todos Computacionales en Ingenier?a (CIMEC)
Instituto de Desarrollo Tecnol?gico para la Industria Qu?mica (INTEC)
Consejo Nacional de Investigaciones Cient?ficas y T?cnicas (CONICET)
PTLC - G?emes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594
--
Lisandro Dalc?n
---
Centro Internacional de M?todos Computacionales en Ingenier?a (CIMEC)
Instituto de Desarrollo Tecnol?gico para la Industria Qu?mica (INTEC)
Consejo Nacional de Investigaciones Cient?ficas y T?cnicas (CONICET)
PTLC - G?emes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594
Inner KSP never created on SNES
On Dec 2, 2008, at 4:02 PM, Lisandro Dalcin wrote:
However, the argument (at source code) that PCGetOperators should
return new Mat's if they were never set never, never convinced me. For
me, Mat's are to KSP/PC like Function/Jacobian to SNES. Stuff that the
user has to provide. Supose you call PCGetOperators(), and then that
call returns a just created Mat, with no sizes and not type, almost
empty. What those returned Mat's would be good for?? Just to save
users from a MatCreate() call ?? However, creating 'on-demand' inner
PC on KSP, or inner KSP on SNES is a completelly different matter, as
we can provide meaningful defaults for SNESType/KSPType/PCType.
I use to think that the Mat and Vec are different kinds of objects
(data objects)
from SNES and KSP (algorithm objects). In some sense this is true, but
that
doesn't mean they shouldn't be as similarly treated as possible.
I use to think in a PETSc program the user created a bunch of objects
and put them
together. Now I think we can also support a more framework oriented
program
where the user creates one object (like SNES for nonlinear objects)
and just
interacts with it. I'm not claiming this is a better model (in fact I
think often it is
a stupid simplistic model) but I like the idea of supporting it.
BTW:
Currently one can do
MatCreate(comm,A);
KSPSetOperators(ksp,A,,A,)
Barry
On Tue, Dec 2, 2008 at 6:53 PM, Barry Smith bsmith at mcs.anl.gov
wrote:
Ugg, I have added this check.
Barry
This bug came from another design extension that was slightly
half-assed.
Originally SNESCreate() always created a KSP and KSPCreate() always
created
a PC and one could not change them. But I realized that PCCreate()
did not
automatically have a Mat in it, you had to add one with
PCSetOperators()
[which really should be called PCSetMats()!] One could also change
it later with another call to PCSetOperators(). By symmetry one
should
also be able to replace the KSP in a SNES and the PC in a KSP, hence
SNESSetKSP(), KSPSetPC().
But still PC's PCGetOperator() was different
because it returned nothing if PCSetOperators() had not yet been
set. So
I had PCGetOperators() automatically return a new Mat if one had
never set
it. I then changed SNESGetKSP() and KSPGetPC() to automatically
create
one if it did not already exist and SNESSetKSP() had never been
called.
This meant I had to add a bunch of checks if (!snes-ksp) to make
sure SNES had a proper KSP when needed.
An alternative approach was to have SNESCreate() and KSPCreate()
continue to create the KSP and PC and change the PCCreate() to
automatically
have a Mat (then PCSetOperators() would just overwrite the one
already
there). The reason I didn't take this route is that PC hast TWO
slots for
mat and pmat, sometimes they are the same and sometimes they are
different. Should PCCreate() create one and put it in both slots or
create
two, one for each slot. I could avoid that decision by having the
creation
of those mats until PCGetOperators() when the user decides they
want two or
one matrices by passing the same address in for mat and pmat or
different
addresses.
So a bunch of design decisions over time lead to the current
undesirable
need for if (!snes-ksp)
On Dec 2, 2008, at 8:08 AM, Lisandro Dalcin wrote:
I've just noticed that now SNES does not create the inner KSP at the
time SNESCreate() is called. Then I could easily manage to break
things (basically, if SNESSetFromOptions() is never called)
Does it make sense to add:
if (!snes-ksp) { SNESGetKSP(snes, snes-ksp);}
near the begining of SNESSetUp() ??
--
Lisandro Dalc?n
---
Centro Internacional de M?todos Computacionales en Ingenier?a
(CIMEC)
Instituto de Desarrollo Tecnol?gico para la Industria Qu?mica
(INTEC)
Consejo Nacional de Investigaciones Cient?ficas y T?cnicas (CONICET)
PTLC - G?emes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594
--
Lisandro Dalc?n
---
Centro Internacional de M?todos Computacionales en Ingenier?a (CIMEC)
Instituto de Desarrollo Tecnol?gico para la Industria Qu?mica (INTEC)
Consejo Nacional de Investigaciones Cient?ficas y T?cnicas (CONICET)
PTLC - G?emes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594
Could we avoid this when 'make testexamples'?
dded tests_DATAFILESPATH and the variable testexamples_DATAFILESPATH to handle all the examples that use the matrix files HG: Enter commit message. Lines beginning with 'HG:' are removed. HG: -- HG: user: bsmith at barry-smiths-macbook-pro-17.local HG: branch 'default' HG: changed bin/maint/asterix-test.sh HG: changed bin/maint/parth-test.sh HG: changed conf/test HG: changed src/contrib/fun3d/comp/makefile HG: changed src/contrib/fun3d/incomp/makefile HG: changed src/ksp/ksp/examples/tests/makefile HG: changed src/ksp/ksp/examples/tutorials/makefile HG: changed src/mat/examples/tests/makefile HG: changed src/mat/examples/tutorials/makefile This could break some nightly builds :-( On Dec 1, 2008, at 10:46 PM, Satish Balay wrote: fixed now. thanks, satish On Mon, 1 Dec 2008, Lisandro Dalcin wrote: I do not expect users downloading the next release tarball to know in advance about this, nor to actually ever download required stuff. Does this make sense? [0]PETSC ERROR: - Error Message [0]PETSC ERROR: Unable to open file! [0]PETSC ERROR: Cannot locate file: /matrices/small on node zero! .
