[Core] Add EffectiveEquationId to dof.h

[rubenzorrilla]

📝 Description
As agreed, this adds the EffectiveEquationId to the DOF. Tests and Python exposure have been added accordingly.

[loumalouomega]

Can you explain me the pourpose of this?, I tought we wanted to make the dof lighter, not heavier

[pooyan-dadvand]

We don't need to reduce this one unless if we want to use the remaining 16bits for something else

So keep in mind that we have now 16 bits to be used

[rubenzorrilla]

I just wanted to keep it consistent with the standard equation id as I expect these to be of the same order of magnitude. However, maybe we can simply keep the 64 bit and end of the story (rather than leaving the 16, possible unused, ones at limbo).

You've much more expertise than me on this so I'll be fine with whatever you consider in this regard.

[RiccardoRossi]

translating, take out the ": 48" :-D

[rubenzorrilla]

Removed.

[rubenzorrilla]

Can you explain me the pourpose of this?, I tought we wanted to make the dof lighter, not heavier

It is required to properly implement the constraints. Equation ids and "effective" equation ids might not coincide if there are DOFs not associated to elements/conditions (e.g., node tying constraints).

[loumalouomega]

Can you explain me the pourpose of this?, I tought we wanted to make the dof lighter, not heavier

It is required to properly implement the constraints. Equation ids and "effective" equation ids might not coincide if there are DOFs not associated to elements/conditions (e.g., node tying constraints).

A priori we solved this in the block builder and solver, can you explain me an example?

[rubenzorrilla]

Can you explain me the pourpose of this?, I tought we wanted to make the dof lighter, not heavier

It is required to properly implement the constraints. Equation ids and "effective" equation ids might not coincide if there are DOFs not associated to elements/conditions (e.g., node tying constraints).

A priori we solved this in the block builder and solver, can you explain me an example?

It is not. Actually is even more complicated, as you have to also perform the update over those "loose" DOFs, something that it definitively not done in current implementation.

Take this two element mesh: 1 -- 2 -- 3. Now imagine that we have a "flying" DOF 4 and that we want u_3 = u_4, with u_4 possibly being a Dirichlet condition. In this case the standard equation ids will be 1,2 and 3 for nodes 1,2,3 and nothing for node 4. Effective equation ids in this case will be 1,2 for nodes 1 and 2 and 3 for node 4. We will have no effective equation id for node 3 as this is never solved.

[rubenzorrilla]

@loumalouomega BTW, ContactStructuralMechanics failed in Windows 🤷‍♂️

[loumalouomega]

@loumalouomega BTW, ContactStructuralMechanics failed in Windows 🤷‍♂️

Yes, an elimination test... I hope not, but if true could be a memory issue

[RiccardoRossi]

to chime in, honestly i do not think the current solution is viable in a truly generic case...

we have a solution that uses a map, but adding an effective_equation_ids would be a much cleaner solution, which is why @pooyan-dadvand suggested it.

[sunethwarna]

Doesn't this confuse the user? What is the difference between EquationId and EffectiveEquationId? And I did not understand the use case as well. Could you elaborate little bit?

Take this two element mesh: 1 -- 2 -- 3. Now imagine that we have a "flying" DOF 4 and that we want u_3 = u_4, with u_4 possibly being a Dirichlet condition. In this case the standard equation ids will be 1,2 and 3 for nodes 1,2,3 and nothing for node 4. Effective equation ids in this case will be 1,2 for nodes 1 and 2 and 3 for node 4. We will have no effective equation id for node 3 as this is never solved.

Why don't you add this additional node to the mesh as well, and then tie it with a constraint. Thats what we do rather than complicating the interfaces?

[rubenzorrilla]

Doesn't this confuse the user? What is the difference between EquationId and EffectiveEquationId? And I did not understand the use case as well. Could you elaborate little bit?

Take this two element mesh: 1 -- 2 -- 3. Now imagine that we have a "flying" DOF 4 and that we want u_3 = u_4, with u_4 possibly being a Dirichlet condition. In this case the standard equation ids will be 1,2 and 3 for nodes 1,2,3 and nothing for node 4. Effective equation ids in this case will be 1,2 for nodes 1 and 2 and 3 for node 4. We will have no effective equation id for node 3 as this is never solved.

Why don't you add this additional node to the mesh as well, and then tie it with a constraint. Thats what we do rather than complicating the interfaces?

The node is in the mesh and tied with a constraint so this is not the issue. EquationIds are the ones we had so far, that is, the element/condition DOFs and then numbered consecutively. EffectiveEquationIds are the ones of the system you actually solve (i.e., there are no slave DOFs). It is important to note that the effective might involve DOFs not associated to any element/condition (i.e., "flying" DOFs) if there are special constraints.

You need both of them, the effective to apply the actual BCs of the system and the "standard" one to do the update of the "non-effective" DOFs. In this regard I also note that you also need to update the loose DOFs, something that also requires its effective DOF equation id.

EDIT: I cannot longer see your comment about decoupling the nodes and the DOFs, but as I said, this has nothing to do with the nodes. That won't solve the problem for sure.

EDIT2: If you find EffectiveEquationId misleading, I'm open to suggestions about the naming.

[loumalouomega]

Doesn't this confuse the user? What is the difference between EquationId and EffectiveEquationId? And I did not understand the use case as well. Could you elaborate little bit?

