Also, as additional comments (having run some more tests), The Dirichlet condition application is fine - I get the correct solutions and convergence rates when Dirichlet conditions are defined on the entire boundary.
When u.n = u_known.n is applied everywhere, this doesn't give the correct solution, though it is smooth, so I believe there's something going on with the way I am using project_boundary_values_div_conforming. I have no idea at this point what it could be..... On Saturday, September 8, 2018 at 3:48:12 AM UTC+1, Wolfgang Bangerth wrote: > > > > With what you are saying with the normal vector, having looked at the > > documentation, I'm unsure as to why I need to know this? It says that > "i.e. > > the normal components of the solution u and a given f shall coincide. > The > > function f is given by |boundary_function| " so I have fed in the > function f > > which is a vector field, without explicitly stating the normal (as I > assumed > > it thought the normals were calculated somehow). > > Yes, that works. > > What we were trying to say is this: the boundary conditions are of the > form > u.n = g > where g is a scalar function -- say, you have a flow of 3 cubic meters per > second per (square meter of surface area). So, conceptually, we should > have a > function that takes a scalar function as argument. > > But, as a historical accident, the function takes a vector field, say \vec > h, > and then internally computes g=\vec h . n. What this implies is that if > you > were given the physical quantity g, and the function requires you to > provide > an h, then you need to find a way to compute an h out of the g, and the > way to > do this is clearly to set > h = g n > but in order to do that, you will need to know n which is a bit cumbersome > to > obtain when all your function h is given is the point x at which to > evaluate. > > On the other hand, oftentimes you are interested in testing that you > converge > to the correct solution, and in that case you will simply want to set h to > the > exact solution. (This is, indeed, how the "historical accident" happened.) > > > > Doing this, I have something like > > VectorTools::project_boundary_values_div_conforming (dof_handler, 0, > > FluxFunction<dim>(), 2, constraints), where the 2 is the boundary id. > This > > seems to run fine though I have something funny going on in the corner > where > > the Dirichlet boundary and side boundary (flux condition) meet. Is this > > because of some order I've messed up when I am imposing the conditions?? > > (please see photo for the odd instability in the corner of my domain). > The > > solution inside the domain is correct, and this still happens however > much I > > refine the grid. > > > > > > For more info, the VectorTools flux conditions are in my setup_dofs > code, > > within costraints.clear()... constraints.close(). After assembling the > system, > > I don't use the distribute local to global function but I instead > distribute > > the constraints onto the solution after I have solved the system. Is > there > > something wrong with the order?? I am getting a similar issue with > equations > > like step-22 but I will post separately as it is different. > > I'm not sure what is happening there. Does the order in which you put the > Dirichlet and the flux conditions into the constraints object matter? > > Best > W. > > -- > ------------------------------------------------------------------------ > Wolfgang Bangerth email: bang...@colostate.edu > <javascript:> > www: http://www.math.colostate.edu/~bangerth/ > > -- 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.
