How to do with renumber! if I want to mix the dofs of different fields?

[zyhsjtu]

for the following codes,
grid = generate_grid(Triangle, (3, 3)); dh = DofHandler(grid); add!(dh, :u, 2); add!(dh, :p, 1); close!(dh);
the dofs range of :u field is 1 : 6 and the dofs range of :p field is 7 : 9
dof_range(dh, :u); dof_range(dh, :p);
I want the dofs range of :u field is [1,2,4,5,7,8] and and the dofs range of :p field is [3,6,9]. how should I do with the function renumber!

[KnutAM]

The renumber! function reorders the global degrees of freedom (changing the output of celldofs(dh, cellnr)[dof_range(dh, :u)]). This allows, e.g., organizing the global equation system into a block structure.
However, dof_range gives you the local (cell) degrees of freedom ranges for the different fields. This is not changed by reorder!. Out of curiousity, why would you like to reorder these?

[zyhsjtu]

@KnutAM Since the global degrees of freedom with order [u1x, u1y, p1, u2x, u2y, p2, . . . ,unx, uny, pn] is more faster than the order [u1x, u1y, u2x, u2y, . . . ,unx, uny,p1, p2, . . . , pn]. In Matab the former is about 2 times faster than the latter one.
soI wonder if there is a way to reorder the dofs as [u1x, u1y, p1, u2x, u2y, p2, . . . ,unx, uny, pn] ? Thanks.

The renumber! function reorders the global degrees of freedom (changing the output of celldofs(dh, cellnr)[dof_range(dh, :u)]). This allows, e.g., organizing the global equation system into a block structure. However, dof_range gives you the local (cell) degrees of freedom ranges for the different fields. This is not changed by reorder!. Out of curiousity, why would you like to reorder these?

[KnutAM]

Are you talking about the speed for the linear solve?

In that case, for the global dof vector you can renumber by calling renumber!(dh, [ch], perm) ref, but you would have to calculate perm yourself - this is not super-easy but if you have isoparametric elements (so that algebraic and geometric nodes match), I suppose you could get this reordering permuation by looking at the node-number.

If the benchmarks on such a "hack" can show that there is a potential for speed improvements, it could be worth implementing such a general method. If not, the Metis extension can improve the structure of the lu decomposition, not sure what speedups it gives. This requires using Metis, see docstring here for the metis renumbering

[zyhsjtu]

Yes, I agree that the reordering permuation implementation is really not super-easy. But I think reorder is worthing, beacuse the global order with [u1x, u1y, p1, u2x, u2y, p2, . . . ,unx, uny, pn] will affect the sparsity of the sparse matrix, that is, the bandwidth of the sparse matrix is smaller than the order [u1x, u1y, p1, u2x, u2y, p2, . . . ,unx, uny, pn].

Are you talking about the speed for the linear solve?

In that case, for the global dof vector you can renumber by calling renumber!(dh, [ch], perm) ref, but you would have to calculate perm yourself - this is not super-easy but if you have isoparametric elements (so that algebraic and geometric nodes match), I suppose you could get this reordering permuation by looking at the node-number.

If the benchmarks on such a "hack" can show that there is a potential for speed improvements, it could be worth implementing such a general method. If not, the Metis extension can improve the structure of the lu decomposition, not sure what speedups it gives. This requires using Metis, see docstring here for the metis renumbering

[KnutAM]

I cannot say I see way that ordering would be beneficial. But if you try, note that you must explicitly ask to remove some cross-field couplings when calling create_sparsity_pattern, to have any difference. Of course, assuming you have some missing cross-coupling. Without that, there should AFAIU be no difference in the sparsity pattern if ordered the standard way or according to your suggestion.

[KnutAM]

Re-reading this, just to clarify: The current numbering, [u1x, u1y, u2x, u2y, . . . ,unx, uny,p1, p2, . . . , pn] is added on a per-cell basis. To get this globally requires re-ordering with FieldWise, but is not default.

Without that, there should AFAIU be no difference in the sparsity pattern if ordered the standard way or according to your suggestion.

This comment was wrong, it will make some small differences!