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
signature.asc
Description: Digital signature
_______________________________________________ Mailing list: https://launchpad.net/~ffc Post to : [email protected] Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp
