Re: [Ffc] FFC tests
On 2 February 2010 00:06, Anders Logg wrote: The unit tests are taking a very long time. Would it be possible to add some printing along the way so it doesn't look like it's stalling? I changed this, as did you, but I also added some additional info on which element is currently being tested out of how many. Some regression tests are still failing. Can these be ignored and should we then update the references? I just had a look at the values of BDM in the new and old FFC, they are the same on the reference element. I'll take one last look at the values in the regression to see what is going wrong. I think we're ready for a release, but you can work on DOLFIN until I have this one sorted out. Kristian -- Anders -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAktnXnsACgkQTuwUCDsYZdE3oACfce7Q5TNPSyNEgCvXnVdBKxLK YXMAnj9bozoigEM5+E0dGcmBXanUvS29 =+HVp -END PGP SIGNATURE- ___ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp
Re: [Ffc] FFC tests
On 2 February 2010 00:14, Anders Logg wrote: On Tue, Feb 02, 2010 at 12:06:35AM +0100, Anders Logg wrote: The unit tests are taking a very long time. Would it be possible to add some printing along the way so it doesn't look like it's stalling? Some regression tests are still failing. Can these be ignored and should we then update the references? I get this when I run the unit tests now: == FAIL: Test evaluate basis agains FIAT.FiniteElement.tabulate(). -- Traceback (most recent call last): File "/home/logg/work/src/fenics/ffc/ffc-main/test/unit/evaluate_basis/test.py", line 20, in testAgainsFiat self.assertEqual(error, 0, "Errors while testing evaluate_basis against FIAT, see fiat_errors.log for details") AssertionError: Errors while testing evaluate_basis against FIAT, see fiat_errors.log for details And things like this in error.log: --- > evaluate_basis() error: 3.999632e-09 (tol: 1e-14) evaluate_basis_derivatives(), order = 2 error: 1.42108547152e-14 (tol: 1e-14) evaluate_basis_derivatives(), order = 3 error: 7.1054273576e-14 (tol: 1e-14) --- --- > evaluate_basis() error: 4.976842e-09 (tol: 1e-14) evaluate_basis_derivatives(), order = 1 error: 4.0121914e-09 (tol: 1e-14) evaluate_basis_derivatives(), order = 2 error: 3.33344019054e-09 (tol: 1e-14) evaluate_basis_derivatives(), order = 3 error: 1.13686837722e-12 (tol: 1e-14) evaluate_basis_derivatives(), order = 4 error: 1.09139364213e-11 (tol: 1e-14) --- So the tolerance might need to be increased. Something like 1e-8 should be ok. Yes, I was working with two tolerances one of 1e-12 and one 1e-8, I've changed both to 1e-8 so all values are now green. I also get this: *** FFC: Sorry, finite element of type "Brezzi-Douglas-Fortin-Marini" are not supported by FIAT. *** FFC: To get more information about this error, rerun FFC with --debug. I didn't think BDFM was supported by the new FIAT. They're not, I had it in there to test the testing environment, I've commented them out now so everything should be in working order. Kristian -- Anders -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAktnYGQACgkQTuwUCDsYZdH3/ACePekgfTy4g+VQYa4tjbc9UH7c 7L0An34lwWFQm6m0twtIEqBYxJL7mWtt =/lrp -END PGP SIGNATURE- ___ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp
[Ffc] [Fwd: [Branch ~ffc-core/ffc/main] Rev 1369: Fixed Garth's optimised quadrature problem.]
There is still a problem. Now I get an DOLFIN error when I try to assemble my system. I will look at it some more later today. Garth Original Message Subject: [Branch ~ffc-core/ffc/main] Rev 1369: Fixed Garth's optimised quadrature problem. Date: Mon, 01 Feb 2010 20:30:28 - From: nore...@launchpad.net Reply-To: nore...@launchpad.net To: Garth Wells revno: 1369 committer: Marie E. Rognes branch nick: ffc timestamp: Mon 2010-02-01 21:27:04 +0100 message: Fixed Garth's optimised quadrature problem. modified: ffc/quadrature/fraction.py -- lp:ffc https://code.launchpad.net/~ffc-core/ffc/main Your team FFC Core Team is subscribed to branch lp:ffc. To unsubscribe from this branch go to https://code.launchpad.net/~ffc-core/ffc/main/+edit-subscription. === modified file 'ffc/quadrature/fraction.py' --- ffc/quadrature/fraction.py 2010-01-30 19:50:03 + +++ ffc/quadrature/fraction.py 2010-02-01 20:27:04 + @@ -5,7 +5,7 @@ __copyright__ = "Copyright (C) 2009-2010 Kristian B. Oelgaard" __license__ = "GNU GPL version 3 or any later version" -# Last changed: 2010-01-21 +# Last changed: 2010-02-01 # FFC modules. from ffc.log import error @@ -241,9 +241,14 @@ self = found*remain.""" # Reduce the numerator by the var type. -# Handle case where numerator is a sum. if self.num._prec == 3: -num_found, num_remain = self.num.reduce_vartype(var_type)[0] +foo = self.num.reduce_vartype(var_type) +if len(foo) == 1: +num_found, num_remain = self.num.reduce_vartype(var_type)[0] +else: +# meg: I have only a marginal idea of what I'm doing here! +return create_sum([create_fraction(create_product([num_found, num_remain]), self.denom) + for (num_found, num_remain) in foo]).expand().reduce_vartype(var_type) else: num_found, num_remain = self.num.reduce_vartype(var_type) @@ -259,7 +264,7 @@ denom_found, denom_remain = self.denom.reduce_vartype(var_type) # If we have a Sum in the denominator, all terms must be reduced by -# the same terms to make sense. +# the same terms to make sense else: remain = [] for m in self.denom.vrs: @@ -294,6 +299,7 @@ # TODO: Add more checks to avoid expansion. found = None # There is always a remainder. + remain = create_fraction(num_remain, denom_remain).expand() if num_found: @@ -306,6 +312,7 @@ found = create_fraction(create_float(1), denom_found) else: found = () + return (found, remain) # FFC quadrature modules. ___ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp
Re: [Ffc] FFC tests
On Tue, Feb 02, 2010 at 09:46:13AM +0100, Kristian Oelgaard wrote: > > > On 2 February 2010 00:14, Anders Logg wrote: > >On Tue, Feb 02, 2010 at 12:06:35AM +0100, Anders Logg wrote: > >>The unit tests are taking a very long time. Would it be possible to > >>add some printing along the way so it doesn't look like it's stalling? > >> > >>Some regression tests are still failing. Can these be ignored and > >>should we then update the references? > > > >I get this when I run the unit tests now: > > > >== > >FAIL: Test evaluate basis agains FIAT.FiniteElement.tabulate(). > >-- > >Traceback (most recent call last): > > File > > "/home/logg/work/src/fenics/ffc/ffc-main/test/unit/evaluate_basis/test.py", > > line 20, in testAgainsFiat > > self.assertEqual(error, 0, "Errors while testing evaluate_basis > > against FIAT, see fiat_errors.log for details") > >AssertionError: Errors while testing evaluate_basis against FIAT, see > >fiat_errors.log for details > > > >And things like this in error.log: > > > >--- > >> > > evaluate_basis() > > error: 3.999632e-09 (tol: 1e-14) > > evaluate_basis_derivatives(), order = 2 > > error: 1.42108547152e-14 (tol: 1e-14) > > evaluate_basis_derivatives(), order = 3 > > error: 7.1054273576e-14 (tol: 1e-14) > >--- > > > >--- > >> > > evaluate_basis() > > error: 4.976842e-09 (tol: 1e-14) > > evaluate_basis_derivatives(), order = 1 > > error: 4.0121914e-09 (tol: 1e-14) > > evaluate_basis_derivatives(), order = 2 > > error: 3.33344019054e-09 (tol: 1e-14) > > evaluate_basis_derivatives(), order = 3 > > error: 1.13686837722e-12 (tol: 1e-14) > > evaluate_basis_derivatives(), order = 4 > > error: 1.09139364213e-11 (tol: 1e-14) > >--- > > > >So the tolerance might need to be increased. Something like 1e-8 > >should be ok. > > Yes, I was working with two tolerances one of 1e-12 and one 1e-8, I've > changed both to 1e-8 so all values are now green. I didn't realize that until now when I saw the colors. I think that's a pretty good idea to have 2 different tolerances so I changed it back now. > >I also get this: > > > >*** FFC: Sorry, finite element of type "Brezzi-Douglas-Fortin-Marini" > >are not supported by FIAT. > >*** FFC: To get more information about this error, rerun FFC with > >--debug. > > > >I didn't think BDFM was supported by the new FIAT. > > They're not, I had it in there to test the testing environment, I've > commented them out now so everything should be in working order. ok. Seems to work fine now. Let's wait and see what the buildbots think. -- Anders signature.asc Description: Digital signature ___ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp
[Ffc] More optimisation bugs
I still have a problem with fractions + quadrature + optimisation. The
script I sent yesterday now works, but the below scripts leads to a FFC
error
File
"/usr/local/lib/python2.6/dist-packages/ffc/quadrature/sumobj.py",
line 495, in reduce_vartype
f, r = v.reduce_vartype(var_type)
ValueError: too many values to unpack
when using foo/2.0 rather than 0.5*foo.
Garth
from dolfin import *
mesh = UnitSquare(3, 3)
n = FacetNormal(mesh)
PV = VectorFunctionSpace(mesh, "CG", 1)
P0 = FunctionSpace(mesh, "Discontinuous Lagrange", 0)
mixed_space = MixedFunctionSpace([PV, P0])
# Function spaces and functions
r = TestFunction(P0)
U0 = Function(mixed_space)
u0, s0 = split(U0)
U0.vector()[:] = 1.0
F= 1.0/(s0**2 + 1.0)
# This breaks FFC
un = (dot(u0, n) + sqrt(dot(u0, n)*dot(u0, n)))/2.0
un_h = (dot(u0, n) - sqrt(dot(u0, n)*dot(u0, n)))/2.0
# This works
#un = 0.5*(dot(u0, n) + sqrt(dot(u0, n)*dot(u0, n)))
#un_h = 0.5*(dot(u0, n) - sqrt(dot(u0, n)*dot(u0, n)))
L = jump(r)*(un('+')*F('+') - un('-')*F('-'))*dS
param0 = {"representation": "quadrature", "optimize": False}
param1 = {"representation": "quadrature", "optimize": True}
print "Vec norm (no opt): ", assemble(L,
form_compiler_parameters=param0).norm("l2")
print "Vec norm (with opt): ", assemble(L,
form_compiler_parameters=param1).norm("l2")
___
Mailing list: https://launchpad.net/~ffc
Post to : ffc@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ffc
More help : https://help.launchpad.net/ListHelp
Re: [Ffc] FFC tests
On 2 February 2010 00:06, Anders Logg wrote: The unit tests are taking a very long time. Would it be possible to add some printing along the way so it doesn't look like it's stalling? Some regression tests are still failing. Can these be ignored and should we then update the references? How were these references generated? When I look at the code in references/MixedPoisson.h I see something which is definitely not code from ffc-0.7.1, and the code which is there definitely has a bug where only the first 2 reference derivatives are mapped. I think that we can just generate new references and conclude that everything is in working order now. Kristian -- Anders -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAktnXnsACgkQTuwUCDsYZdE3oACfce7Q5TNPSyNEgCvXnVdBKxLK YXMAnj9bozoigEM5+E0dGcmBXanUvS29 =+HVp -END PGP SIGNATURE- ___ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp
Re: [Ffc] More optimisation bugs
On 2 February 2010 10:15, Garth N. Wells wrote:
I still have a problem with fractions + quadrature + optimisation. The
script I sent yesterday now works, but the below scripts leads to a FFC
error
OK, I'll take a look now since my work on evaluate_basis is done.
Kristian
File
"/usr/local/lib/python2.6/dist-packages/ffc/quadrature/sumobj.py",
line 495, in reduce_vartype
f, r = v.reduce_vartype(var_type)
ValueError: too many values to unpack
when using foo/2.0 rather than 0.5*foo.
Garth
from dolfin import *
mesh = UnitSquare(3, 3)
n = FacetNormal(mesh)
PV = VectorFunctionSpace(mesh, "CG", 1)
P0 = FunctionSpace(mesh, "Discontinuous Lagrange", 0)
mixed_space = MixedFunctionSpace([PV, P0])
# Function spaces and functions
r = TestFunction(P0)
U0 = Function(mixed_space)
u0, s0 = split(U0)
U0.vector()[:] = 1.0
F = 1.0/(s0**2 + 1.0)
# This breaks FFC
un = (dot(u0, n) + sqrt(dot(u0, n)*dot(u0, n)))/2.0
un_h = (dot(u0, n) - sqrt(dot(u0, n)*dot(u0, n)))/2.0
# This works
#un = 0.5*(dot(u0, n) + sqrt(dot(u0, n)*dot(u0, n)))
#un_h = 0.5*(dot(u0, n) - sqrt(dot(u0, n)*dot(u0, n)))
L = jump(r)*(un('+')*F('+') - un('-')*F('-'))*dS
param0 = {"representation": "quadrature", "optimize": False}
param1 = {"representation": "quadrature", "optimize": True}
print "Vec norm (no opt): ", assemble(L,
form_compiler_parameters=param0).norm("l2")
print "Vec norm (with opt): ", assemble(L,
form_compiler_parameters=param1).norm("l2")
___
Mailing list: https://launchpad.net/~ffc
Post to : ffc@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ffc
More help : https://help.launchpad.net/ListHelp
signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~ffc
Post to : ffc@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ffc
More help : https://help.launchpad.net/ListHelp
Re: [Ffc] [Bug 511929] Re: Missing domain_type
I tried looking at this but I'm unsure how it should be
handled. Should a cell_integral class be generated or should a
surface_integral class be generated?
--
Anders
On Tue, Jan 26, 2010 at 10:21:51AM +0100, Medhi Nikbakht wrote:
> Hi Anders,
> This is the simplest form that I trying to compile.
>
> elem_cont = FiniteElement("CG", triangle, 1)
> elem_discont = ElementRestriction(elem_cont, dc) # or ec[dc]
>
> element = elem_cont + elem_discont
>
> (vc, vd) = TestFunctions(element)
> (uc, ud) = TrialFunctions(element)
>
> v = vc + vd
> u = uc + ud
>
>
> k = Constant(triangle)
> f = Coefficient(elem_cont)
>
> a = inner(grad(v), grad(u))*dx + k*vd*ud*dc
> L = v*f*dx
>
> What about adding this form as a test for surface integral?
>
> Mehdi
>
> On Tue, 2010-01-26 at 08:37 +, Anders Logg wrote:
> > The unit test should be a small piece of the form that you are
> > compiling and it should contain the surface integral.
> >
> > Put in in a UFL file.
> >
>
signature.asc
Description: Digital signature
___
Mailing list: https://launchpad.net/~ffc
Post to : ffc@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ffc
More help : https://help.launchpad.net/ListHelp
Re: [Ffc] FFC tests
On Tue, Feb 02, 2010 at 10:20:00AM +0100, Kristian Oelgaard wrote: > > > On 2 February 2010 00:06, Anders Logg wrote: > >The unit tests are taking a very long time. Would it be possible to > >add some printing along the way so it doesn't look like it's stalling? > > > >Some regression tests are still failing. Can these be ignored and > >should we then update the references? > > How were these references generated? When I look at the code in > references/MixedPoisson.h I see something which is definitely not code from > ffc-0.7.1, and the code which is there definitely has a bug where only the > first 2 reference derivatives are mapped. I think that we can just generate > new references and conclude that everything is in working order now. > > Kristian I think I regenerated it with the latest FFC at some point when we concluded things were working, so you can just generate new references if you think it looks ok. -- Anders signature.asc Description: Digital signature ___ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp
Re: [Ffc] More optimisation bugs
On Tue, Feb 02, 2010 at 10:25:14AM +0100, Kristian Oelgaard wrote:
>
>
> On 2 February 2010 10:15, Garth N. Wells wrote:
> >I still have a problem with fractions + quadrature + optimisation. The
> >script I sent yesterday now works, but the below scripts leads to a FFC
> >error
>
> OK, I'll take a look now since my work on evaluate_basis is done.
Good work btw! I'm happy I didn't have to touch it. :-)
--
Anders
> Kristian
>
> > File
> > "/usr/local/lib/python2.6/dist-packages/ffc/quadrature/sumobj.py",
> > line 495, in reduce_vartype
> > f, r = v.reduce_vartype(var_type)
> > ValueError: too many values to unpack
> >
> >when using foo/2.0 rather than 0.5*foo.
> >
> >Garth
> >
> >
> >
> >
> >from dolfin import *
> >
> >mesh = UnitSquare(3, 3)
> >n = FacetNormal(mesh)
> >
> >PV = VectorFunctionSpace(mesh, "CG", 1)
> >P0 = FunctionSpace(mesh, "Discontinuous Lagrange", 0)
> >mixed_space = MixedFunctionSpace([PV, P0])
> >
> ># Function spaces and functions
> >r = TestFunction(P0)
> >U0 = Function(mixed_space)
> >u0, s0 = split(U0)
> >
> >U0.vector()[:] = 1.0
> >
> >F = 1.0/(s0**2 + 1.0)
> >
> ># This breaks FFC
> >un = (dot(u0, n) + sqrt(dot(u0, n)*dot(u0, n)))/2.0
> >un_h = (dot(u0, n) - sqrt(dot(u0, n)*dot(u0, n)))/2.0
> >
> ># This works
> >#un = 0.5*(dot(u0, n) + sqrt(dot(u0, n)*dot(u0, n)))
> >#un_h = 0.5*(dot(u0, n) - sqrt(dot(u0, n)*dot(u0, n)))
> >
> >L = jump(r)*(un('+')*F('+') - un('-')*F('-'))*dS
> >
> >param0 = {"representation": "quadrature", "optimize": False}
> >param1 = {"representation": "quadrature", "optimize": True}
> >print "Vec norm (no opt): ", assemble(L,
> > form_compiler_parameters=param0).norm("l2")
> >print "Vec norm (with opt): ", assemble(L,
> > form_compiler_parameters=param1).norm("l2")
> >
> >___
> >Mailing list: https://launchpad.net/~ffc
> >Post to : ffc@lists.launchpad.net
> >Unsubscribe : https://launchpad.net/~ffc
> >More help : https://help.launchpad.net/ListHelp
> >
>
> ___
> Mailing list: https://launchpad.net/~ffc
> Post to : ffc@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ffc
> More help : https://help.launchpad.net/ListHelp
signature.asc
Description: Digital signature
___
Mailing list: https://launchpad.net/~ffc
Post to : ffc@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ffc
More help : https://help.launchpad.net/ListHelp
Re: [Ffc] [Bug 511929] Re: Missing domain_type
On Tue, 2010-02-02 at 10:30 +0100, Anders Logg wrote:
> I tried looking at this but I'm unsure how it should be
> handled. Should a cell_integral class be generated or should a
> surface_integral class be generated?
>
We handle terms related to surface integral inside a class derived from
ufc::cell_integral. I have started working on updating ffcpum module
which is built against standard ffc.
Mehdi
> --
> Anders
>
>
> On Tue, Jan 26, 2010 at 10:21:51AM +0100, Medhi Nikbakht wrote:
> > Hi Anders,
> > This is the simplest form that I trying to compile.
> >
> > elem_cont = FiniteElement("CG", triangle, 1)
> > elem_discont = ElementRestriction(elem_cont, dc) # or ec[dc]
> >
> > element = elem_cont + elem_discont
> >
> > (vc, vd) = TestFunctions(element)
> > (uc, ud) = TrialFunctions(element)
> >
> > v = vc + vd
> > u = uc + ud
> >
> >
> > k = Constant(triangle)
> > f = Coefficient(elem_cont)
> >
> > a = inner(grad(v), grad(u))*dx + k*vd*ud*dc
> > L = v*f*dx
> >
> > What about adding this form as a test for surface integral?
> >
> > Mehdi
> >
> > On Tue, 2010-01-26 at 08:37 +, Anders Logg wrote:
> > > The unit test should be a small piece of the form that you are
> > > compiling and it should contain the surface integral.
> > >
> > > Put in in a UFL file.
> > >
> >
___
Mailing list: https://launchpad.net/~ffc
Post to : ffc@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ffc
More help : https://help.launchpad.net/ListHelp
Re: [Ffc] [Bug 511929] Re: Missing domain_type
On Tue, Feb 02, 2010 at 10:42:23AM +0100, Mehdi Nikbakht wrote: > > > On Tue, 2010-02-02 at 10:30 +0100, Anders Logg wrote: > > I tried looking at this but I'm unsure how it should be > > handled. Should a cell_integral class be generated or should a > > surface_integral class be generated? > > > > We handle terms related to surface integral inside a class derived from > ufc::cell_integral. I have started working on updating ffcpum module > which is built against standard ffc. > > Mehdi So a surface integral should just result in a standard cell integral being generated? Then what is the point of having *dc? When the code has been generated, you won't be able to tell which cell integrals came from *dx and which came from *dc. -- Anders signature.asc Description: Digital signature ___ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp
[Ffc] ffc module scientific python
hi, i'm following up with you to keep close to the next release of fenics, i just built everything (no errors) but for ffc i get Exception: Unable to import the Python Scientific module required by FIAT. Consider installing the package python-scientific. can you tell me which package this is? obviously it's not scipy? best regards, patrick ___ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp
Re: [Ffc] ffc module scientific python
Patrick Riesen wrote: > hi, i'm following up with you to keep close to the next release of fenics, > > i just built everything (no errors) but for ffc i get > > > Exception: Unable to import the Python Scientific module required by FIAT. > Consider installing the package python-scientific. > > > can you tell me which package this is? obviously it's not scipy? > It's: http://dirac.cnrs-orleans.fr/plone/software/scientificpython/ If you use Debian/Ubuntu, the package is called 'python-scientific'. We should see if we can find a mainstream alternative, for example from SciPy. Garth > best regards, > > patrick > > ___ > Mailing list: https://launchpad.net/~ffc > Post to : ffc@lists.launchpad.net > Unsubscribe : https://launchpad.net/~ffc > More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp
Re: [Ffc] ffc module scientific python
Garth N. Wells wrote: Patrick Riesen wrote: hi, i'm following up with you to keep close to the next release of fenics, i just built everything (no errors) but for ffc i get Exception: Unable to import the Python Scientific module required by FIAT. Consider installing the package python-scientific. can you tell me which package this is? obviously it's not scipy? It's: http://dirac.cnrs-orleans.fr/plone/software/scientificpython/ Garth, thank you, I fetched 2.9 from http://sourcesup.cru.fr/frs/download.php/2372/ScientificPython-2.9.0.tar.gz and it was no problem for installing from source. I just compiled all FEniCS development modules and all went fine. Looking forward to the new releases, best regards, patrick If you use Debian/Ubuntu, the package is called 'python-scientific'. We should see if we can find a mainstream alternative, for example from SciPy. Garth best regards, patrick ___ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp
Re: [Ffc] JIT compile strangeness
More compile strangeness: Clean cache, error at first run, things running at second run: m...@localhost ~/local/src/fenics/adaptivity/demo $ instant-clean Instant cache is empty m...@localhost ~/local/src/fenics/adaptivity/demo $ python test.py Calling FFC just-in-time (JIT) compiler, this may take some time. Traceback (most recent call last): File "test.py", line 6, in L = assemble(v*dx) File "/home/meg/local/lib64/python2.6/site-packages/dolfin/fem/assemble.py", line 88, in assemble dolfin_form = Form(form, function_spaces, coefficients, form_compiler_parameters) File "/home/meg/local/lib64/python2.6/site-packages/dolfin/fem/form.py", line 39, in __init__ function_spaces) File "/home/meg/local/lib64/python2.6/site-packages/dolfin/fem/form.py", line 60, in _extract_function_spaces if not isinstance(func.function_space(), cpp.FunctionSpace): AttributeError: 'Argument' object has no attribute 'function_space' m...@localhost ~/local/src/fenics/adaptivity/demo $ python test.py L = Anyone else experience this? from dolfin import * mesh = UnitSquare(2,2) V_h = FunctionSpace(mesh, "DG", 1) v = TestFunction(V_h) L = assemble(v*dx) print "L = ", L ___ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp
Re: [Ffc] JIT compile strangeness
On Tue, Feb 02, 2010 at 12:29:55PM +0100, Marie Rognes wrote: > > More compile strangeness: Clean cache, error at first run, > things running at second run: > > m...@localhost ~/local/src/fenics/adaptivity/demo $ instant-clean > Instant cache is empty > m...@localhost ~/local/src/fenics/adaptivity/demo $ python test.py > Calling FFC just-in-time (JIT) compiler, this may take some time. > Traceback (most recent call last): > File "test.py", line 6, in >L = assemble(v*dx) > File "/home/meg/local/lib64/python2.6/site-packages/dolfin/fem/assemble.py", > line 88, in assemble >dolfin_form = Form(form, function_spaces, coefficients, > form_compiler_parameters) > File > "/home/meg/local/lib64/python2.6/site-packages/dolfin/fem/form.py", > line 39, in __init__ >function_spaces) > File > "/home/meg/local/lib64/python2.6/site-packages/dolfin/fem/form.py", > line 60, in _extract_function_spaces >if not isinstance(func.function_space(), cpp.FunctionSpace): > AttributeError: 'Argument' object has no attribute 'function_space' > m...@localhost ~/local/src/fenics/adaptivity/demo $ python test.py > L = > > Anyone else experience this? > > from dolfin import * > mesh = UnitSquare(2,2) > V_h = FunctionSpace(mesh, "DG", 1) > v = TestFunction(V_h) > L = assemble(v*dx) > print "L = ", L Same problem here. I'll fix it. -- Anders signature.asc Description: Digital signature ___ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp
Re: [Ffc] JIT compile strangeness
On 02/02/2010 11:29, Marie Rognes wrote: > > More compile strangeness: Clean cache, error at first run, > things running at second run: > > m...@localhost ~/local/src/fenics/adaptivity/demo $ instant-clean > Instant cache is empty > m...@localhost ~/local/src/fenics/adaptivity/demo $ python test.py > Calling FFC just-in-time (JIT) compiler, this may take some time. > Traceback (most recent call last): > File "test.py", line 6, in >L = assemble(v*dx) > File > "/home/meg/local/lib64/python2.6/site-packages/dolfin/fem/assemble.py", > line 88, in assemble >dolfin_form = Form(form, function_spaces, coefficients, > form_compiler_parameters) > File > "/home/meg/local/lib64/python2.6/site-packages/dolfin/fem/form.py", line > 39, in __init__ >function_spaces) > File > "/home/meg/local/lib64/python2.6/site-packages/dolfin/fem/form.py", line > 60, in _extract_function_spaces >if not isinstance(func.function_space(), cpp.FunctionSpace): > AttributeError: 'Argument' object has no attribute 'function_space' > m...@localhost ~/local/src/fenics/adaptivity/demo $ python test.py > L = > > Anyone else experience this? > > from dolfin import * > mesh = UnitSquare(2,2) > V_h = FunctionSpace(mesh, "DG", 1) > v = TestFunction(V_h) > L = assemble(v*dx) > print "L = ", L Me, me, me! :) Harish ___ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp
Re: [Ffc] [Bug 511929] Re: Missing domain_type
Mehdi Nikbakht wrote: > On Tue, 2010-02-02 at 12:01 +0100, Anders Logg wrote: >> On Tue, Feb 02, 2010 at 11:56:10AM +0100, Mehdi Nikbakht wrote: >>> On Tue, 2010-02-02 at 11:52 +0100, Anders Logg wrote: On Tue, Feb 02, 2010 at 11:24:46AM +0100, Mehdi Nikbakht wrote: > On Tue, 2010-02-02 at 11:18 +0100, Anders Logg wrote: >> On Tue, Feb 02, 2010 at 11:16:20AM +0100, Mehdi Nikbakht wrote: >>> On Tue, 2010-02-02 at 10:50 +0100, Anders Logg wrote: On Tue, Feb 02, 2010 at 10:42:23AM +0100, Mehdi Nikbakht wrote: > > On Tue, 2010-02-02 at 10:30 +0100, Anders Logg wrote: >> I tried looking at this but I'm unsure how it should be >> handled. Should a cell_integral class be generated or should a >> surface_integral class be generated? >> > We handle terms related to surface integral inside a class derived > from > ufc::cell_integral. I have started working on updating ffcpum module > which is built against standard ffc. > > Mehdi So a surface integral should just result in a standard cell integral being generated? Then what is the point of having *dc? When the code has been generated, you won't be able to tell which cell integrals came from *dx and which came from *dc. >>> Although we could have them in a separate class, we handle them inside >>> cell_integral class to have compatibility with ufc interface. >>> >>> Note that having *dc helps us to compute the corresponding terms by >>> using gauss points located on a surface. >>> >>> I don't see the point on being able to tell which cell integrals came >>> from *dx and which one from *dc, we add all of them to the global >>> element tensor. >> My point is that if FFC should treat *dc in exactly the same way as >> *dx, then you might as well just write *dx and we can remove the >> "support" for *dc in FFC. >> >> Or you could just write dc = dx in your form files. > No, it is not the case. They are handled differently inside ffc, we only > add them inside ufc::cell_integral in the code generation stage. ok, so the code example you sent me (Poisson.h) is code generated by FFC? Not a version you have modified. I didn't know that was supported. >>> No, this is generated by ffc-pum which is a module on the top of >>> standard ffc. To compile this file, one need just run, >>> > ffcpum -l dolfin Poisson.ufl >> Then I don't really understand what goes on. Should or should not FFC >> treat surface integrals in exactly the same way as standard integrals? > > No, we should not treat them as standard integrals. However, I am not > sure how it should be handled inside FFC. > > For now, it is better to throw an error for this case in standard FFC. > Garth, what do you think? > It should throw an error if it's not supported by FFC. Garth > > Mehdi > >> -- >> Anders >> >> >> > ___ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp
Re: [Ffc] [Bug 511929] Re: Missing domain_type
On Tue, Feb 02, 2010 at 12:11:33PM +, Garth N. Wells wrote: > > > Mehdi Nikbakht wrote: > > On Tue, 2010-02-02 at 12:01 +0100, Anders Logg wrote: > >> On Tue, Feb 02, 2010 at 11:56:10AM +0100, Mehdi Nikbakht wrote: > >>> On Tue, 2010-02-02 at 11:52 +0100, Anders Logg wrote: > On Tue, Feb 02, 2010 at 11:24:46AM +0100, Mehdi Nikbakht wrote: > > On Tue, 2010-02-02 at 11:18 +0100, Anders Logg wrote: > >> On Tue, Feb 02, 2010 at 11:16:20AM +0100, Mehdi Nikbakht wrote: > >>> On Tue, 2010-02-02 at 10:50 +0100, Anders Logg wrote: > On Tue, Feb 02, 2010 at 10:42:23AM +0100, Mehdi Nikbakht wrote: > > > > On Tue, 2010-02-02 at 10:30 +0100, Anders Logg wrote: > >> I tried looking at this but I'm unsure how it should be > >> handled. Should a cell_integral class be generated or should a > >> surface_integral class be generated? > >> > > We handle terms related to surface integral inside a class derived > > from > > ufc::cell_integral. I have started working on updating ffcpum module > > which is built against standard ffc. > > > > Mehdi > So a surface integral should just result in a standard cell integral > being generated? Then what is the point of having *dc? When the code > has been generated, you won't be able to tell which cell integrals > came from *dx and which came from *dc. > >>> Although we could have them in a separate class, we handle them inside > >>> cell_integral class to have compatibility with ufc interface. > >>> > >>> Note that having *dc helps us to compute the corresponding terms by > >>> using gauss points located on a surface. > >>> > >>> I don't see the point on being able to tell which cell integrals came > >>> from *dx and which one from *dc, we add all of them to the global > >>> element tensor. > >> My point is that if FFC should treat *dc in exactly the same way as > >> *dx, then you might as well just write *dx and we can remove the > >> "support" for *dc in FFC. > >> > >> Or you could just write dc = dx in your form files. > > No, it is not the case. They are handled differently inside ffc, we only > > add them inside ufc::cell_integral in the code generation stage. > ok, so the code example you sent me (Poisson.h) is code generated by > FFC? Not a version you have modified. I didn't know that was > supported. > >>> No, this is generated by ffc-pum which is a module on the top of > >>> standard ffc. To compile this file, one need just run, > >>> > > ffcpum -l dolfin Poisson.ufl > >> Then I don't really understand what goes on. Should or should not FFC > >> treat surface integrals in exactly the same way as standard integrals? > > > > No, we should not treat them as standard integrals. However, I am not > > sure how it should be handled inside FFC. > > > > For now, it is better to throw an error for this case in standard FFC. > > Garth, what do you think? > > > > It should throw an error if it's not supported by FFC. > > Garth ok, that's easy to fix. In fact, it has been working for a long time. :-) -- Anders signature.asc Description: Digital signature ___ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp
Re: [Ffc] JIT compile strangeness
On Tue, Feb 02, 2010 at 12:08:51PM +, Harish Narayanan wrote: > On 02/02/2010 11:29, Marie Rognes wrote: > > > > More compile strangeness: Clean cache, error at first run, > > things running at second run: > > > > m...@localhost ~/local/src/fenics/adaptivity/demo $ instant-clean > > Instant cache is empty > > m...@localhost ~/local/src/fenics/adaptivity/demo $ python test.py > > Calling FFC just-in-time (JIT) compiler, this may take some time. > > Traceback (most recent call last): > > File "test.py", line 6, in > >L = assemble(v*dx) > > File > > "/home/meg/local/lib64/python2.6/site-packages/dolfin/fem/assemble.py", > > line 88, in assemble > >dolfin_form = Form(form, function_spaces, coefficients, > > form_compiler_parameters) > > File > > "/home/meg/local/lib64/python2.6/site-packages/dolfin/fem/form.py", line > > 39, in __init__ > >function_spaces) > > File > > "/home/meg/local/lib64/python2.6/site-packages/dolfin/fem/form.py", line > > 60, in _extract_function_spaces > >if not isinstance(func.function_space(), cpp.FunctionSpace): > > AttributeError: 'Argument' object has no attribute 'function_space' > > m...@localhost ~/local/src/fenics/adaptivity/demo $ python test.py > > L = > > > > Anyone else experience this? > > > > from dolfin import * > > mesh = UnitSquare(2,2) > > V_h = FunctionSpace(mesh, "DG", 1) > > v = TestFunction(V_h) > > L = assemble(v*dx) > > print "L = ", L > > Me, me, me! :) > > Harish > > ___ > Mailing list: https://launchpad.net/~ffc > Post to : ffc@lists.launchpad.net > Unsubscribe : https://launchpad.net/~ffc > More help : https://help.launchpad.net/ListHelp This is fixed now. It was an intricate caching problem relating to reuse of the dummy form v*dx that FFC creates when JIT compiling elements (for use in DOLFIN FunctionSpace). I fixed it by making sure FormData is not cached when compiling elements but a proper solution (removal of the FFC dummy form) should be implemented instead. I've added a FIXME in jit.py. -- Anders signature.asc Description: Digital signature ___ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp
Re: [Ffc] JIT compile strangeness
Anders Logg wrote: On Tue, Feb 02, 2010 at 12:08:51PM +, Harish Narayanan wrote: On 02/02/2010 11:29, Marie Rognes wrote: More compile strangeness: Clean cache, error at first run, things running at second run: m...@localhost ~/local/src/fenics/adaptivity/demo $ instant-clean Instant cache is empty m...@localhost ~/local/src/fenics/adaptivity/demo $ python test.py Calling FFC just-in-time (JIT) compiler, this may take some time. Traceback (most recent call last): File "test.py", line 6, in L = assemble(v*dx) File "/home/meg/local/lib64/python2.6/site-packages/dolfin/fem/assemble.py", line 88, in assemble dolfin_form = Form(form, function_spaces, coefficients, form_compiler_parameters) File "/home/meg/local/lib64/python2.6/site-packages/dolfin/fem/form.py", line 39, in __init__ function_spaces) File "/home/meg/local/lib64/python2.6/site-packages/dolfin/fem/form.py", line 60, in _extract_function_spaces if not isinstance(func.function_space(), cpp.FunctionSpace): AttributeError: 'Argument' object has no attribute 'function_space' m...@localhost ~/local/src/fenics/adaptivity/demo $ python test.py L = Anyone else experience this? from dolfin import * mesh = UnitSquare(2,2) V_h = FunctionSpace(mesh, "DG", 1) v = TestFunction(V_h) L = assemble(v*dx) print "L = ", L Me, me, me! :) Harish ___ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp This is fixed now. Hurray! -- Marie It was an intricate caching problem relating to reuse of the dummy form v*dx that FFC creates when JIT compiling elements (for use in DOLFIN FunctionSpace). I fixed it by making sure FormData is not cached when compiling elements but a proper solution (removal of the FFC dummy form) should be implemented instead. I've added a FIXME in jit.py. -- Anders ___ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp
Re: [Ffc] JIT compile strangeness
On 02/02/2010 12:54, Marie Rognes wrote: > Anders Logg wrote: >> On Tue, Feb 02, 2010 at 12:08:51PM +, Harish Narayanan wrote: >> >>> On 02/02/2010 11:29, Marie Rognes wrote: >>> More compile strangeness: Clean cache, error at first run, things running at second run: m...@localhost ~/local/src/fenics/adaptivity/demo $ instant-clean Instant cache is empty m...@localhost ~/local/src/fenics/adaptivity/demo $ python test.py Calling FFC just-in-time (JIT) compiler, this may take some time. Traceback (most recent call last): File "test.py", line 6, in L = assemble(v*dx) File "/home/meg/local/lib64/python2.6/site-packages/dolfin/fem/assemble.py", line 88, in assemble dolfin_form = Form(form, function_spaces, coefficients, form_compiler_parameters) File "/home/meg/local/lib64/python2.6/site-packages/dolfin/fem/form.py", line 39, in __init__ function_spaces) File "/home/meg/local/lib64/python2.6/site-packages/dolfin/fem/form.py", line 60, in _extract_function_spaces if not isinstance(func.function_space(), cpp.FunctionSpace): AttributeError: 'Argument' object has no attribute 'function_space' m...@localhost ~/local/src/fenics/adaptivity/demo $ python test.py L = Anyone else experience this? from dolfin import * mesh = UnitSquare(2,2) V_h = FunctionSpace(mesh, "DG", 1) v = TestFunction(V_h) L = assemble(v*dx) print "L = ", L >>> Me, me, me! :) >>> >>> Harish >>> >>> ___ >>> Mailing list: https://launchpad.net/~ffc >>> Post to : ffc@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~ffc >>> More help : https://help.launchpad.net/ListHelp >>> >> >> This is fixed now. > > Hurray! !! ___ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp
Re: [Ffc] More optimisation bugs
On 2 February 2010 10:15, Garth N. Wells wrote:
> I still have a problem with fractions + quadrature + optimisation. The
> script I sent yesterday now works, but the below scripts leads to a FFC
> error
>
> File
> "/usr/local/lib/python2.6/dist-packages/ffc/quadrature/sumobj.py",
> line 495, in reduce_vartype
> f, r = v.reduce_vartype(var_type)
> ValueError: too many values to unpack
>
> when using foo/2.0 rather than 0.5*foo.
Fixed, and the norms are even equal.
I think we should release and quickly.
Kristian
> Garth
>
>
>
>
> from dolfin import *
>
> mesh = UnitSquare(3, 3)
> n = FacetNormal(mesh)
>
> PV = VectorFunctionSpace(mesh, "CG", 1)
> P0 = FunctionSpace(mesh, "Discontinuous Lagrange", 0)
> mixed_space = MixedFunctionSpace([PV, P0])
>
> # Function spaces and functions
> r = TestFunction(P0)
> U0 = Function(mixed_space)
> u0, s0 = split(U0)
>
> U0.vector()[:] = 1.0
>
> F = 1.0/(s0**2 + 1.0)
>
> # This breaks FFC
> un = (dot(u0, n) + sqrt(dot(u0, n)*dot(u0, n)))/2.0
> un_h = (dot(u0, n) - sqrt(dot(u0, n)*dot(u0, n)))/2.0
>
> # This works
> #un = 0.5*(dot(u0, n) + sqrt(dot(u0, n)*dot(u0, n)))
> #un_h = 0.5*(dot(u0, n) - sqrt(dot(u0, n)*dot(u0, n)))
>
> L = jump(r)*(un('+')*F('+') - un('-')*F('-'))*dS
>
> param0 = {"representation": "quadrature", "optimize": False}
> param1 = {"representation": "quadrature", "optimize": True}
> print "Vec norm (no opt): ", assemble(L,
> form_compiler_parameters=param0).norm("l2")
> print "Vec norm (with opt): ", assemble(L,
> form_compiler_parameters=param1).norm("l2")
>
> ___
> Mailing list: https://launchpad.net/~ffc
> Post to : ffc@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ffc
> More help : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~ffc
Post to : ffc@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ffc
More help : https://help.launchpad.net/ListHelp
Re: [Ffc] More optimisation bugs
On Tue, Feb 02, 2010 at 05:28:11PM +0100, Kristian Oelgaard wrote: > On 2 February 2010 10:15, Garth N. Wells wrote: > > I still have a problem with fractions + quadrature + optimisation. The > > script I sent yesterday now works, but the below scripts leads to a FFC > > error > > > > File > > "/usr/local/lib/python2.6/dist-packages/ffc/quadrature/sumobj.py", > > line 495, in reduce_vartype > > f, r = v.reduce_vartype(var_type) > > ValueError: too many values to unpack > > > > when using foo/2.0 rather than 0.5*foo. > > Fixed, and the norms are even equal. > I think we should release and quickly. > > Kristian ok, one release coming up. :-) -- Anders signature.asc Description: Digital signature ___ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp
[Ffc] buildbot failure in FEniCS Buildbot on ffc-hardy-i386
The Buildbot has detected a new failure of ffc-hardy-i386 on FEniCS Buildbot. Full details are available at: http://fenics.org:8080/builders/ffc-hardy-i386/builds/155 Buildbot URL: http://fenics.org:8080/ Buildslave for this Build: hardy-i386 Build Reason: Build Source Stamp: HEAD Blamelist: Anders Logg BUILD FAILED: failed ffc check sincerely, -The Buildbot ___ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp
Re: [Ffc] [Branch ~ffc-core/ffc/main] Rev 1387: Disable element library testing in regression tests to get around error
On 2 February 2010 18:27, wrote:
>
> revno: 1387
> committer: Anders Logg
> branch nick: ffc-main
> timestamp: Tue 2010-02-02 18:24:56 +0100
> message:
> Disable element library testing in regression tests to get around error
> on buildbot (most likely a roundoff error, will fix later).
> modified:
> test/regression/test.py
Yes, I get the errors too when I run the tests. Looks like 1e-8 is too strict.
9.4699181e-08
9.4699182e-08
Kristian
>
> --
> lp:ffc
> https://code.launchpad.net/~ffc-core/ffc/main
>
> Your team FFC Core Team is subscribed to branch lp:ffc.
> To unsubscribe from this branch go to
> https://code.launchpad.net/~ffc-core/ffc/main/+edit-subscription.
>
> === modified file 'test/regression/test.py'
> --- test/regression/test.py 2010-02-02 16:57:18 +
> +++ test/regression/test.py 2010-02-02 17:24:56 +
> @@ -62,9 +62,9 @@
>
> # Generate form files for elements
> from elements import elements
> - info("Generating form files for extra elements (%d elements)" %
> len(elements))
> - for (i, element) in enumerate(elements):
> - open("X_Element%d.ufl" % i, "w").write("element = %s" % element)
> + #info("Generating form files for extra elements (%d elements)" %
> len(elements))
> + #for (i, element) in enumerate(elements):
> + # open("X_Element%d.ufl" % i, "w").write("element = %s" % element)
>
> end()
>
>
>
>
___
Mailing list: https://launchpad.net/~ffc
Post to : ffc@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ffc
More help : https://help.launchpad.net/ListHelp
Re: [Ffc] More optimisation bugs
On 02/02/2010 16:28, Kristian Oelgaard wrote: > On 2 February 2010 10:15, Garth N. Wells wrote: >> I still have a problem with fractions + quadrature + optimisation. The >> script I sent yesterday now works, but the below scripts leads to a FFC >> error >> >>File >> "/usr/local/lib/python2.6/dist-packages/ffc/quadrature/sumobj.py", >> line 495, in reduce_vartype >>f, r = v.reduce_vartype(var_type) >> ValueError: too many values to unpack >> >> when using foo/2.0 rather than 0.5*foo. > > Fixed, and the norms are even equal. > I think we should release and quickly. Sounds like someone's release enthusiasm has rubbed off on you. :) Harish ___ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp
Re: [Ffc] [Branch ~ffc-core/ffc/main] Rev 1387: Disable element library testing in regression tests to get around error
On Tue, Feb 02, 2010 at 06:42:57PM +0100, Kristian Oelgaard wrote:
> On 2 February 2010 18:27, wrote:
> >
> > revno: 1387
> > committer: Anders Logg
> > branch nick: ffc-main
> > timestamp: Tue 2010-02-02 18:24:56 +0100
> > message:
> > Disable element library testing in regression tests to get around error
> > on buildbot (most likely a roundoff error, will fix later).
> > modified:
> > test/regression/test.py
>
> Yes, I get the errors too when I run the tests. Looks like 1e-8 is too strict.
>
> 9.4699181e-08
> 9.4699182e-08
>
> Kristian
ok, I'll try 1e-7. It's strange that it should be so sensitive and
vary even between different Ubuntu versions.
--
Anders
> >
> >
> > Your team FFC Core Team is subscribed to branch lp:ffc.
> > To unsubscribe from this branch go to
> > https://code.launchpad.net/~ffc-core/ffc/main/+edit-subscription.
> >
> > === modified file 'test/regression/test.py'
> > --- test/regression/test.py 2010-02-02 16:57:18 +
> > +++ test/regression/test.py 2010-02-02 17:24:56 +
> > @@ -62,9 +62,9 @@
> >
> > # Generate form files for elements
> > from elements import elements
> > - info("Generating form files for extra elements (%d elements)" %
> > len(elements))
> > - for (i, element) in enumerate(elements):
> > - open("X_Element%d.ufl" % i, "w").write("element = %s" % element)
> > + #info("Generating form files for extra elements (%d elements)" %
> > len(elements))
> > + #for (i, element) in enumerate(elements):
> > + # open("X_Element%d.ufl" % i, "w").write("element = %s" % element)
> >
> > end()
> >
> >
> >
> >
>
> ___
> Mailing list: https://launchpad.net/~ffc
> Post to : ffc@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ffc
> More help : https://help.launchpad.net/ListHelp
signature.asc
Description: Digital signature
___
Mailing list: https://launchpad.net/~ffc
Post to : ffc@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ffc
More help : https://help.launchpad.net/ListHelp
[Ffc] Problems with roundoff errors
The build bot is giving me a hard time. I'll make a release now and then sort out the precision thing with Johannes tomorrow. -- Anders signature.asc Description: Digital signature ___ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp
[Ffc] Version 0.9.0 of ffc released
0.9.0 - Updates for FIAT 0.9.0 - Updates for UFC 1.4.0 (now supporting the full interface) - Automatic selection of representation - Change quadrature_order --> quadrature_degree - Split compile() --> compile_form(), compile_element() - Major cleanup and reorganization of code (flatter directories) - Updates for changes in UFL: Argument, Coefficient, FormData 0.7.1 - Handle setting quadrature degree when it is set to None in UFL form - Added demo: HyperElasticity.ufl 0.7.0 - Move contents of TODO to: https://blueprints.launchpad.net/ffc - Support for restriction of finite elements to only consider facet dofs - Use quadrature_order from metadata when integrating terms using tensor representation - Use loop to reset the entries of the local element tensor - Added new symbolic classes for quadrature optimisation (speed up compilation) - Added demos: Biharmonic.ufl, div(grad(v)) term; ReactionDiffusion.ufl, tuple notation; MetaData.ufl, how to attach metadata to the measure; ElementRestriction.ufl, restriction of elements to facets - Tabulate the coordinates of the integration points in the tabulate_tensor() function - Change command line option '-f split_implementation' -> '-f split' - Renaming of files and restructuring of the compiler directory - Added option -q rule (--quadrature-rule rule) to specify which rule to use for integration of a given integral. (Can also bet set through the metadata through "quadrature_rule"). No rules have yet been implemented, so default is the FIAT rule. - Remove support for old style .form files/format 0.6.2 [2009-04-07] - Experimental support for UFL, supporting both .form and .ufl - Moved configuration and construction of python extension module to ufc_module 0.6.1 [2009-02-18] - Initial work on UFL transition - Minor bug fixes - The version of ufc and swig is included in the form signature - Better system configuration for JIT compiled forms - The JIT compiled python extension module use shared_ptr for all classes 0.6.0 [2009-01-05] - Update DOLFIN output format (-l dolfin) for DOLFIN 0.9.0 - Cross-platform fixes for test scripts - Minor bug fix for quadrature code generation (forms affected by this bug would not be able to compile - Fix bug with output of *.py. - Permit dot product bewteen rectangular matrices (Frobenius norm) 0.5.1 [2008-10-20] - New operator skew() - Allow JIT compilation of elements and dof maps - Rewrite JIT compiler to rely on Instant for caching - Display flop count for evaluating the element tensor during compilation - Add arguments language and representation to options dictionary - Fix installation on Windows - Add option -f split_implementation for separate .h and .cpp files 0.5.0 [2008-06-23] - Remove default restriction +/- for Constant - Make JIT optimization (-O0 / -O2) optional - Add in-memory cache to speed up JIT compiler for repeated assembly - Allow subdomain integrals without needing full range of integrals - Allow simple subdomain integral specification dx(0), dx(1), ds(0) etc 0.4.5 [2008-04-30] - Optimizations in generated quadrature code - Change formatting of floats from %g to %e, fixes problem with too long integers - Bug fix for order of values in interpolate_vertex_values, now according to UFC - Speed up JIT compiler - Add index ranges to form printing - Throw runtime error in functions not generated - Update DOLFIN format for new location of include files 0.4.4 [2008-02-18] - RT, BDM, BDFM and Nedelec now working in 2D and 3D - New element type QuadratureElement - Add support for 1D elements - Add experimental support for new Darcy-Stokes element - Use FIAT transformed spaces instead of mapping in FFC - Updates for UFC 1.1 - Implement caching of forms/modules in ~/.ffc/cache for JIT compiler - Add script ffc-clean - New operators lhs() and rhs() - Bug fixes in simplify - Bug fixes for Nedelec and BDFM - Fix bug in mult() - Fix bug with restrictions on exterior facet integrals - Fix bug in grad() for vectors - Add divergence operator for matrices 0.4.3 [2007-10-23] - Require FIAT to use UFC reference cells - Fix bug in form simplification - Rename abs --> modulus to avoid conflict with builtin abs - Fix bug in operators invert, abs, sqrt - Fix bug in integral tabulation - Add BDFM and Nedelec elements (nonworking) - Fix bug in JIT compiler 0.4.2 [2007-08-31] - Change license from GPL v2 to GPL v3 or later - Add JIT (just-in-time) compiler - Fix bug for constants on interior facets 0.4.1 [2007-06-22] - Fix bug in simplification of forms - Optimize removal of unused terms in code formattting 0.4.0 [2007-06-20] - Move to UFC interface for code generation - Major rewrite, restructure, cleanup - Add support for Brezzi-Douglas-Marini (BDM) elements - Add support for Raviart-Thomas (RT) elements - Add support for Discontinuous Galerkin (DG) methods - Operators jump() and avg() - Add quadrat
[Ffc] buildbot failure in FEniCS Buildbot on ffc-linux64-exp
The Buildbot has detected a new failure of ffc-linux64-exp on FEniCS Buildbot. Full details are available at: http://fenics.org:8080/builders/ffc-linux64-exp/builds/162 Buildbot URL: http://fenics.org:8080/ Buildslave for this Build: linux64-exp Build Reason: Build Source Stamp: HEAD Blamelist: Anders Logg BUILD FAILED: failed ffc check sincerely, -The Buildbot ___ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp
[Ffc] strip_variables
Should the UFL function 'strip_variables' be called on a UFL form from inside FFC? I suspect that this may fix the bug https://bugs.launchpad.net/ufl/+bug/512425 Garth ___ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp
[Ffc] buildbot failure in FEniCS Buildbot on ffc-jaunty-amd64
The Buildbot has detected a new failure of ffc-jaunty-amd64 on FEniCS Buildbot. Full details are available at: http://fenics.org:8080/builders/ffc-jaunty-amd64/builds/163 Buildbot URL: http://fenics.org:8080/ Buildslave for this Build: jaunty-amd64 Build Reason: Build Source Stamp: HEAD Blamelist: Anders Logg BUILD FAILED: failed ffc check sincerely, -The Buildbot ___ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp
Re: [Ffc] JIT compile strangeness
Anders Logg wrote:
> On Tue, Feb 02, 2010 at 12:08:51PM +, Harish Narayanan wrote:
>> On 02/02/2010 11:29, Marie Rognes wrote:
>>> More compile strangeness: Clean cache, error at first run,
>>> things running at second run:
>>>
>>> m...@localhost ~/local/src/fenics/adaptivity/demo $ instant-clean
>>> Instant cache is empty
>>> m...@localhost ~/local/src/fenics/adaptivity/demo $ python test.py
>>> Calling FFC just-in-time (JIT) compiler, this may take some time.
>>> Traceback (most recent call last):
>>> File "test.py", line 6, in
>>>L = assemble(v*dx)
>>> File
>>> "/home/meg/local/lib64/python2.6/site-packages/dolfin/fem/assemble.py",
>>> line 88, in assemble
>>>dolfin_form = Form(form, function_spaces, coefficients,
>>> form_compiler_parameters)
>>> File
>>> "/home/meg/local/lib64/python2.6/site-packages/dolfin/fem/form.py", line
>>> 39, in __init__
>>>function_spaces)
>>> File
>>> "/home/meg/local/lib64/python2.6/site-packages/dolfin/fem/form.py", line
>>> 60, in _extract_function_spaces
>>>if not isinstance(func.function_space(), cpp.FunctionSpace):
>>> AttributeError: 'Argument' object has no attribute 'function_space'
>>> m...@localhost ~/local/src/fenics/adaptivity/demo $ python test.py
>>> L =
>>>
>>> Anyone else experience this?
>>>
>>> from dolfin import *
>>> mesh = UnitSquare(2,2)
>>> V_h = FunctionSpace(mesh, "DG", 1)
>>> v = TestFunction(V_h)
>>> L = assemble(v*dx)
>>> print "L = ", L
>> Me, me, me! :)
>>
>> Harish
>>
>> ___
>> Mailing list: https://launchpad.net/~ffc
>> Post to : ffc@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~ffc
>> More help : https://help.launchpad.net/ListHelp
>
> This is fixed now. It was an intricate caching problem relating to
> reuse of the dummy form v*dx that FFC creates when JIT compiling
> elements (for use in DOLFIN FunctionSpace).
>
> I fixed it by making sure FormData is not cached when compiling
> elements but a proper solution (removal of the FFC dummy form) should
> be implemented instead. I've added a FIXME in jit.py.
>
This works for Marie's form, but the it's broken for the below form.
Garth
from dolfin import *
from numpy import random
mesh = UnitSquare(24, 24)
n = FacetNormal(mesh)
V = FunctionSpace(mesh, "DG", 1)
v = TestFunction(V)
u = Function(V)
# Fill vector with some numbers
random.seed(2)
u.vector().set_local( random.rand(u.vector().size()) )
flux = variable(grad(u))
L2 = dot(jump(v, n), avg(flux))*dS
print "Norm case 2 (using variable): ", assemble(L2).norm("l2")
> --
> Anders
>
>
>
>
> ___
> Mailing list: https://launchpad.net/~ffc
> Post to : ffc@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ffc
> More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~ffc
Post to : ffc@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ffc
More help : https://help.launchpad.net/ListHelp
Re: [Ffc] strip_variables
On Tue, Feb 02, 2010 at 10:26:13PM +, Garth N. Wells wrote: > Should the UFL function 'strip_variables' be called on a UFL form from > inside FFC? I suspect that this may fix the bug > > https://bugs.launchpad.net/ufl/+bug/512425 > > Garth Not sure if that's the right place to do it. I'll have a look tomorrow. -- Anders signature.asc Description: Digital signature ___ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp
Re: [Ffc] strip_variables
On Tue, Feb 02, 2010 at 11:45:41PM +0100, Anders Logg wrote: > On Tue, Feb 02, 2010 at 10:26:13PM +, Garth N. Wells wrote: > > Should the UFL function 'strip_variables' be called on a UFL form from > > inside FFC? I suspect that this may fix the bug > > > > https://bugs.launchpad.net/ufl/+bug/512425 > > > > Garth > > Not sure if that's the right place to do it. I'll have a look > tomorrow. This broke the HyperElasticity demo: *** FFC: Expecting a Variable in VariableDerivative. But you may be onto something. For the tensor representation, this should happen before or after the call to purge_list_tensors in monomialextaction.py. Don't know where it should go in the quadrature representation. -- Anders signature.asc Description: Digital signature ___ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp
Re: [Ffc] strip_variables
Anders Logg wrote: > On Tue, Feb 02, 2010 at 11:45:41PM +0100, Anders Logg wrote: >> On Tue, Feb 02, 2010 at 10:26:13PM +, Garth N. Wells wrote: >>> Should the UFL function 'strip_variables' be called on a UFL form from >>> inside FFC? I suspect that this may fix the bug >>> >>> https://bugs.launchpad.net/ufl/+bug/512425 >>> >>> Garth >> Not sure if that's the right place to do it. I'll have a look >> tomorrow. > > This broke the HyperElasticity demo: > > *** FFC: Expecting a Variable in VariableDerivative. > > But you may be onto something. For the tensor representation, this > should happen before or after the call to purge_list_tensors in > monomialextaction.py. Don't know where it should go in the quadrature > representation. > OK. It fixes https://bugs.launchpad.net/ufl/+bug/512425 and the DOLFIN hyperelastic demo runs, but it seems to break caching. Garth > -- > Anders ___ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp
Re: [Ffc] strip_variables
Anders Logg wrote:
> On Tue, Feb 02, 2010 at 11:45:41PM +0100, Anders Logg wrote:
>> On Tue, Feb 02, 2010 at 10:26:13PM +, Garth N. Wells wrote:
>>> Should the UFL function 'strip_variables' be called on a UFL form from
>>> inside FFC? I suspect that this may fix the bug
>>>
>>> https://bugs.launchpad.net/ufl/+bug/512425
>>>
>>> Garth
>> Not sure if that's the right place to do it. I'll have a look
>> tomorrow.
>
> This broke the HyperElasticity demo:
>
> *** FFC: Expecting a Variable in VariableDerivative.
>
> But you may be onto something. For the tensor representation, this
> should happen before or after the call to purge_list_tensors in
> monomialextaction.py. Don't know where it should go in the quadrature
> representation.
>
I've moved the function call for the quadrature representation. For the
tensor rep, I get the below error message. Does it not handle facets
normals?
Garth
File
"/usr/local/lib/python2.6/dist-packages/ffc/tensor/monomialextraction.py",
line 274, in terminal
raise MonomialException, ("No handler defined for terminal %s." %
o._uflclass.__name__)
ffc.tensor.monomialextraction.MonomialException: No handler defined for
terminal FacetNormal.
> --
> Anders
___
Mailing list: https://launchpad.net/~ffc
Post to : ffc@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ffc
More help : https://help.launchpad.net/ListHelp
Re: [Ffc] [Branch ~dolfin-core/dolfin/main] Rev 4434: Set parameter to use tensor rep for DG Poisson demo. It's broken.
On Tue, Feb 02, 2010 at 11:20:32PM -, nore...@launchpad.net wrote: > > revno: 4434 > committer: Garth N. Wells > branch nick: dolfin-all > timestamp: Tue 2010-02-02 23:16:44 + > message: > Set parameter to use tensor rep for DG Poisson demo. It's broken. > > This shows that tensor rep is not wotking for DG. I think it just shows that the tensor representation does not handle FacetNormals or Division which is known. Without the -r representation option, FFC will automatically discover that the integrand in question needs to be done with quadrature but if someone insists on -r tensor, then FFC will try and explain why it fails: *** FFC: No handler defined for expression Division. I'll switch the demo back to "auto". -- Anders > modified: > demo/pde/dg/poisson/python/demo.py > > > === modified file 'demo/pde/dg/poisson/python/demo.py' > --- demo/pde/dg/poisson/python/demo.py2010-01-27 21:09:29 + > +++ demo/pde/dg/poisson/python/demo.py2010-02-02 23:16:44 + > @@ -23,6 +23,8 @@ > > from dolfin import * > > +parameters["form_compiler"]["representation"] = "tensor" > + > # Create mesh and define function space > mesh = UnitSquare(24, 24) > V = FunctionSpace(mesh, "DG", 1) > signature.asc Description: Digital signature ___ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp
Re: [Ffc] strip_variables
On 2 February 2010 23:26, Garth N. Wells wrote: Should the UFL function 'strip_variables' be called on a UFL form from inside FFC? I suspect that this may fix the bug I remember that there was a problem with calling the algorithm_strip variables. I did that once as an easy fix to handle Variable, but it screwed something up I remember but what it was I don't recall. Maybe it was a performance issue? Does calling strip_variables solve all problems related to Variable? Kristian https://bugs.launchpad.net/ufl/+bug/512425 Garth ___ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp
