On 3 Mar 2014, at 12:09, Martin Sandve Alnæs <[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]> 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. > > -- > Anders > > > On Sat, Mar 01, 2014 at 11:20:21AM -0600, Douglas N Arnold wrote: > > I think we should not insist on too rigorous a correspondence > > between the names we use in the periodic table and the UFL element > > names, since the needs are different. The former are intended to > > make an accurate and visually appealing poster, and possibly to have > > some unifying effect on usage by researchers, while UFL has many > > other needs. > > > > Specifically, in my comment of 27 February at > > > > https://bitbucket.org/fenics-project/ufl/pull-request/7/introduce-notation-for-the-periodic-table/diff > > > > I included an image showing how the names will look in the periodic > > table (including subscripts) and then a possible pure text version > > that could be used in UFL. Based on the discussion so far, I would > > stick with the image for the poster, but appreciate that the > > developers may need to make changes to the UFL version (two such > > having been mentioned so far: changing dP to DP to avoid possible > > confusion, and removing the c from BDMce to avoid redundancy with > > the specification of the cell type, etc.). Hopefully the > > differences can be made consistently. E.g., if you remove the "c" > > (meaning "cubic variant") from BDM and RT, it should alo be removed > > from the Nedelec cubical elements and dPc. > > > > -- Doug > > > > On 02/28/2014 04:30 AM, Anders Logg wrote: > > >On Fri, Feb 28, 2014 at 10:55:05AM +0100, Marie E. Rognes wrote: > > >>On 02/28/2014 09:41 AM, Anders Logg wrote: > > >>>Other opinions? > > >> > > >>Would you consider dropping the c (or q/C/Q) for the BDMs/RTs on > > >>cubes? In the UFL FiniteElement constructor, the cell is given > > >>separately, so there is no need for the family name to indicate > > >>this. Advantages would be: simpler names and greater possibility of > > >>code independence wrt cell type. > > > > > >That would also be consistent with the use of P for both triangles and > > >tetrahedra. > > > > > _______________________________________________ > > fenics mailing list > > [email protected] > > http://fenicsproject.org/mailman/listinfo/fenics > _______________________________________________ > fenics mailing list > [email protected] > http://fenicsproject.org/mailman/listinfo/fenics > > _______________________________________________ > fenics mailing list > [email protected] > http://fenicsproject.org/mailman/listinfo/fenics _______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
