ffc team mailing list archive

["Johan Hoffman" <jhoffman@xxxxxxxxxx>]

> Hi all, I'm trying to do a survey of all the different ways of enforcing
> incompressibility in the Navier-Stokes equations, and FFC/FIAT of course
> has
> the most advanced element capabilities for doing this...
>
> Unfortunately, I have hit a snag (either in my ignorance or through a bug)
> in my grand scheme, starting with the Oseen equations (fix the convective
> velocity for fixed points, don't do the full Newton linearization).
>
> It seems that if you put a vector element into a mixed element and then
> take
> it back out, you can no longer index it.
>
> Putting the following in a .form (everything that doesn't involve pressure
> spaces) works beatifully
> #start .form file here
> vel_element = VectorElement("Lagrange","triangle",2)
> u = TrialFunction( vel_element )
> v = TestFunction( vel_element )
> u0 = Function( vel_element )
>
> a = D(v[i],j)*D(u[i],j)*dx + v[i]*u0[j]*D(u[i],j)*dx
> #end .form file
>
> On the other hand, if I do:
> # start new .form file here
> vel_element = VectorElement("Lagrange","triangle",2)
> pre_element = FiniteElement("Lagrange","triangle",1)
> element = vel_element + pre_element
> (u,p) = TrialFunctions( element )
> (v,q) = TestFunctions( element )
> u0 = Function( vel_element )
>
> a = D(v[i],j)*D(u[i],j)*dx + v[i]*u0[j]*D(u[i],j)*dx
> # end new .form file
>
> I get an error:
>
> Preprocessing form file: Oseen.form --> Oseen.py
>
> *** object cannot be interpreted as an index
> *** To get more information about this error, rerun ffc with the option
> -d1.
>
> I've attached the output using -d1.
>
> Any corrections either of my stupidity or of FFC would be appreciated :)

Hi Rob!

I don't think you have to question your sanity, we have experienced
similar problems when dealing with the compressible Euler equations: with
scalar density and energy together with a momentum vector. We have been
forced to use built in operators instead, which is non optimal since the
definitions of the action of some operators is a bit unclear.

I do not know what the underlying problem is, but we have brought this up
before and it seems to be non-trivial? Or maybe (hopefully) I am wrong?

This is also something I want to stress for the coming UFL; that to me in
terms of operators, the most important is to have a fully reliable system
for indexing. Then to add a nice collection of well defined operators on
top is great, but secondary (to me).

I wasn't sure I was supposed to edit the UFL page directly with this
wishes? What do you say Anders?

/Johan



>
> Rob
> _______________________________________________
> FFC-dev mailing list
> FFC-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/ffc-dev
>