Spherical Joint

[bencannell]

Hi @tkoziara,

Would it be possible to include functionality to model a spherical joint (ball in socket) with rotational stiffness. Specifically we are intending to translate the LS-DYNA keywords CONSTRAINED_JOINT_SPHERICAL_ID and CONSTRAINED_JOINT_STIFFNESS_FLEXION-TORSION as defined here.

There are a number of variables which we ignore (or are always zero) in the LS-DYNA input decks we are translating into parmec. As such, we do not need these options/behaviours to be available in the parmec implementation. I've provided an example of our LS-DYNA keyword usage below along with comments as to which variables can be ignored (or assumed to have default values):

---

*CONSTRAINED_JOINT_SPHERICAL_ID 2905
11290530 11290501 1.0 1.0

Variables N3, N4, N5 and N6 are not required. Variables RPS and DAMP are always 1.0.

---

*CONSTRAINED_JOINT_STIFFNESS_FLEXION-TORSION 12905 1290589 2290589 1290530 2290530 0 1000089 0 10000089 10000089 0 10000089 0.0 0.0 0.0 0.0 0.0 0.0 0.0

Variables JID and LCIDG are always set to 0. All values in Card3 and Card4 are always set to 0.0 (sets these properties as inactive).

---

Would the above be possible?

Best regards,

Ben

(mention @stevebrasier)

[tkoziara]

Hi:) Yes, of course I can look into this and implement such functionality; I will have a look soon and get back to you with a proposed way of doing it; T.

[tkoziara]

Hey:) @bencannell @stevebrasier

In fact this can be already realised by using coincident points with springs, yes? Have a look the following test: https://github.com/tkoziara/parmec/blob/master/tests/spring.py https://github.com/tkoziara/parmec/blob/master/tests/spring_chain.py

I just added the possibility to define spring dashpot as a critical damping factor instead of a lookup table; Have look at these examples: https://github.com/tkoziara/parmec/blob/master/tests/spring_damping_factor.py https://github.com/tkoziara/parmec/blob/master/tests/spring_chain_critical.py

This helps to simplify the choice of damping in case one would like to realise joints using springs; Let me know whether this functionality is sufficient for what you would like to do:) T.

[bencannell]

Ah, excellent. Thank you for looking into this. I'll let you know how we get on!

[bencannell]

Hi @tkoziara (and @stevebrasier),

I can't currently see how the current spring definition provides the functionality we're looking for.

We want to be able to constrain the relative rotation of nodes using spring definitions whereas I think the SPRING definition only allows for the relative displacements of nodes to be controlled.

I've attached the figure below (taken from the LS-DYNA documentation). We are aiming to be able to use non-linear spring/damper curves to constrain the motion in angles alpha and beta (gamma is unconstrained in our models so can be ignored).

What do you think?

[tkoziara]

I see; my previous interpretation was about enabling an unconstrained spherical joint, which is realised by a spring joining coincident points; ok - constraining rotation angles is another matter - let me have another look; Could you propose an example Python interface for such joint? It may help me guide development work.

[tkoziara]

Having given this some thought, perhaps this is an ok initial guess:

A needed more abstract command first:

asn = ANGLE_SPRING (part1, part2, point, zdir, xdir, kalpha, kbeta, kgamma)

and then:

(psn, asn) = SPHERICAL_JOINT (part1, part2, point, zdir, xdir, stiffness, alphalim, betalim)

where above:

psn is the point spring number (i.e. same as returned by SPRING) asn is the angle spring number part1 is a first particle number part2 is optional (can be -1) kalpha, kbeta, kgamma are angle spring stiffnesses about the three Euler angles point is a coincident point between two particles zdir, xdir are local directions convected by the two particles; these directions are co-rotated with part1 while the Euler angles are measured between so co-rotated directions and these same directions co-rotated with particle part2; these directions must be orthogonal but don't have to have unit lengths stiffness is the joint stiffness (or -1 to automatically use a maximum stiffness that does not lower the stable time step) alphalim, betalim, are the limits on the two Euler angles (no limits by default; in this case the joint is realised by a two-point spring only and asn = -1)

