[WIP] Add springs to the bridge supports

Work in progress (WIP) pull request

Extension of the current FE model builder with the option to have springs at the bottom of piers and abutments. Motivation: it seems to be that the hinges at the bottom of the piers of bridge 705 are not working as perfect hinges neither perfectly fixed but something in between.This can be modeled by adding springs to the bottom of the supports. In order to see if the prediction accuracy could be improved by having rotational springs at the piers we need to enhance a bit the current FE model.

Current behavior

Boundary conditions at the bottom of piers and abutments: boolean, either fixed or free.

class Support:

    def __init__(
        self,
        x: float,
        z: float,
        length: float,
        height: float,
        width_top: float,
        width_bottom: float,
        materials: Union[List["MaterialSupport"], Callable[[float], "MaterialSupport"]],
        fix_x_translation: bool,
        fix_z_translation: bool,
        fix_y_translation: bool = True,
        fix_x_rotation: bool = False,
        fix_z_rotation: bool = False,
        fix_y_rotation: bool = False,
    ):

Desired behavior

Boundary conditions at the bottom of piers and abutments: float, spring stiffness.
Translational or rotational spring stiffness (stiffness) for each degree of freedom (dof) depending on the type of the dof.
stiffness_x_rotation = 0 is equivalent to fix_x_rotation = False
stiffness_x_rotation = float('inf') is equivalent to fix_x_rotation = True

This is a generalization of the existing code that can be achieved with minor edits to the existing code base and adding some new code. The current master state is a special case of the proposed generalization.

The support class could look like this:

class Support:

    def __init__(
        self,
        x: float,
        z: float,
        length: float,
        height: float,
        width_top: float,
        width_bottom: float,
        materials: Union[List["MaterialSupport"], Callable[[float], "MaterialSupport"]],
        stiffness_x_translation: float,
        stiffness_z_translation: float,
        stiffness_y_translation: float = float('inf'),
        stiffness_x_rotation: float = 0,
        stiffness_z_rotation: float = 0,
        stiffness_y_rotation: float = 0,
    ):

Implementation notes

OS zeroLength element can be used to model the springs.

I gave up trying to implement it, I do not have a good enough overview about how the code works and some parts are unintuitive to me, maybe because of my lack of overview/understanding of the code. I pushed my very much work-in-progress code to the branch of this pull request, jut in case if it can be of any use.

It turned out that the above code snippet example would not be logical, i.e. the boundary conditions should not be mixed with the support (pier) geometry.

On a higher level -- independently of the implementation -- it is simple what should be done:

user input
- the user can provide an optional input argument that is a vector of spring stiffness values (rotational spring stiffness is enough for now), for each pier group (6 elements). The stiffness value corresponds to the total stiffness of a pier, 1 out of the 4 piers in a pier group (there are 6 pier groups). The stiffness' support is [0, Inf].
- if the user does not provide the input then all rotational spring stiffness values can default to zero.
nodes
- create duplicate nodes of each bottom node of each pier, the springs will be placed between each node pair
materials
- create 6 uniaxialMaterials using the input from the user, parameter E should be determined based on the user provided stiffness value and the number of nodes at the bottom of a pier.
elements
- create one zeroLength` element between each node pair, use the earlier defined nodes and materials

Ideally to longitudinal (x) translational spring stiffness could be controlled the same way (it could use the same node pairs as the rotational).

@barischrooneyj class Support only for defining piers and not for abutments. It would be better if either it was renamed to Pier or InternalSupport, or even better if Support also supported abutment type of supports, e.g. by having 0 height it could work like the current abutment model. This is not urgent as for now it is sufficient to add the springs to the piers and leave the abutments as is. #174

Thanks for the PR! I think the code looks good. I will try get it running tomorrow, so I will possibly make a few changes to this branch, just so you are aware, then I'll hand it back to you.

Regarding the abutments and variable naming. I will rename the Support class to Pier and ignore abutments in this PR, that can come separately after this PR has been merged.

@rozsasarpi I want to clarify your request and then I think I can complete this:

The translational and rotational attributes of Support should now be in [0, inf] instead of a boolean.
Currently each of the bottom nodes N_i^p for some pier p have an associated fix command, so the code looks something like:

# node id X Y Z
node 862 89.625 -3.5 -4.838298
node 863 89.625 -3.5 -4.837807
node 864 89.625 -3.5 -4.740098
node 865 89.625 -3.5 -4.739607
node 866 89.625 -3.5 -3.556792
node 867 89.625 -3.5 -3.556301
node 868 89.625 -3.5 -3.3

fix 862 0 1 1 0 0 0
fix 863 0 1 1 0 0 0
fix 864 0 1 1 0 0 0
fix 865 0 1 1 0 0 0
fix 866 0 1 1 0 0 0
fix 867 0 1 1 0 0 0
fix 868 0 1 1 0 0 0

Can you provide the replacement OpenSees code corresponding to the above code block for stiffness properties pier_rot_stiffnesses = [0, 0, 1e3, 1e3, 0, 0]?
Is that the only change in the resulting .tcl file that is required?

The translational and rotational attributes of Support should now be in [0, inf] instead of a boolean.

Currently I think that it would be more general to not directly have stiffness inputs in Support. It is a (software) design decision, I think it would be more general if Support was only the geometry and corresponding materials. I'm not very confident though but I made the changes in this pull request accordingly.

Can you provide the replacement OpenSees code corresponding to the above code block for stiffness properties > pier_rot_stiffnesses = [0, 0, 1e3, 1e3, 0, 0]?

Is that the only change in the resulting .tcl file that is required?

It would look like this:

# Bottom nodes of pier 1 in pier group 3
# node id X Y Z
node 862 89.625 -3.5 -4.838298
node 863 89.625 -3.5 -4.837807
node 864 89.625 -3.5 -4.740098
node 865 89.625 -3.5 -4.739607
node 866 89.625 -3.5 -3.556792
node 867 89.625 -3.5 -3.556301
node 868 89.625 -3.5 -3.3

# Pier 1 in pier group 3 support/boundary condition nodes
# Twin sibling of each bottom node of pier 1, note that their coordinates are the same!
# node id X Y Z
node 100862 89.625 -3.5 -4.838298
node 100863 89.625 -3.5 -4.837807
node 100864 89.625 -3.5 -4.740098
node 100865 89.625 -3.5 -4.739607
node 100866 89.625 -3.5 -3.556792
node 100867 89.625 -3.5 -3.556301
node 100868 89.625 -3.5 -3.3

# spring stiffness per node pair for pier 1 in pier group 3
# uniaxialMaterial Elastic id E
uniaxialMaterial Elastic 123 $$E

# spring element
element zeroLength id node_i node_j -mat mat_id -dir dir_int
element zeroLength 234 862 100862 -mat 123 -dir 6 # rotation about global z (to be checked if the local coordinate system coincides with the global if the local coordinate system is not defined here, I'm quite confident that it works like that)
element zeroLength 235 863 100863 -mat 123 -dir 6
...

Where $$E:

$$E = pier_rot_stiffnesses[index_pier_group] / number_of_nodes_at_pier_bottom[index_pier_group] = 1e3 / 7

Assuming that all piers in the same group have the same number of bottom nodes, if this is not the case then the denominator should be adjusted to match the number of pier bottom nodes.

The principle is this: the summed rotational stiffness of the nodes at a pier bottom should be equal to the corresponding element of pier_rot_stiffnesses.

Ideally $$E would be based on the distance between the pier bottom nodes. $$E should be proportional to the length of the pier bottom line a node is representing while still adding up to the corresponding element of pier_rot_stiffnesses. I.e.

jerbaroo / bridge-sim