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