Hey Martin, dont get me wrong, I did not ask you to revert the commit. Only, from the commit message it wasnt even obvious if the change turned out to be beneficient or not. I am also aware that I am working with implementation details of UFL, which may change quite a lot. My plan is to stick to releases of UFL to be as stable as possible.
My decision to go with Steffens prototype (at least for the moment) is based on the idea, that he has already thought through the specialties of Dune (compared to the FEniCs stack) and designed the form compiler suitably (it got some more development after 2011 btw). I am aware of the existence of uflacs, but from reading through it, I got the impression that it still is conceptionally specific to FEniCS (esp. dolfin) in many ways. So, I concluded I'd be better off (especially in terms of quick success) to go with what we have. I agree though, that discussing this in person would be a good idea. Best, Dominic PS: Sorry for not being registered to the list and producing these moderation requests. My subscription is still pending. On Wed, Feb 25, 2015 at 3:05 PM, Kent-Andre Mardal <[email protected]> wrote: > I strongly support Martin here. A visit to Simula and discussions with > Martin in particular would be beneficial. > It would also be interesting for us at Simula to learn more about DUNE. > > Kent > > > On 25 February 2015 at 14:42, Martin Sandve Alnæs <[email protected]> > wrote: > >> Dear Dominic, >> >> Great that you want to try building a ufl-dune form compiler! >> >> The optimizations in that commit were based on a detailed profiling, and >> simplifying >> the constructors of Sum and Product turned out to be crucial for >> performance on >> complicated equations. I won't revert the change and I can't promise not >> making >> more changes to internal details. >> >> I wonder though, if it's fruitful for you to write yet another form >> compiler based on a >> 4 year old quick prototype that hasn't been maintained (AFAIK). I've done >> a lot of work >> on the uflacs code base since then and I think it's a better idea to >> collaborate on making >> a dune compiler on top of that instead. Let me know if this is >> interesting to you. >> >> If you insist on going your own way, I suggest building your own code >> representation >> tree adapted to your own compiler needs. That way you won't be as >> dependent on >> internal changes in UFL. >> >> Best, >> Martin >> >> On 25 February 2015 at 14:18, Dominic Kempf <[email protected]> >> wrote: >> >>> Dear FEniCS crowd, >>> >>> I have recently started my PhD in the research group of Peter Bastian at >>> IWR Heidelberg. As part of my work, I have revived the project of a form >>> compiler for the Dune discretization module dune-pdelab, which was started >>> by Steffen Müthing during a visit at SIMULA in 2011. >>> >>> Porting the existing code base to the newer versions of UFL, I have >>> stumbled across the fact, that you limited all algebraic operators to be >>> binary (in f0da3b2566181d26706d). This breaks the very core of my form >>> compiler, as the given UFL expressions need to be transformed in order to >>> enforce some specific properties of the Dune approach. Until now, those >>> transformations did explicitly flatten all sums and products. Before taking >>> the dive and rewriting those parts, I would like to understand the reasons >>> for the change and whether there is some replacing concept for multi >>> operand algebraic operators, that I did not find. The commit message >>> ("Attempt to optimize product construction, enforcing assumption of two >>> operands") isnt very helpful, unfortunately. >>> >>> Thanks in advance! >>> >>> Best, >>> Dominic >>> >> >> >> _______________________________________________ >> fenics mailing list >> [email protected] >> http://fenicsproject.org/mailman/listinfo/fenics >> >> >
_______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
