Vibration control devices based on relative acceleration, or inerters, are all the rage these days. So it’s no surprise that inerter models are making their way into OpenSees. As far as I know, two inerter elements are available: InertiaTruss and Inerter. There has also been a third attempt at inerters, but via a material model.
Just like a regular truss element, the InertiaTruss element, merged with PR #619, computes inertial force between two nodes with a linear basic force-acceleration relationship 
ops.element('InertiaTruss',tag,ndI,ndJ,b)The InertiaTruss element works in 1, 2, and 3 dimensions with 1, 2, 3, or 6 DOFs per node. Note that this element adds a small amount of material stiffness to avoid numerical errors in the global solution, e.g., for eigenvalues or dynamic response.
The Inerter element is analogous to the TwoNodeLink element, allowing you to define inertance in multiple directions between two nodes. The inertance can be coupled between directions, e.g., between a translational and rotational DOF. Accordingly, the Inerter element takes an inertance matrix as input.
b = [m1,0,0,i4] # Uncoupled 2x2 inertance
b = [m1,mi,mi,i4] # Coupled 2x2 inertance
ops.element('inerter',tag,ndI,ndJ,'-dir',1,4,'-inertance',*b,'-orient',x1,x2,x3,y1,y2,y3)The Inerter element does not add artificial material stiffness to mitigate numerical errors in the global solution, so you’ll have to DIY that with additional elements.
A third inerter implementation almost came into OpenSees not as an element, but as a UniaxialMaterial. The PR (#595) for the GyroMassMaterial was closed by the implementer before we merged it. I like this approach, but there are some logistical issues. Because the UniaxialMaterial interface only deals with strain and strain rate, any inerter material must implement an internal time stepping algorithm, e.g., Newmark, to get strain acceleration. This could lead to inconsistencies with the global time stepping algorithm.
Of course, we could get around this time stepping issue with a material wrapper analogous to DamperMaterial, but for strain acceleration instead of velocity. Then you could easily start playing with nonlinear inertance relationships. Maybe even use Concrete23 for inertance–but just because you could do that doesn’t mean you should.
Portwood Digital 
Excellent ! Thank you. I was looking how to implement an internal time stepping algorithm for strain velocity in my material also. Now I understood that I have to use a wrapper.
Can you please help me to understand how to write that – I need to get strain velocity for my material.
Thank you for nuggets of gold !
LikeLiked by 1 person
Thank you!
For strain velocity, some elements like truss and zeroLength compute and send strain rate to the materials, so I don’t think you need to code anything special.
LikeLike
How would the wrapper get around the need for time stepping estimation of the acceleration in the material? It seems like the benefit of a wrapper would be to avoid repeating the time stepping code, not to eliminate it.
LikeLiked by 1 person
I may not have thought this all the way through…. But, if we added a setTrialStrainAcceleration method to the UniaxialMaterial interface, a wrapper could then take strain acceleration from an element and pass it down as “strain” to any material. This is what DamperMaterial does with strain rate and strain.
LikeLike