Code review #67

Dofmap ordering

Added by Niclas Jansson over 4 years ago. Updated over 4 years ago.

Status:ClosedStart date:04/09/2013
Priority:ImmediateDue 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

Also available in: Atom PDF