On Tue, 9 Dec 2014 21:08:03 +0100 Johan Hake <[email protected]> wrote:
> On Tue, Dec 9, 2014 at 7:25 PM, Jan Blechta > <[email protected]> wrote: > > > 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. > > > > Sure, but it is not natural to document a special method with a doc > string. any suggestions where such documentation should reside? I'd say to add something like %feature("docstring") dolfin::*Vector::__setitem__ "Sets local values blah, blah. Is collective, must be called by all ranks simultaneously."; so that it is included in Sphinx doc of *Vector classes. Jan > > Johan > > Jan > > > > > > > > In additional boolean array indicing works: > > > > > > v[v<5.] = 5.0I 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. > > > > > > > > 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
