Fem: Add constraint rigid body

[marioalexis84]

This pull request continues #7716.

@FEA-eng I have modified the properties to support load and boundary conditions. Free*Mode are intended to leave degrees of freedom.
The task dialog still needs work, but it already exposes all the properties.
The writer is not yet updated to use the new properties. It's pending work.
Note that the Moment unit did not have the correct signature. Now it is corrected. The problem is the collision with the work unit. That's why you see electronvolt as unit for low values. We still have to think about how to solve this, also, in the property editors there is a problem with the unit parser for cases that involve * like N*m, so I commented out the lines in the UnitSchema* files.

[FEA-eng]

Great. I already compiled it. As you said, the writer doesn't work yet so I can't check what actually goes to the input file and thus I have some questions about the new task dialog:

1 - those fields are just for the direction vectors for force, moment and rotation, right?
2 - then those are for the value in the chosen direction? So if I enter 1 in X within Force on Reference Node and then enter the Force (currently in mN) below, this force will be applied in the X direction? So it's not possible to e.g. enter different forces in 2 or 3 directions at once? Why isn't the same approach used for the Displacement on Reference Node?
3 - this is ok but wouldn't it be better to add checkboxes (unchecked = free) to each displacement and rotation vector component like in the Displacement constraint?

4 - does this one choose which of the input fields (force/moment/displacement/rotation) actually go to the input file? Is it necessary? If all forces and moments are 0, there's no problem when they are added as such to the input file. Boundary conditions have their own settings for free and fixed. Even though filling all the input fields at once wouldn't make sense (loads and boundary conditions acting in the same DOFs), maybe we don't have to prevent it by adding more settings which have to be considered to make full use of the tool.

[marioalexis84]

1- The total force applied must be entered. This way, it is easier if we use some shape as a reference, just as used in force constraint (reference selection still needs to be implemented). Of course, there are cases where one approach is more convenient than the other. In any case we can implement the dialog to offer both modes: Force by cartesian component or force by magnitude and direction.
3- I implement this way to reduce the number of properties. But it can be replaced by checkbox.
4- This is added to avoid no sense entries. Of course, it could be the user's responsibility to use the appropriate inputs.

[FEA-eng]

1- The total force applied must be entered. This way, it is easier if we use some shape as a reference, just as used in force constraint (reference selection still needs to be implemented). Of course, there are cases where one approach is more convenient than the other. In any case we can implement the dialog to offer both modes: Force by cartesian component or force by magnitude and direction.

All right. Initially, I was thinking about an approach where each load/BC type has 3 inputs for vector components and that's it but indeed it can be done in other ways too and reference selection can help define forces at angles (the rest could use references too but it should be more convenient to keep the 3 components approach for moments and displacements/rotations).

3- I implement this way to reduce the number of properties. But it can be replaced by checkbox.

I think that checkboxes would be more intuitive.

4- This is added to avoid no sense entries. Of course, it could be the user's responsibility to use the appropriate inputs.

Generally speaking, I'm in favor of allowing all the combinations and making it the user's responsibility while also reducing the number of needed settings. Other preprocessors implement this constraint in such a way that a reference point is created and any load/BC can be applied to it. In FreeCAD this won't work since there's no moment load so we can use the current approach and just give full flexibility in input combinations. The user should know what each quantity means anyway.

Some smaller questions:

• is 180 the maximum possible angle?
• eV for moment indeed doesn't look good but I didn't know it's so tricky to correct this. What if we define a new unit which is not a multiplication of the existing force and distance units but rather a fixed symbol "Nm" or "Nmm"? This way it wouldn't be possible to convert between Nm, Nmm and other variants for low/high values but maybe such a workaround could make sense. If there's still a conflict with the existing N and m or mm symbols then a new "Newton-meter" unit should finally resolve it but it would be a last resort.

[marioalexis84]

@FEA-eng

[FEA-eng]

@marioalexis84 Awesome, it seems that it's all working now. Only the moment units are still eV. Anything else left? Do you plan the support for solids? I think that it could be even added later in a separate PR if it's not ready yet to make sure this is merged before the feature freeze.

Could the green sphere show the actual location of the reference point once it's specified? Do we keep the rotational BC definition the way it is - different than other loads/constraints (vector components and then a single value of the angle of rotation)?

[marioalexis84]

@FEA-eng:

• To Solve the moment unit problem we need to work on the FreeCAD unit system. This can be fixed later. In any case, the problem is more general than this use case.
• We can merge this as is and then add support for solids.
• Green sphere located according to the reference node.
• I prefer to keep the rotation boundary condition using a Rotation property for better interaction with other FreeCAD objects. For the other properties, I plan to add vectorial quantities with units for better support of forces, etc.

@chennes I don't know why the tests fail. In my system all FreeCAD test pass without failure.

[marioalexis84]

@FEA-eng Fixed conflict between node numbers for multiple constraints.

[FEA-eng]

Perfect, it all works well now and the tests passed. @chennes Can you merge it so that we can proceed to the final FEM polish before the freeze?

[marioalexis84]

@chennes
Note that to avoid the error in the test, in Unit::getTypeString() I moved the comparison with Unit::Moment to the last conditional. This avoids the conflict with Unit::Work. This doesn't solve anything, it's just a workaround to avoid the error.
I am working on a possible solution to support units with the same signature.