<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>
<div>Hi Andreas,</div>
<div> </div>
<div>I do not know your described problem, since I am a DG guy. ;)</div>
<div> </div>
<div>One solution could be two new methods</div>
<div> </div>
<div>class DiscreteFunctionImplementation</div>
<div>{</div>
<div>//....</div>
<div>bool hasToBeCommunicated() const {</div>
<div> return commFlag_;</div>
<div>}</div>
<div>void setHasToBeCommunicated( const bool flag ) {</div>
<div> commFlag_ = flag;</div>
<div>}</div>
<div>private:</div>
<div>bool commFlag_;</div>
<div>};</div>
<div> </div>
<div>for discrete functions.</div>
<div>Instead of calling the communicate() method directly at the end of assembleRHS(), setHasToBeCommunicated() is called.</div>
<div>Once all discrete functions has got such two methods, each operator (NewtonInverseOperator, EllipticOperator...)</div>
<div>can handle this situation on his own since Fem-operators operates on discrete functions.</div>
<div> </div>
<div>One further advantage is that even the NewtonInverseOperator can set this flag</div>
<div>and the FemScheme can handle this communication issue.</div>
<div>Since a FemScheme (or Algorithm/Stepper in dune-fem-dg) glues all the stuff together</div>
<div>( solution/rhs, solver, assembler...) this is - in my mind - not negligible.</div>
<div> </div>
<div>(See also "needCommunication()" for localrestrictprolong in dune-fem...)</div>
<div> </div>
<div>Does this solve your communicate problem?</div>
<div> </div>
<div>Best regards</div>
<div>Stefan.</div>
<div>
<div style="margin: 10.0px 5.0px 5.0px 10.0px;padding: 10.0px 0 10.0px 10.0px;border-left: 2.0px solid rgb(195,217,229);">
<div style="margin: 0 0 10.0px 0;"><b>Gesendet:</b> Dienstag, 27. Oktober 2015 um 12:29 Uhr<br/>
<b>Von:</b> "Andreas Dedner" <a.s.dedner@warwick.ac.uk><br/>
<b>An:</b> "dune-fem-devel@dune-project.org" <dune-fem@dune-project.org><br/>
<b>Betreff:</b> [dune-fem] df.communicate</div>
<div>Hi.<br/>
A few times now I had the problem that when executing different methods<br/>
communicate on a discrete function was called more then once. For dg<br/>
functions that is not a problem but for lagrange type functions (okay<br/>
functionals) that's a major headache since dofs are added up during<br/>
communication. So an example is in the howto where both the application<br/>
of the operator does a communicate and assembleRHS does one as well. It<br/>
is not that easy to get rid of - in the assembleRHS it could be removed<br/>
but the operator() has to call communicate at the moment otherwise the<br/>
Newton solver wouldn't work (it assumes that the functional is<br/>
completely computed after the call to operator().<br/>
I was wondering if others have had that problem (as I said dg people<br/>
once again have an easy life here...). Does someone have an idea of how<br/>
to solve this? A similar problem btw is with the call to clear....<br/>
Should we remove clear/communicate from the operators and have the<br/>
solvers, i.e., Newton etc do the corresponding calls?<br/>
I am really not quite sure what a good solution is but the situation is<br/>
complicated because it is difficult to keep track of the places where<br/>
clear/communicate might be called....<br/>
Andreas<br/>
<br/>
_______________________________________________<br/>
dune-fem mailing list<br/>
dune-fem@dune-project.org<br/>
<a href="http://lists.dune-project.org/mailman/listinfo/dune-fem" target="_blank">http://lists.dune-project.org/mailman/listinfo/dune-fem</a></div>
</div>
</div>
</div></div></body></html>