I agree... It also creates some overhead in typical time loops:
for t in times: u = solve_some_problem(u0) u0.assign(u) Then for each u0.assign the vector is recreated, which is why (in the present implementation) you should use: u0.vector().axpy(u.vector(), 1.0) instead. Johan On Mon, May 26, 2014 at 2:17 PM, Martin Sandve Alnæs <[email protected]>wrote: > I don't see how f.zero() is harder or less safe than f = Function(V)? > And the parallel pattern must be consistent with the DofMap, and > the FunctionSpace is not recreated, so I don't see that argument either :) > > I would rather argue that this behaviour is unsafe, as proven by the > original question. > > Martin > > > On 26 May 2014 14:13, Johan Hake <[email protected]> wrote: > >> I would assume because it is easier and safest to implement. Then you >> always know you have the same parallel pattern aso. >> >> Johan >> >> >> On Mon, May 26, 2014 at 1:59 PM, Miroslav Kuchta <[email protected]>wrote: >> >>> Thanks for clarification. I thought that that Function.assign simply >>> fills the vector of expansion coefficients >>> with new values, but I see now, that it creates a new vector with >>> updated values. Just out of curiosity, why >>> is it necessary to recreate the vector? >>> >>> Miro >>> >>> >>> On 05/26/2014 01:52 PM, Johan Hake wrote: >>> >>> And I do get the same values. It is just the third printed value of >>> the function using assign(foo) that differs. That value comes from the >>> vector of the original Function, which never gets it values updated. >>> >>> Johan >>> >>> >>> On Mon, May 26, 2014 at 1:48 PM, Martin Sandve Alnæs <[email protected] >>> > wrote: >>> >>>> I don't see how the id of a vector has anything to do with its value. >>>> The norm that Miro prints should be the same. >>>> >>>> Martin >>>> >>>> >>>> On 26 May 2014 13:43, Johan Hake <[email protected]> wrote: >>>> >>>>> To be honest, I would also assume these two to print the same. But I >>>>> have been bit by the Function::assign-recreate-the-vector behavior quite >>>>> many times now. The point is that the vector in a Function gets recreated >>>>> after an assign. >>>>> >>>>> from dolfin import * >>>>> mesh = UnitSquareMesh(2,2) >>>>> V = FunctionSpace(mesh,"CG",1) >>>>> u0 = Function(V) >>>>> u1 = Function(V) >>>>> >>>>> U = u0.vector() >>>>> print "Same:", U.id()==u0.vector().id() >>>>> u0.assign(u1) >>>>> print "Same:", U.id()==u0.vector().id() >>>>> >>>>> Johan >>>>> >>>>> >>>>> On Mon, May 26, 2014 at 1:32 PM, Martin Sandve Alnæs < >>>>> [email protected]> wrote: >>>>> >>>>>> Johan, I don't understand what you mean by that. I would also expect >>>>>> these to do the same, i.e. result in an exact copy of ut.vector()? >>>>>> >>>>>> Martin >>>>>> >>>>>> >>>>>> On 26 May 2014 13:27, Johan Hake <[email protected]> wrote: >>>>>> >>>>>>> Function.assign re-create the FOOvector holding the actual values. >>>>>>> I assume this explains the difference in behavior. >>>>>>> >>>>>>> Johan >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, May 26, 2014 at 1:09 PM, Miroslav Kuchta <[email protected] >>>>>>> > wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> please consider the attached snippet. I would assume foo() and bar() >>>>>>>> to do the same thing but that is not the case. Is this a bug in >>>>>>>> Function.assign() or am I missing something about the method's >>>>>>>> behaviour? >>>>>>>> Thanks for answer. >>>>>>>> >>>>>>>> Regards, Miro >>>>>>>> _______________________________________________ >>>>>>>> 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
