We could of course add an interface to setting the values of the dofs which could co-exist with our current interface. One option would be a new class like DOFBC, DirichletDOF, DirichletDOFBC which is expected to set the value of the DOF directly. Most of the implementation would be common with DirichletBC but instead of calling evaluate_dof on the Expression, we would directly ask the user for the value (via an Expression).
-- Anders lör 10 okt. 2015 kl 09:52 skrev Garth N. Wells <gn...@cam.ac.uk>: > 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
