ffc team mailing list archive

["Murtazo Nazarov" <murtazo@xxxxxxxxxxx>]

>> 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
>
>

Having index notation would be the best in general. Because, you know that
you have full control of the system you are solving. A similar issue I
posted a month ago. It seems there is no index notation defined in mixed
elements. As Johan pointed it out we use mix elements in compressible
solver. Now, instead of short and clear definition using index notation I
split out the equations to the several one: like for momentum I have three
separate equations which makes difficulties if I need to change some part
of model.

In the future, since the aim of Unicorn is to have a general solver for
continuous mechanics, having index notation would be preferable. I hope it
will be included in coming releases.

/murtazo