On Tue, 9 Dec 2014 19:12:16 +0100
Johan Hake <[email protected]> wrote:
> In a local branch I have now stripped the whole c++ implementation of
> the GenericVector indexing. I have moved all logic of checking
> indices to the Python layer. I have removed all usage of slices as
> the latter really does not make sense in parallel. The following now
> works:
>
> v[indices] = values
>
> where indices and values can be:
>
> 1) indices: some int; values must be scalar
> 2) indices: list of ints or ndarray of ints; values can be either
> scalar or ndarray
>
> indices must be in range [0..local_size]. If indices and values all
> are of correct type and range GenericVector.set_local(indices,
> values) are eventually called followed by a call to apply("insert").
> If an error occurs it will be catched in the __setitem__ method and
> apply("insert") is called in the except statement. The latter to
> avoid deadlocks.
I just remind that it should be documented that __setitem__ is
collective.
Jan
>
> In additional boolean array indicing works:
>
> v[v<5.] = 5.0
>
> This obviously restricts to local values.
>
> I settled with calling apply("insert") inside the __setitem__ method.
> If a user want to have more fine grain control he can use set_local
> directly, and then take the responsibility for calling
> apply("insert") him self.
>
> What this new python layer implementation does not cover is slice
> assignments. Typically:
>
> v[0:20:2] = 1.0
>
> But I am not aware of any who uses it and it really does not make any
> sense in a parallel setting.
>
> Even though this is a pretty big change close to a release, I think
> it is long overdue and should go in before 1.5 release.
>
> The branch will be ready for review at the end of this week but any
> comments this far is highly appreciated.
>
> Johan
>
>
>
>
>
> On Fri, Nov 28, 2014 at 3:59 PM, Martin Sandve Alnæs
> <[email protected]> wrote:
>
> > If doing low level editing of vector values, yes.
> >
> > Unless we set dirty flags on __setitem__, and call apply elsewhere
> > whenever an updated vector is needed, as discussed before.
> >
> > There's probably a lot of common operations that we can add high
> > level utility functions for performing without accessing the vector
> > directly, making this issue rarer.
> >
> > Martin
> >
> >
> > On 28 November 2014 at 15:45, Johan Hake <[email protected]> wrote:
> >
> >> Are you saying that apply calls should be up to the user to call?
> >>
> >> Joahn
> >>
> >> On Fri, Nov 28, 2014 at 3:39 PM, Martin Sandve Alnæs
> >> <[email protected]> wrote:
> >>
> >>> I think there's a lot of merit to the concept of using numpy
> >>> views of the local vectors and require apply calls to communicate.
> >>>
> >>> Martin
> >>> 28. nov. 2014 15:04 skrev "Garth N. Wells" <[email protected]>:
> >>>
> >>>>
> >>>> On Thu, 27 Nov, 2014 at 7:38 PM, Johan Hake <[email protected]>
> >>>> wrote:
> >>>>
> >>>>> Hello!
> >>>>>
> >>>>> In some code I have I uses the indices interface to set local
> >>>>> dofs in a vector. It turns out that v[indices] = some_values
> >>>>> uses the GenericVector::set function instead of
> >>>>> GenericVector::set_local. This means that one need to pass
> >>>>> global indices.
> >>>>>
> >>>>> I typically use the slicing together with some combination of
> >>>>> indices I got from the vertex_to_dofs functionality. However,
> >>>>> now that returns local dofs and it then makes more sense to
> >>>>> switch the behavior of v[indices] to use local dofs.
> >>>>>
> >>>>> Any objections against switching to local indices in v[indices]?
> >>>>>
> >>>>
> >>>> I don't have any objections, but I also don't have a clear view
> >>>> of how we should interact with distributed vectors from Python
> >>>> re the NumPy wrapping. It's a bigger job, but it would be nice
> >>>> to think this through for a consistent interaction between
> >>>> distributed DOLFIN vectors and wrapping as NumPy objects.
> >>>>
> >>>> Garth
> >>>>
> >>>>
> >>>> Johan
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>> _______________________________________________
> >>>> fenics mailing list
> >>>> [email protected]
> >>>> http://fenicsproject.org/mailman/listinfo/fenics
> >>>>
> >>>
> >>
> >
_______________________________________________
fenics mailing list
[email protected]
http://fenicsproject.org/mailman/listinfo/fenics
