On Wednesday 19 August 2009 19:59:00 [email protected] wrote: > > 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?
Should we issue an error, or should we try to work with the local values? Johan > Kent _______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
