Subject: [Ffc] Status update

From: Anders Logg <[email-masked]>
Date: Mon, 25 Jan 2010 18:50:09 +0100

It's starting to look better. The following 8 tests are currently failing:

Generating code
---------------

1. ElementRestriction.ufl failed

*** FFC: Sorry, finite element of type "ElementRestriction" are not
supported by FIAT.

I assume Kristian knows what to do.

2. QuadratureElement.ufl failed

*** FFC: Sorry, finite element of type "Quadrature" are not
supported by FIAT.

I assume Kristian knows what to do.

3. TensorWeightedPoisson.ufl failed

*** FFC: Can only handle rank 0 or rank 1 tensors.

This is a bug in the selection of representation. The tensor
representation should realize earlier that it can't handle tensors
so quadrature should be selected.

Building test programs
----------------------

4. Constant failed

Constant.h:1044: error: unused variable ‘x’

Bug in evaluate_basis or removed_unused?

5. FacetIntegrals failed

Same problem in evaluate_basis

6. MixedMixedElement failed

Same problem in evaluate_basis

7. VectorLaplaceGradCurl failed

VectorLaplaceGradCurl.h:3650: error: ‘K_00’ was not declared in this
scope

Another problem in evaluate_basis

Validating generated programs
-----------------------------

8. P5tet.bin failed

Segmentation fault when calling evaluate_basis_derivatives

--
Anders

---

From: Kristian Oelgaard <[email-masked]>
Date: Mon, 25 Jan 2010 19:14:20 +0100 (CET)

> It's starting to look better. The following 8 tests are currently failing:

Yes, but I'll fix evaluate_basis and get correct results for quadrature code first.

> I assume Kristian knows what to do.

Yes, we should manually check for family == "Quadrature" then return a FFC.QuadratureElement and make sure it has the same member functions as the FIAT.FiniteElement that we currently expects around the code.

> so quadrature should be selected.

I assume Anders knows what to do. :)

> Building test programs

I'm looking into this now. It is related to how intelligent remove_unused is.
I think the easiest solution is to create a set of used variables when generating the code and the have remove_unused operate on the jacobian snippets, which will be the fastest way of doing things anyway.
A fix will be on it's way tomorrow.

> Another problem in evaluate_basis

I'll take a look, should be a format thing from changing from Jinv_ -> K

> Validating generated programs

I don't know what to make of this, but I'll take a look once the other issues has been sorted out.

When running the regression tests, I guess that if the generated code is equal to the reference code there is no need to proceed compiling and running the test program. This will save us some time when running the test suite.

Kristian

> --
> Anders
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAktd2dEACgkQTuwUCDsYZdGk3wCgiHS3vIknl⹨롷崊躪�
> 09sAnRm2lrE3UfFEBK8AejL0FwJbfB3L
> =Rqd8
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Mailing list: https://launchpad.net/~ffc
> Post to     : [email-masked]
> Unsubscribe : https://launchpad.net/~ffc
> More help   : https://help.launchpad.net/ListHelp
>
>

---

From: Anders Logg <[email-masked]>
Date: Mon, 25 Jan 2010 19:43:20 +0100

> Yes, but I'll fix evaluate_basis and get correct results for

ok.

> Yes, we should manually check for family == "Quadrature" then return a FFC.QuadratureElement and make sure it has the same member functions as the FIAT.FiniteElement that we currently expects aroun…

ok.

> I assume Anders knows what to do. :)

Yes! I'm working on it now.

> A fix will be on it's way tomorrow.

Yes, that's the best way. That is how I do it in the tensor code
generator.

> I'll take a look, should be a format thing from changing from Jinv_ -> K

ok.

> other issues has been sorted out.

I tried to see what goes wrong and it was very strange. The variable
num_derivatives gets the value 1 and then it changes to some
completely strange value (like 2312391239123). Looks like a memory
allocation problem. It shouldn't be ruled out that the problem is how
the function is called from within ufctest.h (some array not allocated
properly).

> When running the regression tests, I guess that if the generated code is equal to the reference code there is no need to proceed compiling and running the test program. This will save us some time…

Yes, this will be added.

--
Anders

---

From: Marie Rognes <[email-masked]>
Date: Mon, 25 Jan 2010 20:16:06 +0100

Let me know if I should do anything else than adding unit tests for 
RT/BDM/NED.
(Aaargh, btw).

Is the jit compilation working?

--
Marie

Anders Logg wrote:
> ------------------------------------------------------------------------
>

---

From: Anders Logg <[email-masked]>
Date: Mon, 25 Jan 2010 20:18:46 +0100

> Let me know if I should do anything else than adding unit tests for

I hope to add more a selection of elements to the regression tests
later. Then you can feel very free to help with the debugging. :-)

> Is the jit compilation working?

I hope so. It worked last week but it might have broken since then.

--
Anders

---

From: Marie Rognes <[email-masked]>
Date: Mon, 25 Jan 2010 20:46:47 +0100

> later. Then you can feel very free to help with the debugging. :-)

Hurray ;)

> I hope so. It worked last week but it might have broken since then.

Looks slightly suboptimal, cf below.

(Also, something goes awry in the generation of the dolfin wrapper code 
for mixed elements.
Try compiling the dolfin Elasticity demo for instance.)

meg@localhost ~/local/src/fenics/dolfin/demo/pde/poisson/python $ python 
demo.py
Calling FFC just-in-time (JIT) compiler, this may take some time.
Traceback (most recent call last):
  File "demo.py", line 24, in <module>
    V = FunctionSpace(mesh, "CG", 1)
  File 
