Static line tension disagreement

[RyanDavies19]

Static lines initialize with different tensions between MDC_v2 and MDF_v2/MDC_v1. Differences also emerge with dynamic relaxation. Using MoorPy, NREL's quasi-static model, the equilibrium fairlead tension is 4808 kN. This indicates that MDC_v1 and MDF_v2 are getting a solution closer to the correct answer. See the figures below for a single line resting partially on the seabed:

Line profile:

Fairlead tension with TmaxIC = 0:

Fairlead tension with TmaxIC = 200:

[AlexWKinley]

If you have a MDC_v2 model file, I would definitely be interested to take a look. It looks like the disagreement is percentage wise pretty small, but it would definitely be good to track it down.

[RyanDavies19]

@AlexWKinley Sure thing, here it is: case1.txt

[RyanDavies19]

I've noticed dynamic relaxation differences popping up elsewhere too. I am currently working on tracking them down to put together a fix. @AlexWKinley if you see something that pops out to you that would be great to know.

[sanguinariojoe]

4808 x 1.025 = 4928

Might it be just a different default water density?

On Thu, 12 Oct 2023, 21:39 RyanDavies19, @.***> wrote:

I've noticed dynamic relaxation differences popping up elsewhere too. I am currently working on tracking them down to put together a fix. @AlexWKinley https://github.com/AlexWKinley if you see something that pops out to you that would be great to know.

— Reply to this email directly, view it on GitHub https://github.com/FloatingArrayDesign/MoorDyn/issues/160#issuecomment-1760259401, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMXKKD3YIT2ONYDIH5PKPTX7BBOLAVCNFSM6AAAAAA55447RCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONRQGI2TSNBQGE . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[RyanDavies19]

@sanguinariojoe I don't believe so, at least not from the default value point. For MDC v2: https://github.com/FloatingArrayDesign/MoorDyn/blob/99cd2b6e6afa7e5d58e2ac7ac3a4b05e127f1f72/source/MoorDyn2.cpp#L127

For MDC v1: https://github.com/FloatingArrayDesign/MoorDyn/blob/ea5ccf8c050f359cdd13a0a8b6f5cc5f3158405c/MoorDyn.cpp#L307

And MDF requires a manual input of rho via a driver input file, it is set to 1025 there.

[RyanDavies19]

I do believe though it is a default value or scale issue of some kind because of the constant difference

[sanguinariojoe]

It was just an idea. I let you guys deal with this. I have some other projects to attend

On Thu, 12 Oct 2023, 22:47 RyanDavies19, @.***> wrote:

@sanguinariojoe https://github.com/sanguinariojoe I don't believe so, at least not from the default value point. For MDC v2: https://github.com/FloatingArrayDesign/MoorDyn/blob/99cd2b6e6afa7e5d58e2ac7ac3a4b05e127f1f72/source/MoorDyn2.cpp#L127

For MDC v1: https://github.com/FloatingArrayDesign/MoorDyn/blob/ea5ccf8c050f359cdd13a0a8b6f5cc5f3158405c/MoorDyn.cpp#L307

And MDF requires a manual input of rho via a driver input file, it is set to 1025 there.

— Reply to this email directly, view it on GitHub https://github.com/FloatingArrayDesign/MoorDyn/issues/160#issuecomment-1760343731, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMXKKBQ7OGDO7IRMZCSJYTX7BJOBAVCNFSM6AAAAAA55447RCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONRQGM2DGNZTGE . You are receiving this because you were mentioned.Message ID: @.***>

[AlexWKinley]

@RyanDavies19

Edit 1: Actually I lied, I had made a change to the model that was having a more significant impact (increasing the number of segments). Rerunning without the change shows no significant improvement.

Edit 2: I found something that might actually matter, although I'm still not sure sure how important it is for getting agreement with the other version.

