[dune-fem] df.communicate

[Andreas Dedner]

Hi.
Thanks Stefan for replying (even though you're a DG guy :-)
That might be a solution one would just have to be consequent in 
integrating it into the different parts of dune-fem.

Perhaps a clearer approach would be to have a status on every discrete 
function indicating if it is
- in a modification state
- in a communicated state
This is quite close to what PetSc does.

So basically if the df is in a modification phase /one can get a non 
const local function (call axpy, operator[]/ etc.) A call to communicate 
then does the communication and changes the state to /communicated/. 
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.

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).

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.

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:
     g_D(x_p)*(number of copies of x_p)
But this can be avoided by some use of the slaveDofs etc.

Best
Andreas

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dune-project.org/pipermail/dune-fem/attachments/20151030/9ea2a5f6/attachment.htm>