dolfin team mailing list archive

["Dag Lindbo" <dag@xxxxxxxx>]

It was never my intention to make this a patch for FFC - such decisions I
leave to the developers. However, let me make a few points that support
having separate files for declarations and implementation:

*) From the compilers point of view I think headers sholuld be 'clean'
(i.e. not even inline functions).

*) Solvers, in my case at least, are changed more often than forms. It
would make sense that the form implementations are not recompiled when the
solver is changed. This actually becomes a real issue when the forms
become complicated. We have dicussed compile time on this list before.

*) Due to compile time it is often neccesary to lower optimization levels
on more complicated forms. Compiling the form separately makes this more
convenient.

/Dag

> On Tue, Oct 31, 2006 at 05:16:33PM +0100, Dag Lindbo wrote:
>>> Hi all,
>>>
>>> I'm seeing really great speedup due to the new mesh class in DOLFIN
>>> 0.6.3!
>>> Other reaction?
>>>
>
>>Yes, I'm also seeing speedups, the old mesh had overhead which seems
>>to be gone now. I haven't done any real benchmarks yet though. The new
>>mesh is also a much better abstraction and I really like it.
>
> I'm working on some benchmarks for the new mesh that I will present in
> Delft next week. I'm mostly happy with the speed we get but we could
> improve in some places. The mesh is designed to be very fast but I
> have made absolutely no optimizations (other than by design) so there
> is room for improvements.
>
>>> Well, I had to make changes in FFC in order to compile my solvers
>>> with
>>> 0.6.3. Let me share the problem (and a proposed fix).
>>>
>>> As I understand it, there is a consolidation between DOLFIN and SWIG
>>> formats in DOLFIN 0.6.3/FFC 0.3.4 (Johan J: isn't this correct?).
>
>>Yes, this is correct, we had two different formats due to SWIG not
>>supporting nested classes. We've managed to come up with a workaround
>>though.
>
>>> The problem (that is new in 0.6.3) is that if one uses the same
>>> form-header in two classes (that are both used in a particular
>>> solver)
>>> then there will be an error at link-time due to multiple
>>> implementation of
>>> the form. Take this example:
>>>
>>> Class GeneralFunctions
>>>     *) Includes a form header, formX.h
>>>
>>> Class LevelSetSolver
>>>     *) Uses stuff from GenericFunctions
>>>
>>> Class FlowSolver
>>>      *) Uses stuff from GenericFunctions as well
>>>
>>> Class TwoPhaseFlowSolver
>>>      *) Uses FlowSolver and LevelSetSolver
>>>      *) Has main()
>>>
>>> All classes compile. This means that the code in the formX header is
>>> compiled into object code in multiple places. Then linker will fail
>>> due to
>>> redefinitions of the formX implementation.
>
>>Ok, the idea was that the new format should be semantically equivalent
>>to the old format. But it seems we overlooked one thing. The old
>>format looked like this:
>>
>>class A
>>{
>>  void foo()
>>  {
>>  }
>>}
>>
>>and the new format looks like this:
>>
>>class A
>>{
>>  void foo();
>>}
>>
>>void A::foo()
>>{
>>}
>>
>>But apparently this is not equivalent, putting the implementation
>>inside the class definition implicitly makes the function inline, so
>>it should look like this:
>>
>>class A
>>{
>>  void foo();
>>}
>>
>>inline void A::foo()
>>{
>>}
>
>>> What I did to solve this was to change the output format of FFC so
>>> that I
>>> get form declarations in .h-files and form implementations in the
>>> corresponding .cpp-files. This way the form implementations are only
>>> compiled into object code once, so the linkage is fine.
>
>>Yes, this would be the cleanest solution. The question is if we want
>>to make such a structural change when we will change to a different
>>format soon anyway. It would break all the DOLFIN demos for example,
>>which assume only one source file
>
> I'd prefer only one file.
>
>>> If anyone else is has plans to move to 0.6.3 and has forms that are
>>> used
>>> in multiple classes, then I think the best option is to do this
>>> change in
>>> FFC. Let me know, and I'll send a simple patch. Coming releases of
>>> FFC/DOLFIN will use a new format, and the linkage problem will be
>>> dealt
>>> with then (according to Anders Logg).
>>>
>>> Cheers!
>>> /Dag Lindbo
>>>
>
>>I CC:ed this to dolfin-dev and ffc-dev, I hope you don't mind.
>>
>>  Johan
>
> The new output format from FFC will be UFC - Unified Form-assembly
> Code. This is nothing fancy, just an attempt at specifying a fixed
> interface for the code that FFC (and other compilers like SyFi)
> generates.
>
> We're working on the first draft of UFC that we will present in Delft
> next week. After a few rounds of comments and updates, this will be
> fixed as "UFC v 1.0". Then you can compile your form with any compiler
> (for example FFC and SyFi) and know that you can stick the generated code
> into
> any system that supports UFC 1.0 (like DOLFIN and PyCC).
>
> There's a preview available at
>
>     http://www.fenics.org/hg/ufc
>
> /Anders
> _______________________________________________
> FFC-dev mailing list
> FFC-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/ffc-dev
>