ffc team mailing list archive

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

Found, fixed, and pushed to ffc-uflacs-ufc-geometry-merged/.
I had to add -e to building of AdaptivePoisson.ufl in the ffc
regression test to make the bug visible there, which is why I didn't
catch it earlier. Although it had nothing to do with error control.
It would be good to add some demo files to ffc that cover more
corner cases, there's a lot of very similar forms there from a
testing perspective.

Now the only demos failing to build in dolfin are:

pde/biharmonic
undocumented/dg-poisson
undocumented/stokes-stabilized
/undocumented/dg-poisson

With errors like this:
/home/martinal/dev/fenics/dolfin/work/demo/pde/biharmonic/cpp/Biharmonic.h:2770:40:
error: ‘x_0’ was not declared in this scope
/home/martinal/dev/fenics/dolfin/work/demo/pde/biharmonic/cpp/Biharmonic.h:2771:39:
error: ‘J_0_11’ was not declared in this scope
/home/martinal/dev/fenics/dolfin/work/demo/undocumented/stokes-stabilized/cpp/Stokes.h:5258:38:
error: ‘x’ was not declared in this scope
/home/martinal/dev/fenics/dolfin/work/demo/undocumented/stokes-stabilized/cpp/Stokes.h:5259:37:
error: ‘J_11’ was not declared in this scope

which looks like a few more geometry snippets fixes.

Martin



On 28 February 2013 12:07, Kristian Ølgaard <k.b.oelgaard@xxxxxxxxx> wrote:

> On 28 February 2013 10:12, Martin Alnæs <martinal@xxxxxxxxx> wrote:
> > Ok, I know where to look. Basically, when a symbol is created with GEO
> access instead of IP, it becomes part of the G array?
>
> Yes, GEO is G, IP is inside the integration points loop (array I), and
> BASIS is inside the 'j' and 'k' loops (array B, if used).
>
> Kristian
>
> > Martin
> >
> > Den 28. feb. 2013 kl. 07:45 skrev Kristian Ølgaard <
> k.b.oelgaard@xxxxxxxxx>:
> >
> >> On 27 February 2013 23:48, Anders Logg <logg@xxxxxxxxx> wrote:
> >>> I'm trying to get DOLFIN to build against the new UFC branch (the
> >>> foo-ufc-geometry branches) and it works mostly ok now, but for a few
> >>> demos, something strange happens in the optimized quadrature code.
> >>>
> >>> One example that fails is AdaptivePoisson.ufl/h in
> >>> demo/undocumented/auto-adaptive-poisson/. In the new code, the
> >>> following fails to build
> >>>
> >>>    double G[6];
> >>>    G[0] =  - F1*det*(K[0]*K[2] + K[1]*K[3]);
> >>>    G[1] =  - F1*det*(K[2]*K[2] + K[3]*K[3]);
> >>>    G[2] =  - F1*det*(K[0]*K[0] + K[1]*K[1]);
> >>>    G[3] = F1*det;
> >>>    G[4] =  - det*(K[0]*(F4*K[0] + F5*K[2]) + K[1]*(F4*K[1] + F5*K[3]));
> >>>    G[5] =  - det*(K[2]*(F4*K[0] + F5*K[2]) + K[3]*(F4*K[1] + F5*K[3]));
> >>>
> >>> because F1 has not been defined.
> >>
> >> F1 is something related to a coefficient function while G are geometry
> >> konstants.
> >> So F1 is always computed after the geometry constants (the first thing
> >> to be computed inside the loop over integration points)
> >> Why F1 is being marked as a geometry constant and not as depending on
> >> integration points I don't know.
> >> I assume what you did in ufc-geometry is to store all the K_** in the
> >> array K, but I don't see how that has an effect on the optimisations.
> >> Perhaps Martin changed something if you are running against ffc dev?
> >>
> >> Kristian
> >>
> >>> In the old code, that same piece of code is instead
> >>>
> >>>    double G[3];
> >>>    G[0] =  - det*(K_00*K_10 + K_01*K_11);
> >>>    G[1] =  - det*(K_10*K_10 + K_11*K_11);
> >>>    G[2] =  - det*(K_00*K_00 + K_01*K_01);
> >>>
> >>> Any ideas what might have gone wrong?
> >>>
> >>> --
> >>> Anders
> >>>
> >>> _______________________________________________
> >>> Mailing list: https://launchpad.net/~ffc
> >>> Post to     : ffc@xxxxxxxxxxxxxxxxxxx
> >>> Unsubscribe : https://launchpad.net/~ffc
> >>> More help   : https://help.launchpad.net/ListHelp
> >>
> >> _______________________________________________
> >> Mailing list: https://launchpad.net/~ffc
> >> Post to     : ffc@xxxxxxxxxxxxxxxxxxx
> >> Unsubscribe : https://launchpad.net/~ffc
> >> More help   : https://help.launchpad.net/ListHelp
>