search

UG4 / ugcore

The core functionality of UG4. Includes sources, build-scripts, and utility scripts.
https://github.com/UG4/ugcore
Other
36 stars 23 forks source link

OrderCuthillMcKee says "Do not use" #60

Closed bsumirak closed 2 years ago

bsumirak commented 2 years ago

Since 3d2fecbb14, the function OrderCuthillMcKee prints out a warning

!!!!!!!!!!! OrderCuthillMcKee: Do not use this function

on stderr. Why is that? Is there a problem with the implementation? Or is there a better way to accomplish the ordering? In that case, it would be nice to also give a pointer as to how this can be done.

LogashenkoDL commented 2 years ago

The message should be really corrected to a somehow more informative. And there is the UG_LOG macro, one should not use the direct output to stderr, this is true.

However, this is only a message. The functionality should not be changed. (However, this is not completely confirmed by the tests.) The implementation is currently incomplete, but in the future, the old ordering functions should be replaced.

First about the alternative: Yes, there is one. You can specify the ordering directly for the solver, cf. line 750 in solver_util.lua. But as I see, this is currently only done for the ilu and ilut methods. However, for them several different ordering strategies are provided. I hope, the work will be continued.

The main problem with the commands OrderCuthillMcKee, OrderLex, ... were that they worked on the ApproximationSpaces where only the indices are stored. GridFunctions were reodered, too, because they registered callbacks. However, normal algebra vectors and matrices have not been reordered. This lead to inconsistencies: For ex., if an object stores a vector, its contents is not reordered, but grid functions are reordered, so that the entries do not correspond to each other any more.

This issue was really essential for the parallelization. The matter is that the parallel layouts belong to the Algebra module and do not register any callbacks.

The issues did not appear if the ordering has been used only once in the script, namely directly after creating the grid and before any initializations of the solvers. But in more complicated scripts, these reorderings lead problems.

The idea was to move the ordering to the solvers.

To my mind, a reordering of the grid nodes should exist, too. But it should happen in the refiner (and when the grid is loaded). This should not be a separate routine.

LogashenkoDL commented 2 years ago

The message has been reformulated. It is printed now using UG_LOG and only once for ApproximationSpace (not for every DoFDistribution), i.e. once per the call of OrderCuthillMcKee in the script. Note that up to this message, the function works as before.

bsumirak commented 2 years ago

Thanks for your detailed answer.

The idea was to move the ordering to the solvers.

To my mind, a reordering of the grid nodes should exist, too. But it should happen in the refiner (and when the grid is loaded). This should not be a separate routine.

I tend to concur. It surely is useful to have a well-sorted approximation space right from the start. Otherwise (at least for problems where matrix entries can change), matrices will have to be re-sorted in every step, which is relatively costly.