ffc team mailing list archive

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

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

Attachment: signature.asc
Description: Digital signature