Subject: [FFC-dev] [HG FFC] Minor fixes

From: [email-masked] (FFC)
Date: Mon, 7 Jul 2008 20:06:05 +0200 (CEST)

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 <[email-masked]>
date:        Mon Jul 07 20:06:30 2008 +0200
files:       src/ffc/jit/jit.py
description:
Minor fixes

changeset:   1145:77e33e2dbc3ccd7abfe644d4e7a00a8bf7fd2155
user:        "Johan Hake <[email-masked]>"
date:        Thu Jul 03 21:04:05 2008 +0200
files:       src/ffc/jit/jit.py
description:
Change the interface to jit. It now takes a form as first argument and
and optional options argument at second. It now complies to the interface
used in pyDOLFIN's assemble function.

changeset:   1144:ca574155bd2d52db55beea7d04b0ca19894d3264
user:        Anders Logg <[email-masked]>
date:        Tue Jun 24 07:31:48 2008 +0200
files:       scripts/makedist
description:
Fix bug in makedist script

----------------------------------------------------------------------
For more details, visit http://www.fenics.org/hg/ffc

---

From: Johan Hake <[email-masked]>
Date: Wed, 9 Jul 2008 13:21:57 +0200

> files:       src/ffc/jit/jit.py

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

> _______________________________________________
> FFC-dev mailing list
> [email-masked]
> http://www.fenics.org/mailman/listinfo/ffc-dev

---

From: Anders Logg <[email-masked]>
Date: Wed, 9 Jul 2008 16:05:50 +0200

> calling in the jit functions, but they are not defined anywhere in ffc.

Fixed. You can tell I'm on vacation.

-- 
Anders

---

From: Johan Hake <[email-masked]>
Date: Wed, 9 Jul 2008 16:17:00 +0200

On Wednesday 09 July 2008 16:05:50 Anders Logg wrote:
> > 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
>

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.

This could be accessed fro mthe dolfin interface with e.g. 
get_default_jit_params() or something like that.

Johan

---

From: Anders Logg <[email-masked]>
Date: Wed, 9 Jul 2008 16:59:18 +0200

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

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

-- 
Anders

---

From: "Martin Sandve Alnæs" <[email-masked]>
Date: Wed, 9 Jul 2008 23:10:59 +0200

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

> which options the form compiler accepts. It just delivers the

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

---

From: Anders Logg <[email-masked]>
Date: Wed, 9 Jul 2008 23:20:51 +0200

> here opt2 "inherits" the changes done to FFC_OPTION via opt1.

Good point.

> 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

---

From: "Martin Sandve Alnæs" <[email-masked]>
Date: Wed, 9 Jul 2008 23:28:36 +0200

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

--
Martin

---

From: Anders Logg <[email-masked]>
Date: Thu, 10 Jul 2008 08:29:12 +0200

> that's fine, but if it involves changes in the form compilation, it won't be the

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