ffc team mailing list archive

[Kristian Oelgaard <k.b.oelgaard@xxxxxxxxxx>]

Quoting Martin Sandve Alnæs <martinal@xxxxxxxxx>:

> 2008/9/12 Anders Logg <logg@xxxxxxxxx>:
> > On Fri, Sep 12, 2008 at 12:11:13PM +0200, Kristian Oelgaard wrote:
> >> Quoting Martin Sandve Alnæs <martinal@xxxxxxxxx>:
> >>
> >> > 2008/9/10 Anders Logg <logg@xxxxxxxxx>:
> >> > > On Wed, Sep 10, 2008 at 11:48:14AM +0200, Martin Sandve Alnæs wrote:
> >> > >> 2008/9/10 Anders Logg <logg@xxxxxxxxx>:
> >> > >> > On Wed, Sep 10, 2008 at 11:33:27AM +0200, Kristian Oelgaard wrote:
> >> > >> >> Quoting Anders Logg <logg@xxxxxxxxx>:
> >> > >> >>
> >> > >> >> > On Wed, Sep 10, 2008 at 11:17:32AM +0200, Kristian Oelgaard
> wrote:
> >> > >> >> > >
> >> > >> >> > > Hi,
> >> > >> >> > >
> >> > >> >> > > This is my standard procedure for FFC development:
> >> > >> >> > >
> >> > >> >> > >   1. Modify FFC
> >> > >> >> > >   2. Run regression tests
> >> > >> >> > >   3. Regression tests fails
> >> > >> >> > >   4. Look at code, to see if it makes sense
> >> > >> >> > >   5. Generate new references
> >> > >> >> > >   6. Push to repository
> >> > >> >> > >
> >> > >> >> > >
> >> > >> >> > > Instead of step 4 it would obviously be better to actually
> check if
> >> > the new
> >> > >> >> > code
> >> > >> >> > > still computes the right thing. To this end I've created a
> module
> >> > that
> >> > >> >> > verifies
> >> > >> >> > > if tabulate_tensor() is correct according to some reference.
> The
> >> > module
> >> > >> >> > needs
> >> > >> >> > > ufc_benchmark to run.
> >> > >> >> > >
> >> > >> >> > > have a look at ffc/src/test/verify_tensor/test.py
> >> > >> >> > >
> >> > >> >> > > ./test.py -h
> >> > >> >> > >
> >> > >> >> > >
> >> > >> >> > > Kristian
> >> > >> >> >
> >> > >> >> > I've looked at it and it looks very good. Will you add
> references
> >> > for
> >> > >> >> > all the forms?
> >> > >> >>
> >> > >> >> Sure, I didn't want to flood the repository with a lot of
> references if
> >> > we
> >> > >> >> decided we didn't need it. Currently, I'm assembling over the
> >> > reference
> >> > >> >> elements. Would it be better to use arbitrary elements? I'm just
> >> > wondering if
> >> > >> >> certain bugs will be picked up by an element defined with a lot
> of
> >> > zeros and ones.
> >> > >> >
> >> > >> > Yes, it would definitely be better to use another element. I
> suggest
> >> > >> > randomizing a triangle and a tet and then sticking those numbers
> into
> >> > >> > the code.
> >> > >> >
> >> > >> >> > Is the idea that we run this only when the regression tests
> fail
> >> > >> >> > (since it may take some time to run)?
> >> > >> >>
> >> > >> >> Yes, if the regression test do not fail, the code will return the
> same
> >> > values as
> >> > >> >> last time the verify_tensor/test.py was run. This is why I didn't
> >> > include it in
> >> > >> >> the top test.py script.
> >> > >> >
> >> > >> > ok.
> >> > >> >
> >> > >>
> >> > >> Great! I've been wanting something like this to ease the development
> >> > >> of the UFL based form compiler. I can probably modify your tests
> with
> >> > >> fairly small changes to use UFL, and make the form compiler an
> option,
> >> > >> so we can share the tests based on UFL. I'll wait until you've done
> >> > >> the improvements discussed above.
> >> > >>
> >> > >> I do wonder though, whether it makes sense to keep two form compiler
> >> > >> projects if both will implement the full UFL language...
> >> > >
> >> > > It would make sense to have just one form compiler and make the code
> >> > > generation strategy an option. But I suspect it will take a lot of
> >> > > effort to merge. Do we want to do this now?
> >>
> >> I too think this would make sense and I also agree that we don't want to
> do this
> >> now. However, two things to consider:
> >>
> >> 1) Having two different compilers make the philosophy behind UFL and UFC
> >>    very obvious.
> >
> > Yes, this is a good point.
> >
> >> 2) Specifying what strategy to use will add yet another command line
> option
> >>    that one has to supply.
> >
> > That is not such a big problem since we already have -r tensor,
> > quadrature. We could just add an option -r syfi.
> 
> Nope. SFC also has multiple representations. And in real life,
> quadrature is the most important.

Yes, I guess:

ffc -r quadrature -fno-evaluate_basis -fno-evaluate_basis_derivatives
-fsplit_implementation Poisson.form

and

compiler -r ffc -r quadrature -fno-evaluate_basis
-fno-evaluate_basis_derivatives -fsplit_implementation Poisson.form

are almost equally complex.

Kristian

 
> > But a bigger problem is dependencies. FFC depends on FIAT and SFC
> > depends on SyFi (which requires compilation of a C++ library and SWIG)
> > so we would need to have optional dependencies.
> >
> > --
> > Anders
> 
> --
> Martin
> _______________________________________________
> FFC-dev mailing list
> FFC-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/ffc-dev
>