In Line.hhp Line;:getNodeTen

    inline vec getNodeTen(unsigned int i) const
    {
        if (i > N) {
            LOGERR << "Asking node " << i << " of line " << number
                   << ", which only has " << N + 1 << " nodes" << std::endl;
            throw moordyn::invalid_value_error("Invalid node index");
        }
        if ((i == 0) || (i == N))
            return (
                Fnet[i] +
                vec(0.0, 0.0, M[i](0, 0) * (-env->g))); // <<< update to use W

        // take average of tension in adjacent segments
        return (0.5 * (T[i] + T[i - 1]));
    };

It looks like we are adding an additional weight term to the end force. As far as I know, Fnet[N] should already contain that weight term. For reference the Line::getEndStuff function just returns Fnet[N] for ENDPOINT_TOP. A quick look at the v1 branch suggests to me this is a change carried over from there, but perhaps it was more justified in that case?

I'm not entirely convinced by this, but it would pretty accurately match the idea of a constant offset, and if you change it to just return Fnet[i] for the ends, the tensions decrease to more closely match the others.

I'll leave it up to you to determine if that behavior is present or correct in the other version of MoorDyn.

Left because it still is a difference but doesn't actually make a difference

One thing that seems to have an effect is the fact that MoorDyn v2 does submergence calculations that make a decent approximation for cylinders.

This causes the top segment to have slightly less buoyancy because it's like top corner is sticking out of the water. Crude illustration of what part of the cylinder is out of the water

If I remove the partial submergence calculation in Line::getStateDeriv

// F[i] = calcSubSeg(i, i + 1, surface_height);
F[i] = 1.0;

the fairlead tension does decrease to be a little closer to the others.

But it doesn't look like that is the only factor. You might want to validate my findings with your setup, I'm using a slightly old and slightly modified version of MoorDyn v2 (although my numbers generally agree with yours before the submergence change).

[RyanDavies19]

@AlexWKinley I think it was the first one you noted, with regards to adding an extra weight. V1 did have the added weight found here: https://github.com/FloatingArrayDesign/MoorDyn/blob/ea5ccf8c050f359cdd13a0a8b6f5cc5f3158405c/Line.cpp#L324 Removing the added weight in v2 causes all the versions to line up (under the TmaxIC = 0 case). Here is the comparison with that weight removed:

Another note though is that it seems like the dynamic relaxation methods have some differences. I will leave this issue open until we can resolve those as well. With the removal of that added weight, here are the fairtens with TmaxIC = 200:

@mattEhall do you have any inputs on either of these?

[mattEhall]

Hi all, Yeah, I agree this line https://github.com/FloatingArrayDesign/MoorDyn/blob/d1010520a4285f650c696a0ba0545c3ce58fe756/source/Line.hpp#L434 is causing a double counting of the weight contribution to the tension of line end nodes. If we remove it the code will be consistent with v2 Fortran.

Regarding differences in the initial conditions between C and F, the first thing I'd wonder is if the codes hit the convergence tolerance at different times (assuming they don't go through all of TMaxIC=200 seconds). I don't recall if the convergence criterion is the same in both codes.

[RyanDavies19]

@mattEhall That's likely it, I believe the Fortran code reaches it first. I am working on that now and will have a PR up soon with both the weight double counting fix and that relaxation criteria standardized.

[RyanDavies19]

Okay so it turned out there were a couple things going on here. First, MDF had an indexing error that caused it to not compare the current fairten to the previous 10 in the dynamic relaxation routine. Secondly MDC was checking the previous 10 fairtens while MDF was checking the previous 9 fairtens. Lastly the way the MDC main IC gen time stepping loop was set up caused an extra timestep to be run because ICTmax - t > 0 when t = ICTmax due to precision errors. Fixing these in both codes resolves the differences we were seeing. For that same case1 input file these are the results now:

ICTmax = 0:

ICTmax = 200:

I am putting together PR's to both MDF and MDC with these changes.