I'm also wondering if x[:] = y
for x,y GenericVectors will 1. stop to work, 2. work through numpy, 3. work directly in C++ layer Now it goes through 3 and if it became 2 users would continue using it although it would be very inefficient. Jan On Tue, 9 Dec 2014 21:43:05 +0100 Johan Hake <[email protected]> wrote: > On Tue, Dec 9, 2014 at 9:39 PM, Jan Blechta > <[email protected]> wrote: > > > On Tue, 9 Dec 2014 21:34:43 +0100 > > Jan Blechta <[email protected]> wrote: > > > > > 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."; > > > > Maybe add "do-nothing" suggestion > > > > "... Is collective, must be called by all ranks simultaneously. To > > do-nothing on some process do x[[]] = []." > > > > or whatever is correct. > > > > Sounds like a good suggestion as that is what is intended. > > Johan > > > > > > > Jan > > > > > > > > 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 > > > > _______________________________________________ > > fenics mailing list > > [email protected] > > http://fenicsproject.org/mailman/listinfo/fenics > > _______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
