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.
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 <marti...@simula.no>
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 <hake....@gmail.com> 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 <marti...@simula.no>
>> 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" <gn...@cam.ac.uk>:
>>>
>>>>
>>>> On Thu, 27 Nov, 2014 at 7:38 PM, Johan Hake <hake....@gmail.com> 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
>>>> fenics@fenicsproject.org
>>>> http://fenicsproject.org/mailman/listinfo/fenics
>>>>
>>>
>>
>
_______________________________________________
fenics mailing list
fenics@fenicsproject.org
http://fenicsproject.org/mailman/listinfo/fenics
