<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hi.<br>
Thanks Stefan for replying (even though you're a DG guy :-)<br>
That might be a solution one would just have to be consequent in
integrating it into the different parts of dune-fem.<br>
<br>
Perhaps a clearer approach would be to have a status on every
discrete function indicating if it is<br>
- in a modification state<br>
- in a communicated state<br>
This is quite close to what PetSc does. <br>
<br>
So basically if the df is in a modification phase <i>one can get
a non const local function (call axpy, operator[]</i> etc.) A
call to communicate then does the communication and changes the
state to <i>communicated</i>. After that any method which could
modify the function/functional would throw an assert. Any further
call to communicate would be ignored. Then one could have as many
calls to communicate as one wants. A call to clear would set the
discrete function/functional back into the modification state.<br>
<br>
In this case the EllipticOperator and the rhsAssemble etc. would
not call communicate (and they wouldn't call clear either). That
is left to the user or in the case of the NewtonInverseOperator
that would be done after calling operator(u,v).<br>
<br>
The drawback: it would mean a lot of change to code. If one uses
the NewtonInvOp with an operator that calls communicate then a
second call to communicate would result either in an assertion or
in unpredicted behaviour. <br>
<br>
There would be some other small consequence, e.g., the Dirichlet
data in the dune-fem-howto is now set after communicate is called
(to be more precise: it has to be set after communicate is called
otherwise one would get entries of the form:<br>
g_D(x_p)*(number of copies of x_p)<br>
But this can be avoided by some use of the slaveDofs etc.<br>
<br>
Best<br>
Andreas<br>
<br>
On 27/10/15 14:59, Stefan Girke wrote:<br>
</div>
<blockquote
cite="mid:trinity-105c9978-5fcd-41a2-abf2-8f9a1c28bc80-1445957947886@3capp-gmx-bs27"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<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 class="moz-txt-link-rfc2396E" href="mailto:a.s.dedner@warwick.ac.uk"><a.s.dedner@warwick.ac.uk></a><br>
<b>An:</b> <a class="moz-txt-link-rfc2396E" href="mailto:dune-fem-devel@dune-project.org">"dune-fem-devel@dune-project.org"</a>
<a class="moz-txt-link-rfc2396E" href="mailto:dune-fem@dune-project.org"><dune-fem@dune-project.org></a><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>
<a class="moz-txt-link-abbreviated" href="mailto:dune-fem@dune-project.org">dune-fem@dune-project.org</a><br>
<a moz-do-not-send="true"
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>
</blockquote>
<br>
</body>
</html>