The spherical joint is realised by a two-point spring with the prescribed stiffness, constraining the relative motion of the coincident point, and an angle spring with kalpha = kbeta = stiffness |zdir| and kgamma = 0, constraining the relative rotation about the alpha and beta angles (multiplication by |zdir*| can be used to allow for an extra freedom of stiffness adjustment). Critical damping is used along in all cases to stabilise the spring constraints.

How does this look like to you? (@bencannell and @stevebrasier)

[bencannell]

Would kalpha, kbeta, kgamma be single values or non-linear curves of moment versus rotation?

Also, are you able to include damper curves similar to the SPRING definition where the user can provide non-linear curves for the rate of rotation vs unit time? Rather than enforcing critical damping.

[tkoziara]

Yes, all these could be non-linear curves - the same as it is now for regular springs; also damping could be added in the same manner as it is now used in the SPRING command: either value or table based curve or -1 indicating critical damping;

[tkoziara]

Here is a revised interface:

trsnum = TORSION_SPRING (part1, part2, zdir, xdir | kalpha, kbeta, kgamma, dalpha, dbeta, dgamma)

where:

trsnum - torsion spring number part1 - first particle number part2 - second particle number; -1 can be used to indicate a single-particle constraint zdir, xdir - local direction tuples (u,v,w), convected with the two particles, and used to determine the Euler angles alpha, beta, gamma; these directions must be orthogonal kalpha, kbeta, kgamma - spring torque lookup tables [angle1,torque1,angle2,torque2,...], about the three Euler angles; default: [−∞,0,+∞,0] dalpha, dbeta, dgamma - dashpot torque lookup tables [angvel1,torque1,angvel2,torque2,...] or a critical damping ratio from interval [0,+∞); default: [−∞,0,+∞,0]

The spherical joint can then be realised as:

SPRING (part1, point, part2, point, spring, dashpot) TORSION_SPRING (part1, part2, zdir, xdir, kalpha = [...], kbeta = [...], dalpha = [...], dbeta = [...])

where the angle limits can be modelled by a suitable choice of angle-torque curves.

How about that?

[bencannell]

Yes this look good thank you. I'll let you know if I think of any other limitations but this looks suitable. :)

[tkoziara]

ok; I'll start on #13 today and come back to this one next:) we can always modify as we go:)

[tkoziara]

FYI: an initial implementation is now available for testing: http://parmes.org/blog/parmec_spherical_joint.html Looking forward to your feedback:) Tomek

[bencannell]

Thank you @tkoziara, I'm adding the functionality into our DYNA translator now for testing :) Ben

[bencannell]

Hi, is the origin of the coordinate system identified by the intersect of xdir and zdir? Or is it determined by the particle positioning?

[tkoziara]

There is no need for an origin for the torsional spring per se; it is about rotations only; In the spherical joint example the linear spring between the two particles - at a coincident point - creates the unbounded rotational joint - which is then made "bounded" by means of the torsional spring; You can say that this coincident point is the "origin" of a local coordinate system for the "spherical joint constraint" - in this case:)

On 13 June 2018 at 17:25, bencannell notifications@github.com wrote:

Hi, is the origin of the coordinate system identified by the intersect of xdir and zdir? Or is it determined by the particle positioning?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/tkoziara/parmec/issues/7#issuecomment-396978664, or mute the thread https://github.com/notifications/unsubscribe-auth/ACGKNILPGlUvnW2qYVt68ZDcQw-GO1i0ks5t8S7WgaJpZM4S4rOP .

[bencannell]

OK, your example makes sense.

However, we are hoping to model a spherical joint with an infinitely stiff translational stiffness. To achieve this we would need to apply are very stiff spring curve, which would presumably have implications on the stable time step. What do you think?

Would it be straightforward to add in optional parameters pnt1 and pnt2 which define points on part1 and part2 which are rigidly constrained in rotation?

Or perhaps the RESTRAIN command could be modified to restrain relative motion of part1, part2 (I would use this defining in place of the linear SPRING definition in your "spherical joint constraint" example)

[tkoziara]

We have linear springs and torsional springs - these are our building blocks in Parmec. Infinitely stiff translational stiffness can be achieved through algebraic constraints. That would be another way of modelling altogether - more like in Solfec.

