Excessive/insfficient use of Function::update() throughout the library

[Jan Blechta]

Function::update() is used redundantly by assemblers. This may ruin scalability.

On the other hand, DirichletBC::compute_bc* lack these calls, see pull request #117.

So far suggested solutions:

• (Garth) update lately only when necessary; vector is flagged for ghost_consistence.
• (Martin) update early; user takes care of an update when fiddling with vector entries.

[Jan Blechta]

Here is actual MWE (run on two processes):

from dolfin import *

mesh = UnitSquareMesh(4, 5)
V = FunctionSpace(mesh, 'CG', 1)

class F(Expression):
    def eval(self, y, x):
        y[0] = 10.0
f = project(F(), V)
#f.update() # Uncomment to fix the problem

u = Function(V)

bc = DirichletBC(V, f, lambda x,onb:True)
bc.apply(u.vector())

plot(u, interactive=True)

[Jan Blechta]

Fix in pull request #117.

[Prof Garth Wells]

I think the best solution is that we add a state flag to vectors to track whether or not the ghost values are up-to-date. This way we can sprinkle Function::update() without a performance hit.

[Martin Sandve Alnæs]

I like Garths solution, is it feasible?

See also David Hams comment on the list: With Garths suggestion of dirty flags to vectors, access to the vector entries can mark the vector as dirty so the next time someone calls update it does the job.

[Prof Garth Wells]

@martinal It should be easy - we can set a flag to true after update() is called, and invalidate the flag when Generic::vector::set/get, etc is called.

We can add a boolean argument to update() so that it can be automatic (according to the internal state flag) or forced.

[Jan Blechta]

@garth-wells User could also have a possibility to reset a flag for the case he did not touch any ghost.

[Prof Garth Wells]

@blechta Yes, for fancier/advanced use we could let the user modify the flag.

[Prof Garth Wells]

Fix Issue #263.

Move calls to update vector ghost values to apply(), and after linear solves.

Epetra implementation is flaky, but Epetra interface needs an overhaul for parallel objects.

→ <<cset 756e630ada78>>

[Prof Garth Wells]

Fix Issue #263.

Move calls to update vector ghost values to apply(), and after linear solves.

Epetra implementation is flaky, but Epetra interface needs an overhaul for parallel objects.

→ <<cset 5c29b06be35d>>

[Jan Blechta]

@garth-wells Is it wise to remove GenericVector::update_ghost_values() which may be useful for special purpose? User would now need to downcast to PETScVector or EpetraVector.

[Prof Garth Wells]

@blechta I thought about keeping GenericVector::update_ghost_values(), but was swayed by not needing it in the code. I don't have a strong view either way.

[Jan Blechta]

@garth-wells Me neither. User probably finishes every fiddling with DOFs with GenericVector::apply.

[Prof Garth Wells]

Removing milestone: 1.4 (automated comment)