Hi Ed, Does it still happen in your code with the most recent firedrake? A branch was merged that fixes one out of two of the warnings issued in the geometric multigrid demo. (We should still track down the other one.) Patrick On 20/04/2020 08:55, Lawrence Mitchell wrote:
Hi Ed,
On 20 Apr 2020, at 04:40, Ed Bueler <elbueler@alaska.edu> wrote:
Dear Firedrake --
Following up with more clarity on my part, I see that the warning comes from get_transfer_operators() in dmhooks. Furthermore, I see that I do not get the warning when using -pc_type mg in simple things (like Poisson). Apparently it arises because I am using options like -pc_type fieldsplit -fieldsplit_0_pc_type mg and etc. The demo geometric_multigrid.py and my own code solve the Stokes equations.
So I am guessing that I should not be putting anything into my own (application) appctx, but rather this is about a Firedrake object's existing appctx? I am trying to interpret the top of the dmhooks docstring """ Firedrake uses PETSc for its linear and nonlinear solvers. The interaction is carried out through DM objects. These carry around any user-defined application context and can be used to inform the solvers how to create field decompositions (for fieldsplit preconditioning) as well as creating sub-DMs (which only contain some fields), along with multilevel information (for geometric multigrid) """ I am going fishing for info on whether *I* should be fixing something or ya'll should be, to make the warning go away and/or to setup and store the appropriate DM info so that the warning is not triggered.
Thanks, and noting that Firedrake really works for me,
In the demo this appears because in the fieldsplit case we must inject the boundary value into the coarse grids. The idea we have is that we have a TransferManager (one per solver) that shares any (possibly expensive) transfer matrices between different calls of the grid transfer. Finding it is not always perfect (in this case it looks like the bc value we inject is sufficiently "disconnected" from the solve that we didn't find the solver's transfer manager, and made a fresh one.
If these are made every time you go round the multigrid cycle, it can be expensive, hence the warning.
In your code, I imagine a similar thing is happening. I think this is something we need to fix (rather than you). We were probably doing the same previously, except we recently merged some changes that warn when this occurs.
Assuming your code just spews the single warning, I guess the multigrid demo is sufficient to chase this down. If you have many warnings, it might be useful to see your code too.
Thanks,
Lawrence
_______________________________________________ firedrake mailing list firedrake@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/firedrake