You can also have a look at these slides for example. They mentioned "reduced coordinates" which is another option for a rigid body framework with joints. Nonetheless, implementing this approach within Parmec would be a larger undertaking and not necessarily aligned with its current design and choices made to make the code relatively efficient.

Can you tell me more about your requirements for an infinitely stiff translational joint? What are the rationale for this?

[tkoziara]

By the way - while implementing output for torsion springs - I am adding just now a "reference point" to the torsion spring command - so that the outputted vector fields can be attached somewhere:)

Also, thinking a little more about what you've said, implementing rigid constraints between independent pairs of particles - would be quite easy - because the resulting algebra would be just 3x3 and well conditioned; what would not be easy - would be implementing rigid link constraints that can be arbitrarily mixed between any number or particles - in this case we end up with a larger system just like in Solfec;

Implementing implicit constraints in Parmec is something that we could do:) It just needs to be incremental; So let's see what is needed for just this moment:)

[bencannell]

OK, thank you for thinking about this.

The background for the request is "simply" to replicate the behaviour of a spherical joint in LS-DYNA, such that the parmec models we are producing are like-for-like. Our understanding of the LS-DYNA joints is that they are rigid in translation - hence having the same parmec functionality would mean we don't have to derive/justify a deviation away from the current LS-DYNA approach.

From your most recent message, I think it is the "rigid constraint between independent pairs of particles" which we are requesting - since our only known use for this functionality would be for the spherical joint connection between two adjacent particles.

[tkoziara]

Yes, if such particles would not form chains, then this should be OK:) Please register another issue: "Rigid links between independent pairs of particles" and I will start having a look into this once the current issue is fully processed (I am implementing output files for torsion springs today; next history output);

In the meantime just use linear springs for testing the spherical joints; Feedback on and testing of the current implementation, as it is, is welcome;

[bencannell]

Ah, ok. I think I may have misunderstood what you meant by "arbitrarily mixed between any number or particles". Our ultimate use of the TORSION_SPRING command is to model configurations such as:

Where each yellow circle is a TORSION_SPRING connecting particles (represented by the coloured lines).

Does this configuration class as "chaining" particles?

[tkoziara]

Yes:) This is an articulated body; Ok, ok, I see now!:) Can you send me an input deck from LS-DYNA where you model just a single chain of this kind? This will help me trace this functionality more accurately and look into the theory manual; I think, for this type of chains, there should be a way to model reduced coordinates by means of recursion (like in robotics), which should be quite effective; But this will require a little more thinking and reading - ha, ha, ha:) What would be a suitable issue for that? Articulated joint chains? In this case, even copying the approach from Solfec should work - by using multiple rigid links which form chains (as long as there is no branching and looping) the resulting linear system will be well conditioned - so I should be relatively easy to implement this using linear solves (rather then recursion); How long chains are these?

[bencannell]

OK, I'll email you a suitable LS-DYNA input deck.

It's also worth making you aware that there is another layer of complexity in the configuration we are modelling (and represented in the input deck I'll send you)...the particles in the chain interact with particles which aren't part of the chain using SPRINGs. We are, in effect, modelling a chain within a tube, where the tube is comprised of multiple segments connected together using SPRINGs and the tube and chain interact using SPRINGs.

Each chain will be comprised of <20 particles.

FYI @stevebrasier.

[bencannell]

For the time being I'll try and provide some feedback on our application of the TORSION_SPRING command using stiff SPRING commands to constrain relative translations as per your example.

[tkoziara]

OK; regarding the model with tubes you can also let me know more about how you represent them (what are the segments?); if you have a report or a paper where your model is described that you could share - having a look at the total idea could help us converge with more understanding of the objective;

[tkoziara]

@bencannell @stevebrasier, FYI, from my end implementation of the TORSION_SPRING functionality is completed for now; Just to summarise, here is an example of the spherical joint: https://github.com/tkoziara/parmec/blob/master/tests/spherical_joint.py and two simpler tests here: https://github.com/tkoziara/parmec/blob/master/tests/torsion_spring_one.py https://github.com/tkoziara/parmec/blob/master/tests/torsion_spring_two.py The HISTORY and OUTPUT commands now include entities specific to torsion springs: http://parmes.org/parmec/input_commands.html#history http://parmes.org/parmec/input_commands.html#output Let me know please about the results of your testing and whether it is ok to close this issue.