modelica / ModelicaStandardLibrary

Free (standard conforming) library to model mechanical (1D/3D), electrical (analog, digital, machines), magnetic, thermal, fluid, control systems and hierarchical state machines. Also numerical functions and functions for strings, files and streams are included.
https://doc.modelica.org
BSD 3-Clause "New" or "Revised" License
481 stars 169 forks source link

Request for one-sided spring, which would act as wire #3557

Open goatchurchprime opened 4 years ago

goatchurchprime commented 4 years ago

I want to simulate the forces generated by a wire that exerts a force when it is under tension, but goes slack if the endpoints are closer than its length.

If a spring only gave positive forces, so there was an option for its force to be:

f = abs(c*(s_rel - s_rel0));

then it would seem to do this for me.

I've looked everywhere for this feature, but I can't find it anywhere as an option. Is there a technical problem with having it?

The spring implementation code is here:

https://github.com/modelica/ModelicaStandardLibrary/blob/master/Modelica/Mechanics/MultiBody/Forces/Spring.mo

but it uses a second script to apply hook's law here:

https://github.com/modelica/ModelicaStandardLibrary/blob/master/Modelica/Mechanics/Translational/Components/Spring.mo

mtiller commented 4 years ago

You could just use a prismatic joint and add a simple 1D element to implement this functionality. I don't think your expression is right, it should be something like f=c*max(0, s_rel-s_rel0) if I understand what you are trying to accomplish.

Rather than waiting for this to be added to the standard library (which may never happen), I think you should just create a component of your own and use that. That is the beauty of Modelica, you don't need all primitives to come from the standard library, you can make your own.

goatchurchprime commented 4 years ago

Wouldn't a prismatic joint then require spherical joints at each end to model the anchors?

I found it practically impossible to make a self-contained wire model based on the code in the standard model. There are too many interlinking references, imports and packages from other parts of the library. I gave up at the parameter SI.TranslationalSpringConstant c(final min=0) "Spring constant"; line where I eventually found the SI object inside a Units.mo file, but couldn't see how to include it.

In the end I cloned the whole of the standard library, hacked in that max() function above into one of the Spring.mo files, unloaded the original library, loaded in my copy of the library, set a 2m long wire (spring constant c=5000N/m) between the world and a body at position (1,0,0), and dropped it.

The results look convincing, with the body being jerked side to side when the wire goes taut, but otherwise following parabolic trajectories in Z (I mean Y).
image

The animation could be done with a one-coil spring that goes straight when its under tension, but looks symbolically slack when it's not.

I cannot see how this how this is an omission from the standard library, unless engineers very seldom use tensegrity and wires in their structures. There's this one example of the super-ball-bot, although what we were trying to use modelica to analyse is a hang-glider's airframe.

mtiller commented 4 years ago

As far as I can tell, you'd only need the spherical joints if you wanted to solve for the angular position of the wire. Otherwise, you know exactly what position the spherical joint will be in when the wire is taut and it would be the angle of the prismatic joint. So I don't see the issue.

I don't understand at all what you mean by having to clone the entire Modelica Standard Library. Why? You shouldn't modify the existing models, that shouldn't be necessary at all. The prismatic joint has a special set of connectors that allow you to insert a 1D element between the two ends of the prismatic joint. All you'd really need is to use the prismatic joint and put a "tension only" spring between those 1D connectors. No cloning the MSL, no modifying Spring.mo, etc.

I realize it may not be obvious precisely how to do all this (although you might find my book helpful there. So I'm trying to be critical of what you did. I'm just pointing out that it isn't necessary once you learn the various ways of extending models in Modelica. See if you can figure out how to put a simple 1D spring across the prismatic joint (both models are provided in the MSL). Then try to create your own spring model (here you could simply duplicate the existing 1D spring model in the MSL (not the whole MSL) and modify to your needs. The insert it across the connectors of the prismatic joint.

AHaumer commented 4 years ago

I fully agree with Mike's comments about working with MSL, but I'd like to warn about pitfalls implementing the 1d one-sided spring - if it's ideal, it changes the system's equations drastically. I remember that Alexandra Mehlhase did setup a formalism to switch between two different models. I'd recommend to have a look at the implementation of Modelica.Electrical.Ideal.Diode which also switches between forward and backward mode. I think that implementation of the one-sided 1d spring could be done in a smiliar way:

You might also have a look at Modelica.Mechanics.Translational.Components.ElastoBacklash.

tobolar commented 4 years ago

Depending on the problem, using Modelica.Mechanics.MultiBody.Forces.LineForceWithMass (with mass being 0 kg) could be better approach then to use prismatic (and spherical) joint. Implementing your own 1D spring model and connecting it to that LineForceWithMass stays upon you.

tobolar commented 1 year ago

IMO we can close this issue.

AHaumer commented 1 year ago

IMO we can close this issue.

Why? Do we have such a model? Wouldn't it be usefull? Or close because nobody cares about it for a long time? That's also a method of cleaning up. Tickets are made for keeping in mind.

tobolar commented 1 year ago

To me, the question is: do we need such a model? Or in other words: is this a standard model which shall be contained in a STANDARD library? Everyone of us can sure imagine fare more models to be contained. But this also increases development and maintenance effort.