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
