ffc team mailing list archive

["Martin Sandve Alnæs" <martinal@xxxxxxxxx>]

2008/7/9 Anders Logg <logg@xxxxxxxxx>:
> On Wed, Jul 09, 2008 at 11:10:59PM +0200, Martin Sandve Alnæs wrote:
>> 2008/7/9 Anders Logg <logg@xxxxxxxxx>:
>> > On Wed, Jul 09, 2008 at 04:17:00PM +0200, Johan Hake wrote:
>> >> On Wednesday 09 July 2008 16:05:50 Anders Logg wrote:
>> >> > On Wed, Jul 09, 2008 at 01:21:57PM +0200, Johan Hake wrote:
>> >> > > On Monday 07 July 2008 20:06:05 FFC wrote:
>> >> > > > One or more new changesets pushed to the primary ffc repository.
>> >> > > > A short summary of the last three changesets is included below.
>> >> > > >
>> >> > > > changeset:   1146:6aae9c7272f9d16f2b00d34bbff33b17dcd17004
>> >> > > > tag:         tip
>> >> > > > user:        Anders Logg <logg@xxxxxxxxx>
>> >> > > > date:        Mon Jul 07 20:06:30 2008 +0200
>> >> > > > files:       src/ffc/jit/jit.py
>> >> > > > description:
>> >> > > > Minor fixes
>> >> > >
>> >> > > Not sure what you thought about with the warning and error functions you
>> >> > > are calling in the jit functions, but they are not defined anywhere in
>> >> > > ffc.
>> >> > >
>> >> > > Johan
>> >> >
>> >> > Fixed. You can tell I'm on vacation.
>> >>
>> >> He, he, my starts in 30 min!
>> >>
>> >> To make the user aware of which parameters could be set one could add a
>> >> ffc.get_default_params(), returning a dict with the default parameters.
>> >
>> > They can be accessed by
>> >
>> >  from ffc.common.constants import FFC_OPTIONS
>> >
>> > but maybe get_default_params() or similar could be added.
>>
>> Using a function that returns a new dict is better than a fixed
>> global dict variable because:
>>
>> opt1 = FFC_OPTIONS
>> opt1["foo"] = 123
>> ... moving to another place in the code ...
>> opt2 = FFC_OPTIONS
>> opt2["bar"] = 456
>>
>> here opt2 "inherits" the changes done to FFC_OPTION via opt1.
>
> Good point.
>
>> If the dict is "flat" (no sub-dicts), "opt = default_options();
>> opt.update(user_options)"
>> should do the trick, and if the dict is hierarchial I can provide some code
>> that works the same way recursively if you want.
>>
>> >> This could be accessed fro mthe dolfin interface with e.g.
>> >> get_default_jit_params() or something like that.
>> >
>> > Perhaps, but maybe the point should be that DOLFIN does not know about
>> > which options the form compiler accepts. It just delivers the
>> > dictionary.
>>
>> That's the right way in my opinion. Otherwise, DOLFIN must be
>> kept up to date with changes in each form compiler all the time...
>
> Maybe we could agree on a few common options, like "optimize".
>
> If this option is set in DOLFIN, then DOLFIN will do some tricks
> to cache precompiled forms (in-memory) and FFC will ask instant to use
> -O2 when building modules.
>
> --
> Anders

We can probably agree on some options, but unless they mean exactly
the same, there's really no point. If "optimize" means passing -O2 to instant,
that's fine, but if it involves changes in the form compilation, it won't be the
same anyway.

--
Martin