Subject: Re: [Ffc] evaluate_basis update

From: Kristian Oelgaard <[email-masked]>
Date: Thu, 28 Jan 2010 19:37:02 +0100 (CET)

On 28 January 2010 18:44, Marie Rognes <[email-masked]> wrote:
> [email-masked] wrote:
>>
>> Hi,
>>
>> I'm running some tests on evaluate_basis with different elements and here
>> are some results.
>>
>> The following elements are no longer supported by FIAT:
>>  Crouzeix-Raviart and Brezzi-Douglas-Fortin-Marini, will they be supported
>> again?
>>
>
>
> I would say that BDFM is not important, but that CR is.

OK, will CR be added to FIAT_NEW? I don't have any idea about how to do this.

>
>> The following elements could not be compiled by gcc because of a problem
>> with and undefined variable 'copy' in evaluate_dof() and evaluate_dofs():
>>  FiniteElement('Brezzi-Douglas-Marini', Cell('triangle', 1, Space(2)), 2)
>>  FiniteElement('Brezzi-Douglas-Marini', Cell('triangle', 1, Space(2)), 3)
>>  FiniteElement('Brezzi-Douglas-Marini', Cell('tetrahedron', 1, Space(3)),
>> 2)
>>  FiniteElement('Brezzi-Douglas-Marini', Cell('tetrahedron', 1, Space(3)),
>> 3)
>>  FiniteElement('Nedelec 1st kind H(curl)', Cell('triangle', 1, Space(2)),
>> 2)
>>  FiniteElement('Nedelec 1st kind H(curl)', Cell('triangle', 1, Space(2)),
>> 3)
>>  FiniteElement('Nedelec 1st kind H(curl)', Cell('tetrahedron', 1,
>> Space(3)), 3)
>>
>
> Known potential issue. Will fix.

Great, thanks.

>
>> A funny thing to note is that
>>  FiniteElement('Nedelec 1st kind H(curl)', Cell('tetrahedron', 1,
>> Space(3)), 2)
>> compiles fine.
>>
>> Values differ for the following DG element:
>>  FiniteElement('Discontinuous Lagrange', Cell('interval', 1, Space(1)), 2)
>>  FiniteElement('Discontinuous Lagrange', Cell('interval', 1, Space(1)), 3)
>>  FiniteElement('Discontinuous Lagrange', Cell('interval', 1, Space(1)), 4)
>>  FiniteElement('Discontinuous Lagrange', Cell('tetrahedron', 1, Space(3)),
>> 2)
>>  FiniteElement('Discontinuous Lagrange', Cell('tetrahedron', 1, Space(3)),
>> 3)
>>  FiniteElement('Discontinuous Lagrange', Cell('tetrahedron', 1, Space(3)),
>> 4)
>>  FiniteElement('Discontinuous Lagrange', Cell('triangle', 1, Space(2)), 2)
>>  FiniteElement('Discontinuous Lagrange', Cell('triangle', 1, Space(2)), 3)
>>  FiniteElement('Discontinuous Lagrange', Cell('triangle', 1, Space(2)), 4)
>> but Marie changed the ordering of dofs, so that is not big mystery.
>
>
> I refuse to take the blame for changing the ordering of the dofs! ;)

Hmm, I thought I remembered your name popping up in the same sentence as 'DG', 'reordering' and 'dofs' on the list, but that must be a mistake then. (Note that now your name is actually in a sentence with these three key-words so someone else might blame you later on again :) )

>> I checked some values manually and it looks like the values has just been
>> shifted around so the result should be OK.
>>
>
>
> Good!
>
>
>> Values also differ for the following elements:
>>  FiniteElement('Nedelec 1st kind H(curl)', Cell('tetrahedron', 1,
>> Space(3)), 2)
>>  FiniteElement('Raviart-Thomas', Cell('tetrahedron', 1, Space(3)), 2)
>>  FiniteElement('Raviart-Thomas', Cell('tetrahedron', 1, Space(3)), 3)
>>  FiniteElement('Raviart-Thomas', Cell('triangle', 1, Space(2)), 2)
>>  FiniteElement('Raviart-Thomas', Cell('triangle', 1, Space(2)), 3)
>> For the Nedelec element values look the same, but they appear in different
>> places.
>>
>> If I call tabulate on the FIAT element (reference) I get matching results
>> as when I call evaluate_basis(), so I guess it is OK. Marie, has the
>> ordering of dofs changed for Nedelec?
>
>
> Don't know actually.  I can check evaluate_dof.

OK, thanks.

>
>>
>> For the Raviart-Thomas elements the story is almost the same. The only
>> difference is that for e.g.,
>>  FiniteElement('Raviart-Thomas', Cell('triangle', 1, Space(2)), 2)
>> I get values like '0.44444 0.55556 0.22222 -0.22222 -0.33333' in the 'old'
>> version of FFC and FIAT, but in the new FFC (and the new FIAT) I get values
>> like:
>> 0.66667 0.33333 -0.00000 -0.00000 -0.33333' when I tabulate the basis at
>> the same point. Marie, has something changed for RT elements?
>
>
> Yes. Rob changed the interior degrees of freedom for polynomial degrees > 1
> from integral moments to point values. Hence the basis
> functions have changed.
>
> (Note that there is a unit test for RT2 on a triangle that passes :) )

Aha, I would have found it if I cared to look for it, but thanks for pointing it out.

Kristian

