warning about "Creating new TransferManager to transfer data to coarse grids"
Dear Firedrake -- When I run the demo code https://www.firedrakeproject.org/demos/geometric_multigrid.py.html I get output with the warning firedrake:WARNING Creating new TransferManager to transfer data to coarse grids firedrake:WARNING This might be slow (you probably want to save it on an appctx) The same warning appears for my own codes, which often use -pc_type mg. This is new behavior for me, i.e. as of a firedrake update about 2 months ago. How should I update this demo to avoid the warning message? Is there an example where it is added to an appctx? I'm curious about the cause of the warning, because I would not want mesh-specific info in a PETSc appctx, generally, I think ... Thanks! Ed -- Ed Bueler Dept of Mathematics and Statistics University of Alaska Fairbanks Fairbanks, AK 99775-6660 306C Chapman
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, Ed On Sat, Apr 18, 2020 at 6:15 PM Ed Bueler <elbueler@alaska.edu> wrote:
Dear Firedrake --
When I run the demo code https://www.firedrakeproject.org/demos/geometric_multigrid.py.html I get output with the warning
firedrake:WARNING Creating new TransferManager to transfer data to coarse grids firedrake:WARNING This might be slow (you probably want to save it on an appctx)
The same warning appears for my own codes, which often use -pc_type mg. This is new behavior for me, i.e. as of a firedrake update about 2 months ago. How should I update this demo to avoid the warning message?
Is there an example where it is added to an appctx? I'm curious about the cause of the warning, because I would not want mesh-specific info in a PETSc appctx, generally, I think ...
Thanks!
Ed
-- Ed Bueler Dept of Mathematics and Statistics University of Alaska Fairbanks Fairbanks, AK 99775-6660 306C Chapman
-- Ed Bueler Dept of Mathematics and Statistics University of Alaska Fairbanks Fairbanks, AK 99775-6660 306C Chapman
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
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
On 20 Apr 2020, at 15:55, Patrick Farrell <patrick.farrell@maths.ox.ac.uk> wrote:
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.)
It happens for me in the multigrid demo when injecting the BC value (defined on V rather than W.sub(0)). Lawrence
Yup. Just updated. The multigrid demo still gives the warning, just once, while the warning seems to have gone away for my own stokes code. Ed PS The firedrake-update script always fails for me. Locks-up my machine, essentially; I can't even get a screenshot of the mysterious error messages which appear with mouse clicks. So then I download a fresh copy and it is fine (but slow over the network). Using ubuntu 18.04. Any ideas? On Mon, Apr 20, 2020 at 6:58 AM Lawrence Mitchell <wencel@gmail.com> wrote:
On 20 Apr 2020, at 15:55, Patrick Farrell < patrick.farrell@maths.ox.ac.uk> wrote:
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.)
It happens for me in the multigrid demo when injecting the BC value (defined on V rather than W.sub(0)).
Lawrence _______________________________________________ firedrake mailing list firedrake@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/firedrake
-- Ed Bueler Dept of Mathematics and Statistics University of Alaska Fairbanks Fairbanks, AK 99775-6660 306C Chapman
participants (4)
-
Ed Bueler
-
Lawrence Mitchell
-
Lawrence Mitchell
-
Patrick Farrell