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
