ffc team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Wed, Jul 09, 2008 at 11:28:36PM +0200, Martin Sandve Alnæs wrote:
> 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.
> >
> 
> 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.

I think it's ok if "optimize" means different things for different
form compilers. It would just mean to ask the form compiler to do its
best to optimize. Someone who knows more can set other more specific
options.

-- 
Anders

Attachment: signature.asc
Description: Digital signature