ffc team mailing list archive

[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

Attachment: signature.asc
Description: Digital signature