ffc team mailing list archive

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

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.

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...

-- 
Martin