dolfin team mailing list archive

[kent-and@xxxxxxxxx]

> On Wednesday 19 August 2009 19:11:42 Garth N. Wells wrote:
>> Johan Hake wrote:
>> > On Wednesday 19 August 2009 18:50:13 Garth N. Wells wrote:
>> >> Johan Hake wrote:
>> >>> On Wednesday 19 August 2009 17:29:52 Garth N. Wells wrote:
>> >>>> What's going on behind the scene when I copy one vector to another
>> in
>> >>>> PyDOLFIN using
>> >>>>
>> >>>>      u0.vector()[:] = u.vector()[:]
>> >>>
>> >>> When I add:
>> >>>
>> >>> u2 = Function(V)
>> >>> u2.vector()[:] = u.vector()[:]
>> >>>
>> >>> # Plot solution
>> >>> plot(u2)
>> >>>
>> >>> In a the Poisson demo it works fine.
>> >>
>> >> In parallel?
>> >
>> > Yupp!
>> >
>> >>> This type of slice only uses the assignment operator.
>> >>
>> >> The GenericVector assignment operator?
>> >
>> > Yes. This is done in __setslice__/__getslice__ in the extended python
>> > class.
>>
>> I don't see then why the we end up inside
>>
>>    _compare_vector_with_vector
>>
>> for the Cahn-Hilliard demo when running in parallel?
>
> Are you sure it is in
>
>   _compare_vector_with_vector
>
> this should only kick in if you used '==' or some other comparison
> operator.
>
> When I run this demo in parallel, I get passed the assignment line but it
> stops when calling the solve function with the following message:
>
> Traceback (most recent call last):
>   File "demo.py", line 86, in <module>
>     Traceback (most recent call last):
> solver.solve(problem, u.vector())
> RuntimeError: *** Error: MUMPS is required for parallel symbolic LU.
>
>
>> >> I delved into the problem and the program ends up in the function
>> >> _compare_vector_with_vector from dolfin_la_get_set_items.i. It uses
>> >> GenericVector::get and GenericVector::set. These need to be used with
>> >> caution in parallel.
>> >
>> > Yes, when other type of slices are used we need to find a way to do
>> that
>> > in parallel. I have just started digging in the parallel code, and
>> need
>> > to look into all the changes to get familiar with it before I try to
>> > solve this.
>>
>> This shouldn't be too hard.
>>
>>     set(const double* block, uint m, const uint* rows)
>>
>> works in parallel but
>>
>>     get(double* block, uint m, const uint* rows)
>>
>> doesn't yet (not too hard to fix though). The really evil functions are
>>
>>    set(const double*)
>>
>> and
>>
>>    get(double*)
>
> I think I am only using
>
>    set(const double* block, uint m, const uint* rows)
>    get(double* block, uint m, const uint* rows)
>
> However GenericVector.array is using the get(double*) function, and
> returns
> some fishy numbers in the numpy.array.
>
> Johan
>

I guess anything that involves NumPy will turn into garbage in parallel,
right?

Kent