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: bange...@colostate.edu
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.
