NWTC

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 ris...

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 quit...

Dear Krishnaveni, MoorDyn is not set up to handle non-uniform seabed depths at this time. You can specify different anchor depths, but only one depth (specified by WtrDpth) will be used to model lines resting on the seabed. Positioning a line end below the seabed depth, as you do in your MoorDyn inp...

Hi Francisco, Thanks for providing the plots that show the problem, and also checking with the similar problem noted by a user last year. What you're showing isn't a behavior I'm familiar with, and I haven't been able to think of what could cause it within the MoorDyn model. To help eliminate possib...

Sorry to not have responded sooner. Here are some answers: (1) Yes, this is the right way to compile it. (2) You would need to share with me the specifics of the outputs you are looking at and what their values are for me to be able to offer a suggestion about this. (3) If you would like to use this...

This is an interesting problem that I haven't figured out yet. I see that you're using the standard OC4-DeepCwind mooring system description and it was a surprise to me that the simulation was unstable (the NaN value errors). These errors don't occur in MoorDyn v1.01.00 but do occur in v1.01.01, whi...

Hi Francisco, The frequency of those tension oscillations could be affected by hydrodynamic drag as well as the internal damping that you mentioned, so I'd double check drag coefficients just to be safe. That said, because the oscillations seem to decay more rapidly than the pitch motion, I wonder i...

Hi, If you are simply looking to use MoorDyn, I'd recommend downloading the already compiled libraries rather than the source code. If you are looking to edit the code, please see below. For Windows, the makefiles provided with MoorDyn were set up for use with MinGW. If you don't already have it, I'...

Hi Krishnaveni, I agree with Jason that your proposed approach is a good solution. Because MoorDyn is a lumped-mass model, the calculated touchdown length will change abruptly as a node touches down or lifts off. However, if you have enough nodes (short enough segments) the jumps in touchdown length...

Hi Yichau.Liu, Simulating mooring line failures would be an interesting capability. I've thought of the idea itself, but never how to go about realizing it in MoorDyn. Here are a few initial thoughts in case they are of help. Most of MoorDyn's information about the mooring system is stored in "...

Hi Paul,

Yeah, that sounds like the right approach. Summing the Con#fZ outputs (where # is connection number) for all the fairlead ("vessel") connections should give the total vertical force you're looking for. Glad there's a solution available for what you're looking for.

Best,
Matt

Hi Paul, MoorDyn in FAST isn't currently set up to output the net force components along the line - mostly because I wasn't sure this sort of output would be useful and have a clear physical meaning. The net forces on a node internal to the line would include tensions pulling in opposite directions ...

Dear Luigia, The outputs directly from MoorDyn, including the "N" units, seem to be the correct ones in this case. 9E5 N is the right order of magnitude. I'll look through the code and see if I have an error in how MoorDyn passes the fairlead tensions to FAST. Did you mention that there wa...

Hi, What version of FAST and MoorDyn are you using? I didn't have all the output channels set up in the first MoorDyn versions, but the "Con4pX"-type outputs should be working in the latest version. If updating doesn't solve the problem or you're already using the latest version, let me kn...

I know this is an old thread now, but just as an update: I too encountered the internal error problem with my installed version of gfortran, but the latest version from http://sourceforge.net/projects/mingw-w64/ (gfortran version 5.1.0) seems to have it solved.
Cheers,
Matt