Ok great - good to know that I am implementing it correctly. I'm not sure - I didn't think it would have mattered, but something seems to be going wrong with the Dirichlet condition application (when I remove that snippet of code, the solution is at least smooth).
The values I am using are correct, as I am feeding in the exact solution for u.n conditions on the sides and bottom (since I know u) and the exact value also for p. I've of course modified the right hand side to account for extra source terms in the method of manufactured solutions. I do VectorTools::project_boundary_values_div_conforming (dof_handler, 0, ExactFunction<dim>(), 2, constraints) where 2 is the boundary id for sides and bottom. For boundary id 1 which is the top, I put in the Dirichlet condition in the weak form: local_rhs(i) += -(fe_face_values[velocities].value (i, q) * fe_face_values.normalvector(q) * boundary_values[q] * fe_face_values.JxW(q)); I believe that's all you need to do. I wondered whether the value where the side and top boundary meet as shown in that screenshot is getting messed up once I apply the constraints over the solution after I have solved for it? 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.
