ffc team mailing list archive

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

> 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