[petsc-dev] post 3.1 reorganization of PETSc DMMG code

[Dmitry Karpeev]

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 as the existence of such and such named object of such and such
type attached to so and so ...

Dmitry.

On Mon, Apr 5, 2010 at 1:47 PM, Lisandro Dalcin <dalcinl at gmail.com> wrote:
> On 3 April 2010 23:32, Matthew Knepley <knepley at gmail.com> 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 a
> {KSP|PC|SNES|TS}SetOptions() to pass name,value pairs of options...
> Right now, every time I need it, I have to play with the GLOBAL
> options database.
>
> Think about MPI_Info ... Without it, the MPI API should be far more
> complex for very little to gain... IMHO, your "ALWAYS" is  a bit
> strong :-)
>
>
>
> --
> Lisandro Dalcin
> ---------------
> 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
>