In my case they need to be coupled to variables defined on the interior as
well as variables defined on the manifold. Here's the set up:
1. build_cube()
2. "u" defined on the whole cube
3. "v" defined only on boundary 1
u will have a boundary condition on boundary 1 that needs access to v. v
If find_neighbors is called, and also importantly the DofMap is updated to find
vol/surface coupling (not just vol/vol through a face) I think that'd be close.
> On Mar 27, 2014, at 5:43 PM, "Derek Gaston" wrote:
>
> What do you think about THAT plan?
-
Hmm, probably not too different from the subdomain restricted codepath, but
what do they need to couple to? The other elements on the manifold only, or
also the volume elements?
A challenge is when you have a side it doesn't know it's neighbors,
complicating the sparsity graph.
-Ben
> On M
Yeah - they're fully coupled to interior variables. I can do it with a
sub-solve and a projection... but I would rather not.
Now that I think about it - BoundaryMesh won't work because it creates a
separate Mesh... meaning a separate EquationSystems.
What I really need is more like if you ran ov
Roy's right, we do this to post process surface data for fluids computations.
These values don't need to be coupled to the interior field, or do they? We
just usually solve a projection.
> On Mar 27, 2014, at 5:16 PM, "Roy Stogner" wrote:
>
>
>> On Thu, 27 Mar 2014, Derek Gaston wrote:
>>
How about restricting the variable to the boundary - is there any path
forward on that?
Derek
On Thu, Mar 27, 2014 at 4:16 PM, Roy Stogner wrote:
>
> On Thu, 27 Mar 2014, Derek Gaston wrote:
>
> Is this the place to use BoundaryMesh?
>>
>
> That's what we do, yeah.
>
>
> Can you get the norma
On Thu, 27 Mar 2014, Derek Gaston wrote:
> Is this the place to use BoundaryMesh?
That's what we do, yeah.
> Can you get the normals for the elements when you're on a
> BoundaryMesh?
Not directly, but you can get_dxyzdxi()/get_dxyzdeta(), and take the
cross product of those two for the normal.
