On 9 October 2015 at 22:58, Anders Logg <anders.l...@gmail.com> wrote:
> If you use the ufc::cell version of Expression::eval you can access the > cell normal via ufc::cell.local_facet. > > I can do that, but was hoping I could use the simple JIT-compiled interface, e.g. bc = DirichletBC(W, Constant(1.0), domain, 1) Garth I see the point in being able to specify the value of the normal component > but it's a bit of a special case. In general the dofs can be integral > moments or certain components at certain points and then it's unclear what > you really need to specify. Better then to specify a function of the same > value dimension and say that this function should agree for all the dofs on > the facet. > > -- > Anders > > > fre 9 okt. 2015 kl 22:32 skrev Garth N. Wells <gn...@cam.ac.uk>: > >> I thought you might reply, Doug! >> >> On 9 October 2015 at 21:14, Douglas N Arnold <arn...@umn.edu> wrote: >> >>> How would you handle H(curl) spaces in a consistent way? >>> >> >> H(curl) is trickier, but not a problem I'm facing at the moment. >> >> >>> There you have to provide a tangential vector field, but there >>> is no natural basis for the tangent space. The current method >>> is to apply a full n-vector but only to pay attention to the >>> tangential part (I believe). The analogue is the current >>> approach for H(div) as well. >> >> >> Yes, for H(div) it pulls out the normal part. What's tedious is that in a >> JIT-compiled Expression I don't have ready access to the normal vector. For >> the physical problem I'm modelling I know u.n - it would be natural if this >> was easy to apply. It's also misleading for the naive user that they can >> supply the full n-vector when part of it is discarded. >> >> Garth >> >> >>> I see real problems in changing >>> one of these, but not the other. >>> >>> -- Doug >>> >>> >>> On 10/09/2015 01:48 PM, Garth N. Wells wrote: >>> >>>> In DOLFIN, when applying Dirichlet bcs to H(div) spaces, DOLFIN insists >>>> that the bc function is a vector-valued function, whereas the physically >>>> and mathematically natural function is scalar (normal component). The >>>> present state is annoying when boundaries are not axis-aligned. >>>> >>>> Does anyone have a nice fix for this, or will it require low-level >>>> changes? Looks like the problem is ufc::finite_elemenent::restrict. >>>> >>>> Garth >>>> >>>> >>>> _______________________________________________ >>>> fenics mailing list >>>> fenics@fenicsproject.org >>>> http://fenicsproject.org/mailman/listinfo/fenics >>>> >>>> _______________________________________________ >>> fenics mailing list >>> fenics@fenicsproject.org >>> http://fenicsproject.org/mailman/listinfo/fenics >>> >>
_______________________________________________ fenics mailing list fenics@fenicsproject.org http://fenicsproject.org/mailman/listinfo/fenics