"/home/meg/local/lib64/python2.6/site-packages/dolfin/function/functionspace.py", 
line 226, in __init__
    FunctionSpaceBase.__init__(self, mesh, element)
  File 
"/home/meg/local/lib64/python2.6/site-packages/dolfin/function/functionspace.py", 
line 44, in __init__
    ufc_element, ufc_dofmap = jit(self._ufl_element)
  File 
"/home/meg/local/lib64/python2.6/site-packages/dolfin/compilemodules/jit.py", 
line 44, in mpi_jit
    return local_jit(*args, **kwargs)
  File 
"/home/meg/local/lib64/python2.6/site-packages/dolfin/compilemodules/jit.py", 
line 108, in jit
    return jit_compile(form, options)
  File "/home/meg/local/lib64/python2.6/site-packages/ffc/jit.py", line 
59, in jit
    return jit_element(object, options)
  File "/home/meg/local/lib64/python2.6/site-packages/ffc/jit.py", line 
150, in jit_element
    return extract_element_and_dofmap(module)
  File "/home/meg/local/lib64/python2.6/site-packages/ffc/jit.py", line 
182, in extract_element_and_dofmap
    return (getattr(module, module.__name__ + "_0_finite_element_0")(),
AttributeError: 'module' object has no attribute 
'form_20a60ceb7c37f811570413455597a3abad2819b8_0_finite_element_0'

---

From: Anders Logg <[email-masked]>
Date: Mon, 25 Jan 2010 20:50:30 +0100

On Mon, Jan 25, 2010 at 08:46:47PM +0100, Marie Rognes wrote:
> (Also, something goes awry in the generation of the dolfin wrapper
> code for mixed elements.

ok, I will take a look.

--
Anders

>
>
> meg@localhost ~/local/src/fenics/dolfin/demo/pde/poisson/python $
> python demo.py
>  File "/home/meg/local/lib64/python2.6/site-packages/dolfin/function/functionspace.py",
> line 226, in __init__
>  File "/home/meg/local/lib64/python2.6/site-packages/dolfin/function/functionspace.py",
> line 44, in __init__
>  File "/home/meg/local/lib64/python2.6/site-packages/dolfin/compilemodules/jit.py",
> line 44, in mpi_jit
>  File "/home/meg/local/lib64/python2.6/site-packages/dolfin/compilemodules/jit.py",
> line 108, in jit
>  File "/home/meg/local/lib64/python2.6/site-packages/ffc/jit.py",
> line 59, in jit
>  File "/home/meg/local/lib64/python2.6/site-packages/ffc/jit.py",
> line 150, in jit_element
>  File "/home/meg/local/lib64/python2.6/site-packages/ffc/jit.py",
> line 182, in extract_element_and_dofmap

---

From: Anders Logg <[email-masked]>
Date: Mon, 25 Jan 2010 21:07:45 +0100

> Looks slightly suboptimal, cf below.

JIT compiler seems to work again.

--
Anders

---

From: Anders Logg <[email-masked]>
Date: Mon, 25 Jan 2010 21:29:00 +0100

> Try compiling the dolfin Elasticity demo for instance.)

Should also be fixed now, but the code does not compile yet because of
a bug in evaluate_basis_derivatives:

Elasticity.h:875: error: array subscript is above array
boundsElasticity.h:875: error: array subscript is above array bounds

--
Anders

---

From: Kristian Oelgaard <[email-masked]>
Date: Tue, 26 Jan 2010 12:37:12 +0100

> Yes, that's the best way. That is how I do it in the tensor code

Actually, it turns out that if I remove the line in remove_unused (not
just comment it, I guess this is for debugging?) it works fine.

I have all demos (not Restriction and Quadrature) compiling, including
gcc, but apparently I have no internet on my computer at the moment so
I can't push the fixes. I'll keep working on getting the numbers
correct for the tabulate_tensor() function for quadrature code w.r.t.
the old references.

Kristian

> iEYEARECAAYFAktd5kgACgkQTuwUCDsYZdHNFwCffDN0qOR1ydfwCgNCt46685I6
> N/MAn1Rq8t4lDNSv12NwdZUYekjgw9b9
> =ADQt

---

From: Anders Logg <[email-masked]>
Date: Tue, 26 Jan 2010 12:43:32 +0100

> just comment it, I guess this is for debugging?) it works fine.

Very strange... I had some problems with the tensor code generation
yesterday and then it turned out that commenting instead of removing
made it work... :-)

Does the tensor representation work for terms involving interior_facet
integrals? Can you check if SubDomains.ufl still goes through the
regression tests? I had problems compiling it because unused
variables were not removed correctly.

> correct for the tabulate_tensor() function for quadrature code w.r.t.

ok!

--
Anders

> >> >scope> >> >

---

From: Marie Rognes <[email-masked]>
Date: Tue, 26 Jan 2010 13:42:52 +0100

> JIT compiler seems to work again.

Definite improvement :)  Could you take a look at what goes wrong with

    dolfin/demo/pde/mixed-poisson/python/demo.py

?

---

From: Anders Logg <[email-masked]>
Date: Tue, 26 Jan 2010 13:48:45 +0100

>    dolfin/demo/pde/mixed-poisson/python/demo.py

Looks strange. I will take a look.

--
Anders

---

From: Anders Logg <[email-masked]>
Date: Wed, 27 Jan 2010 19:19:48 +0100

>    dolfin/demo/pde/mixed-poisson/python/demo.py

Fixed.

--
Anders