Dear Larry,
let me give a quick overview of how the measure domain type corresponds to
other components in ffc,ufc,dolfin to explain why using ds is no the right
approach.
The measures in ufl have a domain type that explicitly means
dx = integral over cells
ds = integral over exterior facets (one-sided)
dS = integral over interior facets (between two cells + and -)
+ some more specialized ones, please ignore those.
Look at <ffc>/ufc/ufc.h to see that each domain type corresponds to a class
class <domain_type>_integral
with a variant of tabulate_tensor(...) as well as a function
ufc::form::create_<domain_type>_integral(subdomain_id)
In the dolfin assembler, there is
one loop over cells that calls cell_integral::tabulate_tensor(...)
one loop over exterior facets that calls
exterior_facet_integral::tabulate_tensor(...)
one loop over interior facets that calls
interior_facet_integral::tabulate_tensor(...)
and notice that the various tabulate_tensor signatures are tailored to
match the expected data.
(Note: it would be _possible_ to generalize the tabulate_tensor signature,
but that is a significant extra task to take on, so please ignore that
route).
What you want is
1) a new assembler loop in dolfin that iterates over the edges and collects
the relevant
sets of cells and facets, similar to the interior facet assembly but a bit
more involved
2) a ufc::edge_integral class with a tabulate_tensor signature capable of
taking the
data the assembler needs to pass to generated code
3) a ufl Measure domain_type string "edge" exactly matching the
ufc::edge_integral class
(the 1-1 mapping simplifies ffc)
4) a new shortname for the measure, e.g. "dE".
If you really need 3 different variants of edge integrals, make 3 names,
e.g.:
de - arbitrary choice of one of the cell values (min cell index, for
example)
dE - average over all the adjacent cell values
dJ - sum over the jumps at all facets around the edge in the right-handed
direction (which happens to be the one I care about the most)
So that's my summary of the measure/integral/assembler design.
However I have a clarifying question for you:
Do you mean e.g.
a) integral over edge of (avg(f) * avg(g))
or
b) integral over edge of (avg(f * g))
and correspondingly (with jump(f) something like (f+ - f-))
A) sum_facets [ integral over facet of jump(f)*jump(g) ]
or
B) sum_facets [ integral over facet of jump(f*g) ]
In other words: do you mean jumps and averages of the entire integrand,
or of specific functions and test functions within the integrand?
Because those are not the same, and I think you might be trying
to put too much into the measure definition here.
Martin
On 10 August 2015 at 21:02, Martin Sandve Alnæs <marti...@simula.no> wrote:
> Don't use ds or dx. One or more new measures must be added. I'm back from
> vacation on Friday, will reply more in depth then.
> 7. aug. 2015 12.15 skrev "Garth N. Wells" <gn...@cam.ac.uk>:
>
>>
>> On 6 August 2015 at 07:49, Lizao Li <lixx1...@umn.edu> wrote:
>>
>>> Dear all,
>>>
>>> I plan to implement edge integral assembly in 3D in FEniCS.
>>>
>>
>> Nice. We have an open feature issue on this,
>> https://bitbucket.org/fenics-project/dolfin/issues/106.
>>
>>
>>> It is good for a number of things, for example assembling the canoniacl
>>> projection for 3D Nedelec edge elements. One issue is that there are more
>>> than 3 cells intersecting at an edge in 3D.
>>>
>>
>> My concern has been whether we can do edge integration efficiently
>> without clever analysis of the form. For example, if an edge integral
>> doesn't need all data from all connect cells (and there might be a lot of
>> connected cells), will an assembler that gets all data be performant?
>>
>>
>>> At the level of UFL, my design is to add,
>>> ds('m') - arbitrary choice of one of the cell values (min cell
>>> index, for example)
>>> ds('avg') - average over all the adjacent cell values
>>> ds('jump') - sum over the jumps at all facets around the edge in
>>> the right-handed direction (which happens to be the one I care about the
>>> most)
>>>
>>> Suggestions, hints, and pointers to a good starting point in particular
>>> are welcome~
>>>
>>>
>> I think we need something other than ds. Perhaps we need to be able to
>> pass the topological dimension to dx. Take a look in measure.py from UFL
>> for background.
>>
>> Garth
>>
>>
>>> Best regards,
>>> Larry
>>> --
>>> Lizao (Larry) Li
>>> Univeristy of Minnesota
>>>
>>> _______________________________________________
>>> 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