Take this two element mesh: 1 -- 2 -- 3. Now imagine that we have a "flying" DOF 4 and that we want u_3 = u_4, with u_4 possibly being a Dirichlet condition. In this case the standard equation ids will be 1,2 and 3 for nodes 1,2,3 and nothing for node 4. Effective equation ids in this case will be 1,2 for nodes 1 and 2 and 3 for node 4. We will have no effective equation id for node 3 as this is never solved.

Why don't you add this additional node to the mesh as well, and then tie it with a constraint. Thats what we do rather than complicating the interfaces?

The node is in the mesh and tied with a constraint so this is not the issue. EquationIds are the ones we had so far, that is, the element/condition DOFs and then numbered consecutively. EffectiveEquationIds are the ones of the system you actually solve (i.e., there are no slave DOFs). It is important to note that the effective might involve DOFs not associated to any element/condition (i.e., "flying" DOFs) if there are special constraints.

You need both of them, the effective to apply the actual BCs of the system and the "standard" one to do the update of the "non-effective" DOFs. In this regard I also note that you also need to update the loose DOFs, something that also requires its effective DOF equation id.

EDIT: I cannot longer see your comment about decoupling the nodes and the DOFs, but as I said, this has nothing to do with the nodes. That won't solve the problem for sure.

EDIT2: If you find EffectiveEquationId misleading, I'm open to suggestions about the naming.

But this is fixed in the current B&S just iterating over the constraints and adding the missing dofs even if those dofs are not part of any element nor condition. i still do not understand which is the issue. Can you provide a test that is failing with current implementation?

[rubenzorrilla]

I

Doesn't this confuse the user? What is the difference between EquationId and EffectiveEquationId? And I did not understand the use case as well. Could you elaborate little bit?

Take this two element mesh: 1 -- 2 -- 3. Now imagine that we have a "flying" DOF 4 and that we want u_3 = u_4, with u_4 possibly being a Dirichlet condition. In this case the standard equation ids will be 1,2 and 3 for nodes 1,2,3 and nothing for node 4. Effective equation ids in this case will be 1,2 for nodes 1 and 2 and 3 for node 4. We will have no effective equation id for node 3 as this is never solved.

Why don't you add this additional node to the mesh as well, and then tie it with a constraint. Thats what we do rather than complicating the interfaces?

The node is in the mesh and tied with a constraint so this is not the issue. EquationIds are the ones we had so far, that is, the element/condition DOFs and then numbered consecutively. EffectiveEquationIds are the ones of the system you actually solve (i.e., there are no slave DOFs). It is important to note that the effective might involve DOFs not associated to any element/condition (i.e., "flying" DOFs) if there are special constraints.
You need both of them, the effective to apply the actual BCs of the system and the "standard" one to do the update of the "non-effective" DOFs. In this regard I also note that you also need to update the loose DOFs, something that also requires its effective DOF equation id.
EDIT: I cannot longer see your comment about decoupling the nodes and the DOFs, but as I said, this has nothing to do with the nodes. That won't solve the problem for sure.
EDIT2: If you find EffectiveEquationId misleading, I'm open to suggestions about the naming.

But this is fixed in the current B&S just iterating over the constraints and adding the missing dofs even if those dofs are not part of any element nor condition. i still do not understand which is the issue. Can you provide a test that is failing with current implementation?

Current B&S includes both block and elimination builds?

[loumalouomega]

I

Doesn't this confuse the user? What is the difference between EquationId and EffectiveEquationId? And I did not understand the use case as well. Could you elaborate little bit?

Take this two element mesh: 1 -- 2 -- 3. Now imagine that we have a "flying" DOF 4 and that we want u_3 = u_4, with u_4 possibly being a Dirichlet condition. In this case the standard equation ids will be 1,2 and 3 for nodes 1,2,3 and nothing for node 4. Effective equation ids in this case will be 1,2 for nodes 1 and 2 and 3 for node 4. We will have no effective equation id for node 3 as this is never solved.

Why don't you add this additional node to the mesh as well, and then tie it with a constraint. Thats what we do rather than complicating the interfaces?

The node is in the mesh and tied with a constraint so this is not the issue. EquationIds are the ones we had so far, that is, the element/condition DOFs and then numbered consecutively. EffectiveEquationIds are the ones of the system you actually solve (i.e., there are no slave DOFs). It is important to note that the effective might involve DOFs not associated to any element/condition (i.e., "flying" DOFs) if there are special constraints.
You need both of them, the effective to apply the actual BCs of the system and the "standard" one to do the update of the "non-effective" DOFs. In this regard I also note that you also need to update the loose DOFs, something that also requires its effective DOF equation id.
EDIT: I cannot longer see your comment about decoupling the nodes and the DOFs, but as I said, this has nothing to do with the nodes. That won't solve the problem for sure.
EDIT2: If you find EffectiveEquationId misleading, I'm open to suggestions about the naming.

But this is fixed in the current B&S just iterating over the constraints and adding the missing dofs even if those dofs are not part of any element nor condition. i still do not understand which is the issue. Can you provide a test that is failing with current implementation?

Current B&S includes both block and elimination builds?

I don't remember right now, but can be done as well for the elimination with the same strategy.

[pooyan-dadvand]

I think having the effective ID in the dof is a clean solution and also reduces the memory usage! Let me explain:

The other way of doing this as @RiccardoRossi explained is to maintain a dictionary of dofs with ids in the reduced matrix which needs more memory and will store the same ids in a different place with the overhead of the searching.

On the other hand the memory usage of this over dofs is low (8MB for 1M dofs) so I would go with this solution

[loumalouomega]

I updated to fix Windows CI