Hello,
For my master thesis, I’m currently working on the OC3 spar buoy concept.
I experiment with the mooring systems and want to change the catenary system made of chains to taut leg system with synthetic ropes.
All the other system parameters are unchanged.
However, during the simulation I get the following error message “Maximum outer_loop iterations reached” after 115 seconds.
Even increasing the defaut value of the tolerance from 1.0E-6 to 1.0E-3 doesn’t solve the problem.
Please find enclosed my MAP++ input file.
Thank you for your help
Kind regards,
Quentin AGOULON
Dear Quentin,
What you are experiencing is the difficulty to solve catenary equations.
You have 2 connections points, which make the equations more difficult to solve.
Did you carefully select the initial values for the connection points ?
I had the same kind of troubles. Solving catenary equations is not really robust.
I recommend you some few things :
- Initial values should be reasonable (if a segment is too streched it doesn’t work)
- try first without connection points ( with an equivalent mass for the full line)
- from my experience, changing the solver options usually don’t solve the problem
Kind regards,
Vincent
Good Afternoon,
I’m running into similar trouble. I am modeling the DeepCwind spar mooring line connection. The system consists of a similar arrangement as the example input file described in the MAP++ user manual. The system has a delta connection, which a 424.4 m long line connects to the sea bed and two 30 m lines that are considered ‘infinitely’ rigid and connected to the spar. The last two mooring lines in the model are ‘rigid’ sections that connect the 30m lines to the spar.
My current error is ’ Zero pivot detected in LU factorization.', which I know is an error in the numerical calculations. With the help of a MAP++ support representative and reading previous posts, I have tried a number of different solutions. First, I have confirmed my node’s coordinates and line lengths in SolidWorks (first attached file). Second, in the ‘Solver Options’ section of the MAP input file, I have adjusted the maximum outer loop iterations or ‘outer_max_its’, the outer and inner tolerances, and tried the different Jacobian solvers. As described by a MAP++ support representative, I’ve made sure the inner tolerances are less than the outer tolerances (see file ‘map_kristopher3’). Maybe the system cannot be solved with the number of connect-nodes?
I have also tried modeling a system without the ‘connect’ - node types. I tried to model a simple system which has three lines connecting to the spar and the seabed and the error ‘Node 18 does not project onto any line2 element.’ appears (see file ‘map_kristopher2’). I don’t understand why this error occurs. The geometry is correct, so the lines and nodes should be connected.
Any help would be appreciated.
Take care,
Kristopher Reed, EIT
Graduate Mechanical Engineering Student
University of Maine
MAP++ input file:
map-plus-plus.readthedocs.io/en … html#flags
Untitled document.docx (310 KB)
map_kristopher3.txt (1.71 KB)
map_kristopher2.txt (1.11 KB)
I noticed input file map_kristopher3.txt has three materials with EA varying between 96E6 and 96E9, and individual line lengths varying between 424 m and 0.5 m. Given this variance in stiffness, it’s not surprising the inverse Jacobian is failing. Zero pivot tells us the outer loop Jacobian is not full rank and the matrix is insufficient to find a unique solution. I quickly estimated the Jacobian condition number to be order(1000000), which is indicative of an ill conditioned problem. The Krylov boostrap option may work, but the source of the trouble is the wide stiffness range (and especially the stiff 0.5 meter line). You’ll find easier convergence to a solution omitting the half meter line.
The solver tolerances look a bit loose for the degree of stiffness in your system. The outer loop solver tolerance is 0.1 with a 0.5 m length element defined. If you remove material matThree and apply these options:
outer_tol 1e-3
inner_ftol 1e-6
inner_gtol 1e-6
inner_xtol 1e-6
outer_max_its 1000
outer_fd
outer_epsilon 1e-5
repeat 120 240
krylov_accelerator 4
Then MAP will converge.
Dear Dr. Masciola,
Thank you for your response and help. I will try your suggestions.
Take care,
-Kris
Hey,
Unfortunately the program failed to converge because the LAPACK library is not compiled in the MAP++ version that I am using. I am using the MAP++ v.1.20.10 for Windows from the following link: nwtc.nrel.gov/MAP.
Are you using the Linux version or a modified Windows version?
Thanks for your help,
-Kris
Hi Kristopher,
The version of map I used is indeed built on linux.
I wasn’t aware of this, but your error message confirms the windows binary distributed on the NWTC site is compiled without lapack. It likely went unnoticed for a while because the krylov_accelerator option is rarely used and relies on a single call to a lapack (LAPACK_dgels) matrix factorization routine. This option can be activated by recompiling MAP with the MKL library (if using Intel icc) and the “WITH_LAPACK” compiler flap activated. Unfortunately I don’t have access to a windows compiler (otherwise I could compile it).
As an aside, the Jacobian condition number created by your geometry requires extreme measures to solve. Although the krylov_accelerator flag will help, needing it is a sign the problem is ill-posed. If you remove the half meter lines in your model it will converge easier. MAP wasn’t envisioned to solve lines discretized into half meter resolution, so I think your problem pushes the bounds of what MAP was designed for.
Hello everyone,
I am trying to implement synthetic ropes on DTU 10MW structure using MoorDyn. (out of the context from this thread, I guess)
When trying to find initial nodal positions, so that can add connection points further, around 30+ nodes are positioned higher than the fairlead node.
The simulation is reaching NaN state due to large platform displacements. Can anyone explain the reason why I am facing with such error?
P.S. The layout works fine with the chain cable properties.
Thanks
Hi Abhinay,
MoorDyn requires a time step small enough to resolve vibrations of individual line segments in order for its calculations to be convergent. Because you are modeling a relatively light and stiff line with quite small segment lengths, the natural frequency of segment vibration will be quite high. As a result, you’ll need a much smaller time step (“dtM”) to avoid the simulation becoming unstable. I’d suggest trying a time step of 1 ms to start with, though I wouldn’t be surprised if it needs to be even smaller.
Hope that solves it,
Matt
Regarding a portion of the lines being out of the water, it looks like this is occurring because the lines being modeled are buoyant and have enough slack to float up to the water surface. This version of MoorDyn doesn’t distinguish the water surface, so the buoyancy is modeled even as the lines rise above the water surface (this will be changed in future versions). To avoid the lines reaching the free surface, you could reduce the line length to produce a more taut configuration, or add a clump weight to hold the buoyant lines down.
Matt
