## Code review #67

### Dofmap ordering

Status: | Closed | Start date: | 04/09/2013 | |
---|---|---|---|---|

Priority: | Immediate | Due date: | ||

Assignee: | Johan Jansson | % Done: | 0% | |

Category: | - | |||

Target version: | - |

**Description**

Doesn't this change the order of the tabulated dofs?

Most if not all of our stabilization code assumes that a cell's dofs are of the form [x_0 x_1 x_2 x_3 , y_0 y_1 y_2 y_3 , z_0 z_1 z_2 z_3]

### History

#### #1 Updated by Niclas Jansson over 4 years ago

**Assignee**set to*Johan Jansson***Priority**changed from*Normal*to*Immediate*

#### #2 Updated by Johan Jansson over 4 years ago

No, that commit (45c764f9) actually changes the dofmap back to be compatible with the original dofmap. Here's the explanation:

Originally (commit 78b125e for example) the dofmap looked like:

`uint gdim = ufc_dof_map->geometric_dimension();`

uint num_entities = c.numEntities(0);

dolfin_assert(gdim * num_entities == local_dimension());

for (uint k = 0; k < gdim; k++)

for (uint i = 0; i < num_entities; i++)

dofs[i + k * (gdim + 1)] = v_map[c.entities(0)[i]] + k;

I've now updated it to look like:

`uint gdim = ufc_dof_map->num_sub_dof_maps();`

uint num_entities = c.numEntities(0);

dolfin_assert(gdim * num_entities == local_dimension());

for (uint k = 0; k < gdim; k++)

for (uint i = 0; i < num_entities; i++)
{

dofs[i + k * (num_entities)] = v_map[c.entities(0)[i]] + k;

}

(gdim + 1) -> (num_entities) is just a fix (note that they evaluate to the same thing), and the geometric_dimension() -> num_sub_dof_maps() is the generalization to systems with arbitrary number of components.

I made an intermediate commit (3811d33) which used a dofmap which is incompatible with the assumption we use now, as you say, but this was fixed just two commits after (45c764f).

So the order of the dofs has not changed (2-component systems in 2D and 3-component systems in 3D have exactly the same dofmap as before), but now the dofmap supports systems with arbitrary number of components.

#### #3 Updated by Niclas Jansson over 4 years ago

**Status**changed from*New*to*Closed*

Johan Jansson wrote:

No, that commit (45c764f9) actually changes the dofmap back to be compatible with the original dofmap. Here's the explanation:

Originally (commit 78b125e for example) the dofmap looked like:

uint gdim = ufc_dof_map->geometric_dimension();

uint num_entities = c.numEntities(0);

dolfin_assert(gdim * num_entities == local_dimension());

for (uint k = 0; k < gdim; k++)

for (uint i = 0; i < num_entities; i++)

dofs[i + k * (gdim + 1)] = v_map[c.entities(0)[i]] + k;I've now updated it to look like:

uint gdim = ufc_dof_map->num_sub_dof_maps();

uint num_entities = c.numEntities(0);

dolfin_assert(gdim * num_entities == local_dimension());

for (uint k = 0; k < gdim; k++)

for (uint i = 0; i < num_entities; i++) {

dofs[i + k * (num_entities)] = v_map[c.entities(0)[i]] + k;

}(gdim + 1) -> (num_entities) is just a fix (note that they evaluate to the same thing), and the geometric_dimension() -> num_sub_dof_maps() is the generalization to systems with arbitrary number of components.

I made an intermediate commit (3811d33) which used a dofmap which is incompatible with the assumption we use now, as you say, but this was fixed just two commits after (45c764f).

So the order of the dofs has not changed (2-component systems in 2D and 3-component systems in 3D have exactly the same dofmap as before), but now the dofmap supports systems with arbitrary number of components.

Ok great! Thanks for clarifying things.

#### #4 Updated by Niclas Jansson over 4 years ago

**Tracker**changed from*Bug*to*Code review*