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

[Barry Smith]

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 options (named  
> strings).
> I would find it convenient in various situations.

    I cannot image why anyone would do this :-).

    But I think having the exact same support that we have for int,  
real etc for char* would be fine, since it doesn't introduce any  
additional complexity to the design. Can it be done in the same way?


    Barry

> It would also mirror the way we are able to compose named functions or
> PetscObjects
> with a given PetscObject.
>
> Dmitry.
>
> On Fri, Apr 2, 2010 at 6:33 PM, Barry Smith <bsmith at mcs.anl.gov>  
> wrote:
>>
>>  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- 
>>> dirty
>>> as
>>>
>>>  -prefix_push something_ -other -options -prefix_pop
>>>
>>> which would mean
>>>
>>>  -something_other -something_options
>>>
>>> In particular, this would have to work with
>>>
>>>  -prefix_push fieldsplit_physics1_ -options_file physics1-solver
>>> -prefix_pop
>>>
>>> where everything in 'physics1-solver' would be under this prefix.
>>> Alternatively (or additionally), a parser for yaml options would  
>>> allow
>>> this composition.
>>>
>>> Jed
>>
>>