> --
> Marie
>
>>
>> For both old and new FFC FIAT.tabulate() and evaluate_basis() agrees so I
>> guess the values are OK.
>>
>> If the above issues can be confirmed and addressed It looks like
>> evaluate_basis can be trusted.
>>
>> Kristian
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~ffc
>> Post to     : [email-masked]
>> Unsubscribe : https://launchpad.net/~ffc
>> More help   : https://help.launchpad.net/ListHelp
>>  
>
>

---

From: Kristian Oelgaard <[email-masked]>
Date: Thu, 28 Jan 2010 19:51:52 +0100 (CET)

On 28 January 2010 19:18, Anders Logg <[email-masked]> wrote:
> Update:
>  ElementRestriction.ufl

Could you have a look at and comment on the discussion about element restrictions? It was posted a couple of days ago on the list. It would be nice to get right the first time.

Kristian

>  QuadratureElement.ufl
>  evaluate_basis_derivatives* 1510
>
> Everything else seems to be ok. There's one tabulate_tensor reported
> in error.log but it's the result of different handling of integrals on
> sub domains.
>
> So things are looking good!
>
> --
> Anders
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkth1OkACgkQTuwUCDsYZdFeaQCfWn9HAtAhP1yjLkp7BRp2k9cG
> 3/IAnj2KXkVCXkP1C4PBU+5nZNuxPlf2
> =nzGG
> -----END PGP SIGNATURE-----
>
>

---

From: Anders Logg <[email-masked]>
Date: Thu, 28 Jan 2010 20:31:24 +0100

On Thu, Jan 28, 2010 at 07:51:52PM +0100, Kristian Oelgaard wrote:
> Could you have a look at and comment on the discussion about element
> restrictions? It was posted a couple of days ago on the list. It
> would be nice to get right the first time.

You mean me? I don't know much about restrictions. Who added them in
the first place?

I will have a look at the other thread.

--
Anders

---

From: Kristian Oelgaard <[email-masked]>
Date: Thu, 28 Jan 2010 21:03:46 +0100 (CET)

> You mean me? I don't know much about restrictions. Who added them in

Sorry, yes you. I implemented the restrictions onto facets (Cell) and Mehdi uses the restrictions onto Measure (*dc), the later is implemented, as I understand it, simply as a flag which the code generator looks for.

> I will have a look at the other thread.

OK.

Kristian

> iEYEARECAAYFAkth5gwACgkQTuwUCDsYZdFQyQCdGk677PVCXwVt031BW/P+JVua
> sQ8An3q1mGzUlqJ13lS3fjwT9E8Pzail
> =hEKi

---

From: Anders Logg <[email-masked]>
Date: Thu, 28 Jan 2010 21:04:44 +0100

> Could you have a look at and comment on the discussion about element restrictions? It was posted a couple of days ago on the list. It would be nice to get right the first time.

I can't find the discussion about element restrictions.

What is the status of getting ElementRestriction working? I haven't
looked at restrictions at all so I don't know how it should be
handled.

And shouldn't the name of the element be RestrictedElement rather than
ElementRestriction?

---

From: "Garth N. Wells" <[email-masked]>
Date: Thu, 28 Jan 2010 20:16:05 +0000

> And shouldn't the name of the element be RestrictedElement rather than

I should probably be 'FacetRestriction'.

Garth

---

From: Kristian Oelgaard <[email-masked]>
Date: Thu, 28 Jan 2010 21:16:44 +0100 (CET)

> I can't find the discussion about element restrictions.

My bad, it's at the top of this thread actually!

Kristian

> iEYEARECAAYFAkth7dwACgkQTuwUCDsYZdGIIQCfZQDbASgn8GRi2paqKnkH6E/i
> iLwAn0PLY8ruj7mgd/1K7G0tCGtJBEBj
> =OjEG

---

From: Kristian Oelgaard <[email-masked]>
Date: Thu, 28 Jan 2010 21:57:22 +0100 (CET)

> I should probably be 'FacetRestriction'.

No, because we can restrict elements to Cell, Measure and possibly SubDomain.

Kristian

---

From: "Garth N. Wells" <[email-masked]>
Date: Thu, 28 Jan 2010 21:12:56 +0000

> No, because we can restrict elements to Cell, Measure and possibly

'Can' or 'would like to'? ;)

Garth

---

From: Kristian Oelgaard <[email-masked]>
Date: Thu, 28 Jan 2010 22:22:41 +0100 (CET)

> 'Can' or 'would like to'? ;)

OK, so it is 'could' in the old FFC for restrictions onto facets and to Measure (the *dc that Mehdi uses), the sub-domains business is easy to switch on i UFL, but harder to implement in FFC and it is currently unsupported in both old and new FFC. And it wouldn't like to be able to restrict elements to SubDomains and the moment :)

Kristian

---

From: Marie Rognes <[email-masked]>
Date: Thu, 28 Jan 2010 22:24:15 +0100

Kristian Oelgaard wrote:
> OK, so it is 'could' in the old FFC for restrictions onto facets and 
> to Measure (the *dc that Mehdi uses), the sub-domains business is easy 
> to switch on i UFL, but harder to implement in FFC and it is currently 
> unsupported in both old and new FFC. And it wouldn't like to be able 
> to restrict elements to SubDomains and the moment :)
>

Could somebody fill me in on precisely what the

    "Restrictions to Measure"

and

    "Restrictions to SubDomains"

mean?

(Math wanted ;) )

--
Marie