ffc team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Tue, Feb 02, 2010 at 12:11:33PM +0000, Garth N. Wells wrote:
>
>
> 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

ok, that's easy to fix. In fact, it has been working for a long
time. :-)

--
Anders

Attachment: signature.asc
Description: Digital signature