On Wed, Feb 25, 2015 at 10:27 AM, Martin Sandve Alnæs
<[email protected]> wrote:
> I support a consistent design pattern like this.
>
> I suggest using a consistent naming convention:
> SubFunctionView and SubMeshView (both prefix and postfix seems overkill to
> me)

Yes, clumsy.

> or
> FunctionView and MeshView (advantage of tab completion from "Function<tab>")
> or
> SubFunction and SubMesh (language wise I prefer these names but that's
> impractical because of the legacy implementations)
>

I think I prefer View because it's more explicit in terms of
ownership. 'Sub' is nice, but one can still wonder over ownership, but
I guess would be ok if we're consistent.

I'm not sure SubMesh would be natural in the case that the view is
into a different topological dimension, e.g. a view into the boundary
of a Mesh.

> At least FunctionView and MeshView should be mirrored in UFL abstractions.
> I don't think FunctionSpaceView needs a symbolic representative.
>
> A UFL type matching FunctionView could make a unified split() possible
> (I've mentioned this in some issue somewhere).
>

Yes, sorting out 'split' would be nice and we should take this into
account in any design.

Garth

> Martin
>
>
> On 25 February 2015 at 11:04, Garth N. Wells <[email protected]> wrote:
>>
>> We have some objects in DOLFIN that can contain data or can be a view
>> into another object, e.g. DofMap, FunctionSpace,  Function. It's often
>> not clear what is what, and it tends to complicate the code for
>> classes that can either own data or provide a view.
>>
>> We've settled on adding a MeshView class, and it would nice to extend
>> this further to other classes and have, for example, DofMapView,
>> SubFunctionView, SubSpaceView. Objects that own data could be created
>> from views. For example, in place of the
>> Function.split(deepcopy=False) functionality, we could have
>>
>>     # Mixed function
>>     W = Function(V)
>>
>>     # u and p a SubFunctionViews into W
>>     u = W.sub_function(0)
>>     p = W.sub_function(1)
>>
>>     # u and p are now Function objects that own their data
>>     u = Function(u)
>>     p = Function(p)
>>
>> Thoughts on separating out objects that own data and objects that provide
>> views?
>>
>> Garth
>> _______________________________________________
>> fenics mailing list
>> [email protected]
>> http://fenicsproject.org/mailman/listinfo/fenics
>
>
_______________________________________________
fenics mailing list
[email protected]
http://fenicsproject.org/mailman/listinfo/fenics

Reply via email to