ffc team mailing list archive

[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

Attachment: signature.asc
Description: Digital signature