Subject: [Syfi-dev] [HG syfi] Beginning of boundary integration.

From: [email-masked] (SyFi)
Date: Mon, 22 Jan 2007 21:35:29 +0100 (CET)

One or more new changesets pushed to the primary SyFi repository.
A short summary of the last three changesets is included below.

changeset:   317:90882b5c2304348be81493cd8d6b5733a44457cb
tag:         tip
user:        "Martin Sandve Alnæs <[email-masked]>"
date:        Mon Jan 22 21:35:02 2007 +0100
files:       python/ufccodegen/form.py
description:
Beginning of boundary integration.

changeset:   316:28894334a718eb34ce104345a6c31d498d62ba09
parent:      315:ad03348a18c8a8d9d7e839202b256be9429ccee3
parent:      314:6121ecafe0787c619045ed313101047614a90217
user:        "Kent-Andre Mardal <[email-masked]>"
date:        Mon Jan 22 20:41:35 2007 +0100
files:       
description:
merge

changeset:   315:ad03348a18c8a8d9d7e839202b256be9429ccee3
parent:      311:eda4d4bf4f8c5d725407cd9dfd2bb6e24b905fe2
user:        "Kent-Andre Mardal <[email-masked]>"
date:        Mon Jan 22 20:41:05 2007 +0100
files:       syfi/Polygon.cpp syfi/ginac_tools.cpp
description:
fixed numbering in bernsteinv, polv, homogenous_polv,

----------------------------------------------------------------------
For more details, visit http://www.fenics.org/hg/syfi

---

From: Kent-Andre Mardal <[email-masked]>
Date: Tue, 23 Jan 2007 10:43:23 +0100

Should we decide on a numbering scheme for faces and edges in SyFi
before doing this ? We could adopt the scheme used in Dolfin. 

man, 22,.01.2007 kl. 21.35 +0100, skrev SyFi:
> _______________________________________________
> SyFi-dev mailing list
> [email-masked]
> http://fenics.org/mailman/listinfo/syfi-dev

---

From: "Martin Sandve Alnæs" <[email-masked]>
Date: Tue, 23 Jan 2007 10:49:00 +0100

If you just implement the numbering scheme, it is no problem for me to
update the ufccodegen code afterwards. There is a renumbering in your
code which I copied, it is just a matter of deleting those few lines
really. Just tell me when it's done.

martin

---

From: Anders Logg <[email-masked]>
Date: Tue, 23 Jan 2007 11:05:38 +0100

I'm about to write something down for FFC/DOLFIN. My idea is that the
numbering scheme is the UFC numbering scheme + something else.

The UFC numbering is only concerned with the numbering of mesh
entitites with respect to a cell, based on the vertices of the cell.

My suggestion is that the numbering is based on a lexicographical
ordering of entities and that the vertices of the cell are ordered
lexicographically based on their global index.

Here's an example.

    Triangle with vertices v0 = 10, v1 = 15, v2 = 95

    Cell-edge:  e0 non-incident to v0
                e1 non-incident to v1
                e2 non-incident to v2

    (This is based on a lexicographical ordering of non-incident
     vertices as in the UFC manual.)

    Edge-vertex: e0 = (v1, v2)
                 e1 = (v0, v2) 
                 e2 = (v0, v1)

    (This is based on a lexicographical ordering of the entities
     within the entity (edge) in question.)

So there are two steps: First number all entities based on a
lexicographical ordering as in the UFC manual, then number everything
else based on the global index.

UFC is only concerned with the first step.

We also need to define something we can call "alignment", which is how
two cells meet at a common facet. For two triangles, the alignment is
0 or 1. For two tetrahedra, the alignment is 0, 1, 2, 3, 4 or 5.
This can also be based on a lexicographical ordering of matching
vertices.

The text in the UFC manual is written so that it can be copied to
other manuals (SyFi, DOLFIN, FFC) and extended.

The DOLFIN mesh library should be updated so that each DOLFIN mesh
follows this numbering convention.

/Anders

---

From: Robert Cimrman <[email-masked]>
Date: Tue, 23 Jan 2007 12:10:35 +0100

> This can also be based on a lexicographical ordering of matching

Hi,

I have installed SyFi with the aim to integrate it with my
NumPy/SciPy-based Python FE code (just released at
http://ui505p06-mbs.ntc.zcu.cz/sfe), so I am silently watching this
list. Now I have hijacked your discussion because I have implemented
this alignment (called orientation) in C, based on lexicographical
naming, too, albeit for edges only (0 or 1).
In 3D I have not needed more than P2 elements (edge nodes only), so I
avoided the thing, as it was getting complicated (tetra- and hexa-edra
together, wedge elements, pyramides...). Are you going to consider also
those mixed element type meshes? Do you allow degenerated elements? I
would like to have this finally in my code. (I silently assume you need
the alignment to be able to assign global numbers to the extra element
nodes, that are not present in the underlying mesh. If this was not the
case, ignore the message, please.)

best regards,
Robert Cimrman

---

From: Kent-Andre Mardal <[email-masked]>
Date: Wed, 24 Jan 2007 09:15:12 +0100

>      within the entity (edge) in question.)

I think we will go for this ordering. 

> This can also be based on a lexicographical ordering of matching

We might need this also. But up until now we have tried an alternative 
approach in which we defined the global facet as a ordered sequence 
of the vertices on facet. 

> follows this numbering convention.

Good. 

Kent

---

From: Kent-Andre Mardal <[email-masked]>
Date: Wed, 24 Jan 2007 09:23:36 +0100

tir, 23,.01.2007 kl. 12.10 +0100, skrev Robert Cimrman:
> those mixed element type meshes? 

I have not thought about it. What is the advantage with these polygons? 

> Do you allow degenerated elements? 

What are degenerated elements  ? Do they have very large aspect ratio or
are they degenerated in some other way ? 

> I

We have our own dof-handler, so we can handle dofs that are not present
in the mesh. In fact, we have a very general dof-handler so I think we
can handle just about any dof ( The dof-handler is templated in
terms of the dof and a comparison function for the dof.)

Kent