In an attempt to summarize the opinions, I think we have landed at this:
* Two options: either mixed case or uppercase
Option (1)
P dP
P RTe/RTf dP
P N1e N1f dP
Option (2)
P DP
P RTE/RTF DP
P N1E N1F DP
In favor of (1): DNA
In favor of (2): MSA, (AL)
Option (1) has the advantage that it matches the names in the table.
Option (2) has the advantage of being all uppercase.
More votes?
* Adding aliases for convenience. I have absolutely no problem with
adding aliases in general, but suggest we wait and discuss each
suggested alias whenever it is proposed (later).
--
Anders
On Mon, Mar 03, 2014 at 09:23:42AM -0600, Douglas N Arnold wrote:
> Anders wrote:
> > I would like the names to be as consistent with the poster as
> > possible. After all, we are printing the UFL names in the poster next
> > to the element names.
> >
> > I see two options:
> >
> > 1. Either we keep the UFL names as suggested:
> >
> > P dP
> > P RTe/RTf dP
> > P N1e N1f dP
> > ...
> >
> > 2. Or, as suggested but all uppercase:
> >
> > P DP
> > P RTE/RTF DP
> > P N1E N1F DP
> > ...
> > I think I would vote for the second option.
>
> I tend not to agree. If we have a notation that
> uses subscripts and mixed case for the poster but
> FEniCS translates that algorithmically by switching
> everything to upper case and moving the scripts
> to the line, it does not seem like a problem to me.
> But I don't feel very strongly, and can't really
> tell how it would affect the look of the poster without
> seeing the alternatives.
>
> Also, how do you propose to handle elements like
> RTCE and DPC in UFL? Will it be ('DPC', quadrilateral, deg)
> or ('DP', quadrilateral, deg) with the understanding that
> the quadrilateral implies the C, since C means the cubical
> variant. I prefer the latter. Insisting on typing the
> C when it adds no meaning, doesn't seem right. Another possibility
> is to make the DPC the basic name, but allow just DP,
> which is unambiguous, as an alias. But I don't think
> the unambiguous ('DP', quadrilateral, deg) should lead to an error.
>
> One more issue of this sort: Is 'RT' going to be acceptable
> as an alias for 'RTF', or will the user
> be responsible for specifying RTF or RTE? ('BDM' should
> then be treated consistently, and it should work the same
> on simplices and cubes.)
>
> Martin wrote:
> > I was a bit quick there, the two names Q/S do of course carry
> > information beyond the cell being different from the P cases. Can we
> > perhaps make an alias Lagrange -> P/Q (DP/DQ for degree 0)?
>
> Not only do Q and S spaces both use the same cell (cubes),
> but P can be used on cubes as well (though not for continuous spaces).
> For example, in the famous Q2-P1 Stokes element P1 (discontinuous)
> is used for the pressure on cubes.
>
> The notion of Lagrange elements is not completely standard. 1. Some
> people call a Lagrange element any element for which all the DOFs
> are nodal values (e.g., I just saw that in the book of Bernardi,
> Maday and Rapetti). 2. Some people call the continuous P_r family
> on simplices (r=1, 2, ...) the Lagrange finite elements. I think
> this is most common. 3. Some people also throw in
> discontinuous P_0. Perhaps convenient, but it is somewhat illogical
> and leads to a lot of exceptions. E.g., "the Lagrange finite
> element spaces belong to H^1, except for r=0", "the Lagrange finite
> elements have one DOF at each vertex, except for r=0", "the
> barycentric coordinates of the nodes for a Lagrange finite element
> are of the form j/r, except for r=0...", etc. I'm don't think that we
> should encourage this. It would be analogous to declaring
> that RT0 is the space of DG0 vectors. No good reason to do
> that except that there is no RT0 element so the name is
> available. 4. Some people use Lagrange elements
> for continuous P_r on simplices and continuous Q_r elements on
> cubes. I don't see a problem with this. In this view, there are
> simplicial Lagrange elements and cubic Lagrange elements,
> just like there are simplicial RT elements and cubic RT elements.
>
> So I guess my vote is Lagrange is an alias for P/Q, but I would
> tend to discourage it going to DP/DQ for r=0.
>
> - DNA
>
> On 03/03/2014 07:23 AM, Martin Sandve Alnæs wrote:
> >I was a bit quick there, the two names Q/S do of course carry
> >information beyond the cell being different from the P cases. Can we
> >perhaps make an alias Lagrange -> P/Q (DP/DQ for degree 0)?
> >
> >
> >A couple of UFL implementation sidenotes:
> >
> >All aliases should be applied in UFL just as we do today with short/long
> >names, not in the form compiler, otherwise the form signatures will
> >differ depending on what names you use.
> >
> >If we deprecate (some of) the old names, the deprecation period should
> >be long because this touches a lot of code and keeping old aliases does
> >not carry any real cost to code maintenance.
> >
> >Martin
> >
> >
> >On 3 March 2014 12:04, Anders Logg <[email protected]
> ><mailto:[email protected]>> wrote:
> >
> > Both these options could be handled:
> >
> > - Allow r = 0 for P elements and handle the switch from continuous to
> > discontinuous inside the form compiler, which will anyway need a lot
> > of if-else checking since many of the names are different in FIAT.
> >
> > - Introduce shortcuts in some cases, but note that both the "Q" elements
> > and the "S" elements are essentially different from the "P" elements
> > so it doesn't make sense that "P" should work for all of them. In the
> > case of discontinuous elements, we would need to introduce an alias
> > for "DP" --> "DPC".
> >
> >
> >
> > On Mon, Mar 03, 2014 at 12:30:50PM +0100, Garth N. Wells wrote:
> > >
> > > On 3 Mar 2014, at 12:09, Martin Sandve Alnæs <[email protected]
> > <mailto:[email protected]>> wrote:
> > >
> > > > I prefer the second option here over the first.
> > > >
> > > > But I don't like not being able to switch between (continuous)
> > piecewise linear and piecewise constant elements with just the
> > degree. There's a lot of code snippets a'la 'family = lamda degree:
> > "DG" if degree == 0 else "CG"' around in user code.
> > > >
> > >
> > > Agree. This can be annoying.
> > >
> > > > For similar reasons, I don't like having to select e.g. P,Q,S
> > depending on the cell type, when we already have the cell type
> > specified otherwise. That will make writing mesh-type independent
> > code more difficult when we get support for quads.
> > > >
> > >
> > > Agree.
> > >
> > > Garth
> > >
> > > > I'm pretty sure a family alias which maps to P/Q/S depending on
> > the cell for degree>0 and DP/DQ/DS for degree==0 would quickly
> > become the most popular one.
> > > >
> > > > Martin
> > > >
> > > >
> > > > On 3 March 2014 09:47, Anders Logg <[email protected]
> > <mailto:[email protected]>> wrote:
> > > > I would like the names to be as consistent with the poster as
> > > > possible. After all, we are printing the UFL names in the
> > poster next
> > > > to the element names.
> > > >
> > > > I see two options:
> > > >
> > > > 1. Either we keep the UFL names as suggested:
> > > >
> > > > P dP
> > > > P RTe/RTf dP
> > > > P N1e N1f dP
> > > >
> > > > P dP
> > > > P BDMe/BDMf dP
> > > > P N2e N2f dP
> > > >
> > > > Q dQ
> > > > Q RTce/RTcf dQ
> > > > Q Nce Ncf dQ
> > > >
> > > > S dPc
> > > > S BDMce/BDMcf dPc
> > > > S AAe AAf dPc
> > > >
> > > > 2. Or, as suggested but all uppercase:
> > > >
> > > > P DP
> > > > P RTE/RTF DP
> > > > P N1E N1F DP
> > > >
> > > > P DP
> > > > P BDME/BDMF DP
> > > > P N2E N2F DP
> > > >
> > > > Q DQ
> > > > Q RTCE/RTCF DQ
> > > > Q NCE NCF DQ
> > > >
> > > > S DPC
> > > > S BDMCE/BDMCF DPC
> > > > S AAE AAF DPC
> > > >
> > > > I think I would vote for the second option.
> > > >
> > >
> >
> >
_______________________________________________
fenics mailing list
[email protected]
http://fenicsproject.org/mailman/listinfo/fenics
