Thanks, @Roger.Bergua,
all crystal clear!
Unfortunately I am only using universal and ball joints, so I think I cannot get the right loads, not even with the dummy beans, if I understood correctly.
Anyway, I have noticed that if one one side of the universal/ball joint there is a member of the type “cable”, the bending moment are basically zero (as expected), so I wonder if you have performed, among the verification cases, some with a cable on one end and a beam on the other end.
I’m not sure I follow you… All the loads, except in the dummy beams, should be the proper ones.
According to your description, it seems that you are connecting one universal joint and one cable element together. My understanding is that revolute/universal/ball joints can only be connected to beams. So, you should place, at least, one beam in between those 2 elements.
Adding one schematic representation of your system may help us understand what could be the issue.
Thanks, @Roger.Bergua.
If you look at the SubDyn input file here, I managed to run successfully a number of simulations where I have 9 member of the type cable Mtype = 2, and these are connected at the top to ball joints, and at the bottom to universal joints. For example, if you take member 26, it goes from joint 35 (a universal joint) to joint 20 (a ball joint).
Also, below joint 35 there is a beam member, which goes from the seabed (joint 25) to the universal joint 35.
Maurizio,
If I try to run your model in a stand-alone SubDyn, I have quite some problems.
First of all, I get many warnings about the system being ill-conditioned:
When looking at the SubDyn summary file, I can see that there are 6 rigid body modes (6 frequencies at 0 Hz or very close to it) and the Craig-Bampton modal reduction failed (there are no retained modes available):
Note that in your fixed-bottom system, there shouldn’t be any rigid body motions.
Moreover, there are 10 reaction joints with soil-structure interaction files. If you want to take into account those stiffness matrices, the flags in the different directions should be 0.
Finally, note that the cable element only works at traction (actually in SubDyn will work at traction and compression due to the underlying linear theory used). The cable element doesn’t transmit bending moments. I’m not sure why you need the universal and ball joints in this SubDyn model. Maybe I’m missing something…
Dear @Roger.Bergua ,
firs tof all thanks a lot for taking the time to go through my model, and to analyse it.
I’ll try to answer all your points, and I hope this would also help NREL team to get a better insight into SubDyn for such an unconventional support structure:
First of all, I get many warnings about the system being ill-conditioned.
Yes, they appeared the moment I introduced universal joints and ball joints type at the end of the pre-tension cables. I also noticed (maybe a coincidence) that the number of warnings I got is equal to the number of rotational DOFs let free by the joints. In fact, I got 9 cables, each one connected with a ball joint at the top (9 x 3 = 27) and a universal joint at the bottom (9x2 = 18), and 27+18 = 45, which is the number of warnings. Furthermore, once removed the ball joints, the warnings went from 45 to 18, which seems to confirm the above Anyway, I removed the ball joints first (v2) and the ball joints and universal joints (v3), and compared the tension in the cables, and the forces at the bottom of the cables: no big differences, although all the WARNINGS messages disappeared! More at point 4 below.
When looking at the SubDyn summary file, I can see that there are 6 rigid body modes (6 frequencies at 0 Hz or very close to it) and the Craig-Bampton modal reduction failed (there are no retained modes available)
This is strange, as with the same file, but using OpenFAST I obtain the following (so no rigid body motions). Can the introduction of the tower and RNA change things? I woudl have not thought so, but this si what happens. Screenshot below, and link to the SD.sum.yaml here:
Moreover, there are 10 reaction joints with soil-structure interaction files. If you want to take into account those stiffness matrices, the flags in the different directions should be 0.
I do not have info about the soil, so I do not want to take into account the stiffness matrices. The indicated file xxx.txt' does not exist, and was I check I did, i..e., verifying that OpenFAST/SubDyn was not looking for the file xxx.txt, and that is the case, since I do not receive a "file not found" error. I suppose I can delete the xxx.txt` from each line to avoid confusion.
Finally, note that the cable element only works at traction (actually in SubDyn will work at traction and compression due to the underlying linear theory used). The cable element doesn’t transmit bending moments. I’m not sure why you need the universal and ball joints in this SubDyn model. Maybe I’m missing something…
Thanks a lot for this observation. Yes, I agree, the cables only works at traction (and compression, as I obseerved for some failed simulations). The only reason I used universal and ball joints is because this is how the structure is in reality. But since the universal and ball joints seem to introduce some WARNINGS, and possibly some bugs in reading the member end forces, I now removed the universal and ball joints at the end of the cables. As mentioned above, I compared (for a static case) the tension in the cables and the reaction forces at the bottom of the cables (i.e. at the top of the pile anchor of each cable), and although there are some minor differences between version with ball and universal joints (v1), no ball joints (v2), and no ball no universal joints for the cables (v3), these forces are basically the same.
Anyway, since the WARNINGS have disappeared, I will keep (v3) for my simulations, hoping that this would give me a “w/out bug” reading of the end member forces.
Anyway, I still have this “bug” for the main barrel element…
I’m glad to hear that the feedback was useful, Maurizio.
Regarding the SubDyn summary file, it should be the same for OpenFAST and SubDyn standalone. I think the problem was at my side, as I was using a pretty old SubDyn version. I just recompiled the one from OpenFAST v3.5.0 and I got outputs that are very similar to yours:
Hopefully your model is finally working as expected 
Perfect, thanks a lot @Roger.Bergua !
