Dear Martin, Thank you for your quick reply. I tried as you suggested, and set the initial condition by computing a right hand side, and it lowered the difference between the initial condition and the first time step by about a factor of 5. So it helped, but didn't make a qualitative change.
While doing that test, I realized that I was wrong in my first post where I said that the artifacts are only present between the initial condition and the first time step -- I missed that the field is only outputted every 200 time steps. Changing it so that it outputs every time step, it turns out that the solution changes by up to 1e-8 between time steps for the first 40 time steps or so before settling down. Assuming that this is just intrinsic error in the approximation of the mass matrix, given how you said that the implementation has been repeatedly verified, it must just be that I'm being too aggressive in choosing where to coarsen my mesh. Thank you for sending me that paper -- I'll read through it to better understand the approximations that go into the diagonal mass matrix. Thanks again, Steve On Friday, September 8, 2017 at 1:03:48 PM UTC-4, Martin Kronbichler wrote: > > Dear Stephen, > > At hanging nodes, there is definitely going to be a larger error due to > the approximation of the diagonal mass matrix. I do not remember the > exact details but to get a diagonal mass matrix you need to assume an > interpolation in addition to the approximation leading to the mass > lumping. If I remember correctly my co-worker Katharina Kormann > describes this in her paper: > https://doi.org/10.4208/cicp.101214.021015a > > So in general, I would assume that a change of 1e-8 as you have in your > picture is simply the approximation error that occurs when going from > the initially interpolated solution to the new mesh. I would assume that > it goes away if you compute an "approximate" L2 projection where you > compute a right hand side (v, u_init) for test functions v and the > initial field u_init from ExactSolution of step-48 rather than > VectorTools::interpolate. > > Have you tried that? > > If the change is larger in other cases as you describe, I would be more > worried. Have you tried to investigate more? Does the projection instead > of interpolation help in that case, too? > > The implementation should be correct as far as I can tell - we have > verified it on a large series of applications. In my experience, the > most tricky thing to get right regarding constraints and boundary > conditions is for nonlinear problems or implicit solvers with > inhomogeneous boundary data, but that appears to not be the case here... > > Best, > Martin > > > -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
