Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Static line tension disagreement #160

Closed
RyanDavies19 opened this issue Oct 12, 2023 · 12 comments
Closed

Static line tension disagreement #160

RyanDavies19 opened this issue Oct 12, 2023 · 12 comments
Assignees
@RyanDavies19
Labels
bug
Milestone
2.3.0

Comments

@RyanDavies19
Copy link
Collaborator

RyanDavies19 commented Oct 12, 2023 •
edited
Loading

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:
case_1_shape

Fairlead tension with TmaxIC = 0:
case1_comparison

Fairlead tension with TmaxIC = 200:
200s_dyrelax
@RyanDavies19 RyanDavies19 added this to the 2.3.0 milestone Oct 12, 2023
@RyanDavies19 RyanDavies19 self-assigned this Oct 12, 2023
@AlexWKinley
Copy link
Contributor

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
Copy link
Collaborator Author

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

@RyanDavies19
Copy link
Collaborator Author

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
Copy link
Collaborator

sanguinariojoe commented Oct 12, 2023 via email

@RyanDavies19
Copy link
Collaborator Author

@sanguinariojoe I don't believe so, at least not from the default value point. For MDC v2:

MoorDyn/source/MoorDyn2.cpp

Line 127 in 99cd2b6

env->rho_w = 1025.;

For MDC v1:

MoorDyn/MoorDyn.cpp

Line 307 in ea5ccf8

env.rho_w = 1025.;

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

@RyanDavies19
Copy link
Collaborator Author

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

@sanguinariojoe
Copy link
Collaborator

sanguinariojoe commented Oct 13, 2023 via email

@AlexWKinley
Copy link
Contributor

AlexWKinley commented Oct 13, 2023 •
edited
Loading

@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.
image

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
image

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

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
Copy link
Collaborator Author

@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:

MoorDyn/Line.cpp

Line 324 in ea5ccf8

double Line::getNodeTen(int i)

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:
Mod_get_ten

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:
get_ten_mod_200s

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

@mattEhall
Copy link
Collaborator

Hi all,
Yeah, I agree this line

MoorDyn/source/Line.hpp

Line 434 in d101052

vec(0.0, 0.0, M[i](0, 0) * (-env->g))); // <<< update to use W
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
Copy link
Collaborator Author

@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
Copy link
Collaborator Author

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_0

ICTmax = 200:
ICTmax_200

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

This was referenced Oct 17, 2023
Merged
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@RyanDavies19 RyanDavies19

Labels
bug
Projects
None yet
Milestone
2.3.0
Development

No branches or pull requests
4 participants
@sanguinariojoe @mattEhall @RyanDavies19 @AlexWKinley