Topic: Is there any point to ProblemCommMode?

There is currently two possible values for ProblemCommMode in oofem, node-cut and element-cut partitioning.
Is there any reason to point these out? If we mark each node as local/shared/remote and each element as local/shared/remote, then isn't that enough information? In fact, the domain could just as well be node-cut in some places, and element-cut in others.
The flag indicating node-cut or element-cut doesn't contribute any new information.
And, the code that checks ProblemCommMode only ever supports the node-cut value anyway.

In fact, the "Element_shared", and even the "DofManager_shared" would both be redundant. There will always need to be one CPU-core that "owns" the element/node, so all DofManagers are always either local, or remote.
When passing information between processes, the partition list should be used to determine if a local value should be passed to another core (just like for elements).

Without Element_shared (which is currently not implemented), then element-cut problemcommmode surely can't work either.
I suggest we remove ProblemCommMode, Element_shared, and DofManager_shared.
Instead we just always refer to local (as in, the CPU owns "owns" that component), remote, null, and the partition list (This is what we do for elements right now, which are only local or remote, but can have a nonempty partition list).
To begin with, ProblemCommMode can at least be eliminated, as the code already should rely on shared/local nodes/elements already, rather than assuming anything based on a node-cut, element-cut principle.

2

Re: Is there any point to ProblemCommMode?

I have no objection to this and agree.
Borek