I’m a bit confused about the different line tension outputs from MoorDyn.
What I have clarified myself is, that the tension which one could request with the L#N@Ten syntax in the output section of the MoorDyn input file is actually the tension of the line segment preceding the requested node @, i.e. L#N@Ten is the same tension one gets by using the flag t in the Line Properties section of the MoorDyn input file. This is also verified by the MoorDyn developer Matt at https://github.com/OpenFAST/openfast/pull/604#issuecomment-735524446.
However, it is still not clear to me, what’s the difference between the tension at a connect node and that of a line segment?
In  it is mentioned that
I thought, that this might mean, that the tension at the connect node is the sum of the tensions of the neighbouring line segments, but that’s obviously not the case - at least not in the test cases I run.
Could someone tell me what’s the difference of the tension at a connect node and of a line segment and how the tension at a connect node is calculated?
Furthermore, when I run a MoorDyn simulation to check if my mooring line withstands the occuring forces, which tension output should I take to compare with the breaking load of the cable?
Thanks a lot in advance.
 Vissio, G. et al.: „Expanding ISWEC Modelling with a Lumped-Mass Mooring Line Model.“ In: The European Wave and Tidal Energy Conference, Nantes, France (2015). Available at https://matt-hall.ca/docs/vissio_2015_eim.pdf
To start with, I must admit that I wrote most of the current MoorDyn module in OpenFAST years ago as a side project during my PhD, and I did a hasty job with the optional outputs. Most of the refinements I made since then were to the standalone/C++ version, and it’s only since I joined NREL last year that I’m again working on the OpenFAST module version. So improvements are definitely needed in some of these outputs.
The tension channels in the line output files (enabled with a “t”) provide the tension of each segment along the line due only to stiffness, i.e. F_ten = EA*((L-L_0) / L_0), where L_0 is the segment’s unstretched length. This excludes the contribution of structural damping to the true segment tension, which can be output separately with the letter “c”.
The custom tension outputs along a line in the main output file (e.g. “L1N4Ten”) currently give the tension of the segment prior to that node, as you say. Like the tension outputs in the line output files, this is just the stiffness component and does not include the damping component. In the upcoming version 2, this output will be changed so that it gives the total tension at the node itself – an update I already made in MoorDyn C++/standalone.
MoorDyn calculates tensions at the end of a line, as applied on a connection, by summing all forces on the line’s end node. This includes internal stiffness and damping as well as weight and hydrodynamic loads. However, the net force output at a connection will include the vector sum from all attached lines, so it only gives a measure of tension in the case of fairlead or anchor connections where just a single line is attached.
The sentence you quoted refers to the fact that the dynamics of a free connection point are calculated using the sum of these forces on the ends of each attached line, as well as the sum of the lumped mass at the end of each line.
I hope these clarifications resolve your questions. In practice, if your discretization is fine enough, using the segment tension outputs along a line should usually be adequate for capturing the line tensions. That said, if you want to focus on the tension at the fairlead and have only one line attached per fairlead, taking the net force on the connection (Con#Ten where # is connection number, or equivalently FairTen# where # is line number) may give you a slightly more accurate result. If you are seeing situations where the tension on a fairlead connection is significantly different from the tension on the line’s last segment, please let me know.
thank you very much for your quick and comprehensive reply.
I just have some follow-up questions, mainly to make shure I get all things right.
You are mentioning that “if your discretization is fine enough, using the segment tension outputs along a line should usually be adequate for capturing the line tensions.”
Does that mean, that if the discretization is fine enough the damping force (output with flag “c”) is very small and thus could be neglected and that’s the reason why the segment tension output is an adequate output for capturing the line tensions?
That said, am I right that using the sum of the segment tension output (flag “t”) plus the damping force (output with flag “c”) would be an even more accurate measure of the line tension?
Additionally, how could one determine whether the discretization is fine enough or not? Could I draw the relation, that if the damping force (flag “c”) is almost zero, the discretization should be fine enough?
Additionally, you wrote “However, the net force output at a connection will include the vector sum from all attached lines, so it only gives a measure of tension in the case of fairlead or anchor connections where just a single line is attached.”
I guess with net force here you mean the output of Con#Ten, right? I wonder a bit, as this description sounds very similar to the description of what one theoretically could get with Con#fX, Con#fY, Con#fZ (as you have explained to me at: [url]http://forums.nrel.gov/t/available-output-channels-from-moordyn-module/1423/5])? So, what’s the difference between Con#Ten and Con#fX/Y/Z?
Thanks again and sorry for bothering you with all these questions.
You’re correct – when I say that the line “t” outputs should give an accurate representation of the peak tension along a line if the discretization is fine enough, I mean that other terms can be neglected. Other terms includes the “c” output, as well as inertial loads, drag loads, etc. For tensions mid-way along the line, I’d say that adding the “c” output term, as you say, could make a small improvement, but likely only for synthetic line types (it should be negligible for chains). At the fairlead end of the line, where I would expect loads to be the highest, other terms like drag could be important and very localized (e.g. peak drag at the fairlead where the velocity is the highest). That localization is the reason I mention the discretization.
The above explanation is a bit nuanced and also is very dependent on the line type, so it probably isn’t very useful as general guidance. Instead, what I would suggest is that you do a sensitivity study. Compare your tensions (both along the segments, and those at the fairlead connections) for varying discretizations and see at what NumSeg value the peak tensions converge. (You could compare the line end “t” values with the FAIRTEN values, and also see if the line “c” values are at all significant.
The physical relevance of the line structural damping depends on the line material. In many cases it is more relevant as a way to damp discretization-based resonances in the lumped-mass model than it is to exert any physically realistic damping. So I wouldn’t make any discretization decisions based on observed “c” output values.
Sorry I was a bit unclear about net forces in my earlier reply. Con#Ten will give you the magnitude of the net force on a connection, while Con#fX/Y/Z will give you the x/y/z components of that net force.
I appreciate your questions because they highlight where improvements are needed. And perhaps the biggest one is to publish updated documentation so that all aspects are more clear to users. I’ll get this done in conjunction with MoorDyn v2 release, hopefully early in the new year.
Some time has passed, but I didn’t want to miss to thank you for your again comprehensive answer.
That helped a lot and further clarified things to me.
It especially helped me to guide me to the next steps of my investigations. Thanks for this, too.
I really appreciate your openness to all kind of questions and willingness to help. Keep it up!
Being excited of what the new MoorDyn version will bring, I’m very looking forward to it.