ffc team mailing list archive

["Martin Sandve Alnæs" <martinal@xxxxxxxxx>]

2008/9/13 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 the reason I would want to combine the compilers into one isn't to
be able to write "ffc" instead of "sfc", it's so I wouldn't have to
rewrite and maintain the quadrature code generation :-)

--
Martin