ffc team mailing list archive

["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?
>
> --
> Anders

Probably not.

--
Martin