# Ordering of mixed elements

**URL:** <https://fenicsproject.discourse.group/t/ordering-of-mixed-elements/946>\
**Category:** Uncategorized\
**Created:** [June 5, 2019, 2:27pm UTC](https://fenicsproject.discourse.group/t/ordering-of-mixed-elements/946 "2019-06-05T14:27:14Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![bcsj](https://yyz2.discourse-cdn.com/free1/user_avatar/fenicsproject.discourse.group/bcsj/32/253_2.png) [@bcsj](https://fenicsproject.discourse.group/u/bcsj)\
**Post date:** [June 5, 2019, 2:27pm UTC](https://fenicsproject.discourse.group/t/ordering-of-mixed-elements/946/1 "2019-06-05T14:27:14Z")

</div>

I have a code which builds a function space with mixed elements along the line of

```
E1 = FiniteElement('P', triangle, 1)
E0 = FiniteElement('R', triangle, 0)
V = FunctionSpace(mesh, MixedElement(E1,E0))

```

Later I access the vector for the solution of a problem on `V`.

Running this on different builds of FEniCS I have noticed that the value corresponding to the element `E0` isn’t always in the same position in the vector. On one build it is consistently the first element and on another build it is consistently the last element.

**Question** : Is there some setting I can check somewhere in DOLFIN which will tell me how the values corresponding to the elements become stacked in the vector?

_Probably related: Running `V.tabulate_dof_coordinates()` I notice the the node orderings are different on the different builds._

---

<div class="post-metadata">

**Author:** ![MiroK](https://yyz2.discourse-cdn.com/free1/user_avatar/fenicsproject.discourse.group/mirok/32/33_2.png) [@MiroK](https://fenicsproject.discourse.group/u/MiroK)\
**Post date:** [June 5, 2019, 4:54pm UTC](https://fenicsproject.discourse.group/t/ordering-of-mixed-elements/946/2 "2019-06-05T16:54:09Z")

</div>

Hi, consider the following

```python
from dolfin import (FunctionSpace, UnitSquareMesh, parameters,
                    FiniteElement, MixedElement, triangle)

# False - natural ordering; True - interlace
parameters['reorder_dofs_serial'] = False

mesh = UnitSquareMesh(32, 32)
V = FunctionSpace(mesh, MixedElement([FiniteElement('Lagrange', triangle, 1),
                                      FiniteElement('Raviart-Thomas', triangle, 1)]))

for i in range(V.num_sub_spaces()):
    print V.sub(i).dofmap().dofs()

```

---

<div class="post-metadata">

**Author:** ![bcsj](https://yyz2.discourse-cdn.com/free1/user_avatar/fenicsproject.discourse.group/bcsj/32/253_2.png) [@bcsj](https://fenicsproject.discourse.group/u/bcsj)\
**Post date:** [June 5, 2019, 5:30pm UTC](https://fenicsproject.discourse.group/t/ordering-of-mixed-elements/946/3 "2019-06-05T17:30:55Z")

</div>

Thanks a lot, that was quite useful. I will check if `V.sub(1).dofmap().dofs()[0] == 0` or `== N` to detect if the element from `FiniteElement('R',triangle,0)` ended up at one end or another of the vector.

Related question:

```
parameters['reorder_dofs_serial'] = False

```

Is interlaced more efficient than natural ordering somehow? Also, what does this setting mean when the grid is unstructured?

---

<div class="post-metadata">

**Author:** ![MiroK](https://yyz2.discourse-cdn.com/free1/user_avatar/fenicsproject.discourse.group/mirok/32/33_2.png) [@MiroK](https://fenicsproject.discourse.group/u/MiroK)\
**Post date:** [June 5, 2019, 7:14pm UTC](https://fenicsproject.discourse.group/t/ordering-of-mixed-elements/946/4 "2019-06-05T19:14:19Z")

</div>

I believe the rationale behind “not-natural” ordering is to cluster the nonzeros of the system matrix closer to the diagonal. This might help direct solvers, however, they likely have their own permutation algorithms which they employ regardless of the ordering of the matrix. Therefore the gains are hard to comment on.

For your second question, you should not assume anything special in the structured case. Ordering of the grid nodes and degrees of freedom is in general different. Observe that on 2d structured mesh the nodes are ordered e.g. in row major way while dofs (of P1) are not.