Computing inv diagonal values multiple consecutive times does result in different vectors.

Discovered by @burkhart

added bug label

assigned to @kohl

You can change

f"    {self.dst.name}->interpolate( 0, level );\n"

to

f"    {self.dst.name}->interpolate( 0, level );\n"
f"    communication::syncFunctionBetweenPrimitives( *{self.dst.name}, level );\n"

in the respective kernel operation / kernel type and that seemingly fixes the issue.

Why did we change that from setToZero() to interpolate(0) in c72965a5?

Oops. Could have been due to vector functions not implementing setToZero() and missed that this breaks stuff :/ ...

Missed that myself. Would it make sense to implement such a function for vector functions? (Not suggesting that we should, just asking questions.)

The costs for implementing that are basically nil, at least for the CSFFunction children. So why not? It is definitely more efficient than interpolating and then communicating.

I added this as suggestion: hyteg#274 (closed)

All relevant function classes in HyTeG now support setToZero(). Thus, this should be fixable in HOG without breaking stuff now.

mentioned in issue hyteg#274 (closed)

mentioned in commit 7f462bbb

mentioned in merge request !21 (merged)

mentioned in commit 3190dc38

closed via commit 7f462bbb

closed via merge request !21 (merged)