On Mon, Apr 5, 2010 at 10:33 PM, Jed Brown wrote:
> On Tue, 6 Apr 2010 03:46:37 +0200, Matthew Knepley
> wrote:
>> I think we do. If we do not, then we should.
>
> I think the primary failure here is setting options on objects that
> can't be created until setup (typically PCSetUp). ?These objec
On Mon, Apr 5, 2010 at 8:47 PM, Lisandro Dalcin wrote:
> On 3 April 2010 23:32, Matthew Knepley wrote:
> > Why would you attach an option instead of having an equiv API call?
> >
>
> Do PETSc have an equivalent API call for every option you can set
> using options database?
I think we do. If w
On Tue, 6 Apr 2010 03:46:37 +0200, Matthew Knepley wrote:
> I think we do. If we do not, then we should.
I think the primary failure here is setting options on objects that
can't be created until setup (typically PCSetUp). These objects have a
well-defined prefix so they are controllable through
On 3 April 2010 23:32, Matthew Knepley wrote:
> Why would you attach an option instead of having an equiv API call?
>
Do PETSc have an equivalent API call for every option you can set
using options database?
> Strings
> are ALWAYS a bad interface.
But they are generic... I would love to to have
I would add that the meaning (and even the class) of objects composed
with a given object is also
opaque and is to be interpreted by the application. This does,
however, add flexibility to PETSc
and, in my view, is fairly harmless as long as the rest of the API
doesn't rely on "conventions"
such a
On Sat, Apr 3, 2010 at 8:32 PM, Matthew Knepley wrote:
> Why would you attach an option instead of having an equiv API call? Strings
> are ALWAYS a bad interface.
I'm not sure I understand what you are getting at.
Currently we can attach named PetscObjects to a given object.
All I was suggested t
Why would you attach an option instead of having an equiv API call? Strings
are ALWAYS a bad interface.
Matt
On Fri, Apr 2, 2010 at 9:29 PM, Dmitry Karpeev wrote:
> On a somewhat related note: would it make sense to have the functionality
> to
> attach options or just character strings to Pet
On Apr 2, 2010, at 9:29 PM, Dmitry Karpeev wrote:
> On a somewhat related note: would it make sense to have the
> functionality to
> attach options or just character strings to PetscObjects?
> We have ways of attaching reals, ints and arrays
> thereof to objects, but not character strings or op
On a somewhat related note: would it make sense to have the functionality to
attach options or just character strings to PetscObjects?
We have ways of attaching reals, ints and arrays
thereof to objects, but not character strings or options (named strings).
I would find it convenient in various sit
I think this is a fine idea and have no problem with someone
implementing it.
Barry
On Mar 21, 2010, at 4:04 AM, Jed Brown wrote:
>
>
> As a separate issue, when talking about bigger multiphysics
> problems, I
> would really like namespaced options. This could be as quick-and-
> di
On Fri, 19 Mar 2010 16:23:23 -0500, Barry Smith wrote:
> (3) introduce into DM the ability to "get subphysics" DM. Here the
> conceptual question is how to indicate them. Do we introduce the idea
> of having each DM as having N "fields" and then to be able to request
> "field 1 and 2" etc? P
Hi Barry,
I think this would be very useful. In all my magma dynamics codes, there is a
block of equations that is composed of Stokes, the Compaction equation (good
Helmholtz), and Continuity. Marc has shown that multigrid works very well on
the Compaction equation. It would be interesting t
Now that the 3.1 repository has been cloned I'd like to start work
on the reorganization of PETSc to pull all the functionality of DMMG
into the SNES, PC and TS components. I want to do this because
1) the DMMG "solver" are not compossible with each other and other
solvers. For example,
13 matches
Mail list logo
