This is a good idea, but currently low on the priority list. You’re welcome to take a stab at it and issue a pull request. I would suggest using the Spring element’s code as a template to start with.

A couple of engineers in my course are asking about whether PyNite can accommodate non-linear (axial) springs. I was taking a look at the Spring3D object and also the solver. It seems that, because @JWock82 has already implemented the iterative solver (for tension/compression elements) that it might not actually take a lot of work to add non-linearity to the springs.

The general idea would be that, instead of passing a constant for the spring stiffness, one could instead pass a function. This function would need to have a function signature kind of like:

def stiffness_function(force: Optional[float] = None, displacement: Optional[float] = None) -> float:
    """
    Returns a float representing a stiffness based on either the given 'force' or 
    'displacement'.
    """

There would be conditions in Spring3D to see whether a function or number was passed and, if a function, then the k matrix could be created using the calculated stiffness from the function instead of the static ks value. On the solver, a condition would need to be created to check for convergence but perhaps the convergence check itself could be added in to the Spring3D element to create a common interface.

It seems that there is an opportunity to update the k matrix of the Spring3D to implement other translational/rotational stiffnesses at the same time. Thus, it seems like it would not be too difficult to implement a fully non-linear spring that could provide constant or variable stiffness in any DOF.

I can start a PR for this but I will need some help. It would involve modifying/evolving the interface for Spring3D but I think it can be done in a non-breaking way.

@JWock82 @Jeroen124 @phil-vivant @flit-float-fly: What do you think?

Hello @JWock82 and @connorferster, your suggestions seem workable. I believe adopting a phased approach could be beneficial. At present, I'm not aware of a straightforward method to measure the slopes at the ends of beams. How does one accomplish this within the solver, @JWock82? Knowing the angles is crucial for certain boundary conditions, correct?

If we start by establishing a simple and elegant method for slope measurement, we could then potentially leverage this technique to iteratively develop a solution incorporating a rotational spring at the member ends. Do you both concur? How should we best go about measuring the slopes? I've encountered a method that involves using segments, (#159) though it appears to be somewhat inelegant. Would you agree?