ffc team mailing list archive

["Garth N. Wells" <gnw20@xxxxxxxxx>]

Mehdi Nikbakht wrote:
> On Tue, 2010-02-02 at 12:01 +0100, Anders Logg wrote:
>> On Tue, Feb 02, 2010 at 11:56:10AM +0100, Mehdi Nikbakht wrote:
>>> On Tue, 2010-02-02 at 11:52 +0100, Anders Logg wrote:
>>>> On Tue, Feb 02, 2010 at 11:24:46AM +0100, Mehdi Nikbakht wrote:
>>>>> On Tue, 2010-02-02 at 11:18 +0100, Anders Logg wrote:
>>>>>> On Tue, Feb 02, 2010 at 11:16:20AM +0100, Mehdi Nikbakht wrote:
>>>>>>> On Tue, 2010-02-02 at 10:50 +0100, Anders Logg wrote:
>>>>>>>> On Tue, Feb 02, 2010 at 10:42:23AM +0100, Mehdi Nikbakht wrote:
>>>>>>>>>
>>>>>>>>> On Tue, 2010-02-02 at 10:30 +0100, Anders Logg wrote:
>>>>>>>>>> I tried looking at this but I'm unsure how it should be
>>>>>>>>>> handled. Should a cell_integral class be generated or should a
>>>>>>>>>> surface_integral class be generated?
>>>>>>>>>>
>>>>>>>>> We handle terms related to surface integral inside a class derived from
>>>>>>>>> ufc::cell_integral. I have started working on updating ffcpum module
>>>>>>>>> which is built against standard ffc.
>>>>>>>>>
>>>>>>>>> Mehdi
>>>>>>>> So a surface integral should just result in a standard cell integral
>>>>>>>> being generated? Then what is the point of having *dc? When the code
>>>>>>>> has been generated, you won't be able to tell which cell integrals
>>>>>>>> came from *dx and which came from *dc.
>>>>>>> Although we could have them in a separate class, we handle them inside
>>>>>>> cell_integral class to have compatibility with ufc interface.
>>>>>>>
>>>>>>> Note that having *dc helps us to compute the corresponding terms by
>>>>>>> using gauss points located on a surface.
>>>>>>>
>>>>>>> I don't see the point on being able to tell which cell integrals came
>>>>>>> from *dx and which one from *dc, we add all of them to the global
>>>>>>> element tensor.
>>>>>> My point is that if FFC should treat *dc in exactly the same way as
>>>>>> *dx, then you might as well just write *dx and we can remove the
>>>>>> "support" for *dc in FFC.
>>>>>>
>>>>>> Or you could just write dc = dx in your form files.
>>>>> No, it is not the case. They are handled differently inside ffc, we only
>>>>> add them inside ufc::cell_integral in the code generation stage.
>>>> ok, so the code example you sent me (Poisson.h) is code generated by
>>>> FFC? Not a version you have modified. I didn't know that was
>>>> supported.
>>> No, this is generated by ffc-pum which is a module on the top of
>>> standard ffc. To compile this file, one need just run,
>>>
>>>>> ffcpum -l dolfin Poisson.ufl
>> Then I don't really understand what goes on. Should or should not FFC
>> treat surface integrals in exactly the same way as standard integrals?
> 
> No, we should not treat them as standard integrals. However, I am not
> sure how it should be handled inside FFC. 
> 
> For now, it is better to throw an error for this case in standard FFC.
> Garth, what do you think?
> 

It should throw an error if it's not supported by FFC.

Garth

> 
> Mehdi
> 
>> --
>> Anders
>>
>>
>>
>