← Back to team overview

ffc team mailing list archive

Re: mixed element issue?

 

A question as I get back up the learning curve:
We now have H(div) capabilities in FFC and also DG capabilities thanks to
the hard work of many people.

Has anyone been so perverse as to try to put these together?

I ask because Bangerth & Kanschat have a neat technique for Navier-Stokes
wherein
they do the velocity with Raviart-Thomas elements.  These are in H(div) but
not H^1, so the
put DG-type penalty terms in the tangential direction.

Any thoughts on whether this will work?  If it is known not to work, I would
like to request the feature of DG + Piola-mapped elements...  If it is
unknown, I will be happy to be a guinea pug.

Thanks,
Rob



On Wed, Apr 16, 2008 at 4:49 PM, Martin Sandve Alnæs <martinal@xxxxxxxxx>
wrote:

> 2008/4/16, Anders Logg <logg@xxxxxxxxx>:
> > On Wed, Apr 16, 2008 at 09:24:02PM +0200, Johan Hoffman wrote:
> >  > > 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).
> >
> >
> > Indexing is one of many priorities for UFL.
> >
> >
> >  > I wasn't sure I was supposed to edit the UFL page directly with this
> >  > wishes? What do you say Anders?
> >
> >
> > Yes, just edit the page with suggestions. That's what it's for.
>
> All suggestions are welcome!
>
> Perhaps the best way to add suggestions is to write an example form
> with wanted syntax and explain with verbose comments what you mean by
> it. Then I can use the code as a unit test as well.
>
> Note that the page may be slightly out of sync with what's
> implemented, I'll get around to cleaning this up in a few weeks (other
> pressing matters right now), and can merge your additions in then.
>
> --
> Martin
> _______________________________________________
> FFC-dev mailing list
> FFC-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/ffc-dev
>

Follow ups

References