> On 9 Dec 2014, at 18:12, 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].
Does the range [0, local_size) include ghost values?
> 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.
>
> 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.
>
I can take a look early next week.
Garth
> 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
