Implementation of the Syrope model for polyester ropes in MoorDyn#369
Implementation of the Syrope model for polyester ropes in MoorDyn#369zhilongwei wants to merge 29 commits intoFloatingArrayDesign:devfrom
Conversation
| { | ||
| const auto sim = run_case(c, superimpose_fast); | ||
| const Eigen::Index n = | ||
| std::min(sim.tension_output.size(), sim.strain.size()); |
| ------------------------- LINE TYPES -------------------------------------------------- | ||
| LineType Diam MassDenInAir EA BA/-zeta EI Can Cat Cdn Cdt | ||
| (-) (m) (kg/m) (-) (Pa-s/-) (n-m^2) (-) (-) (-) (-) | ||
| poly 0.203 40 SYROPE:../owc.dat|1.53e8|23.12 5.0e10|1.0e5 0.0 0.0 0.0 0.0 0.0 |
There was a problem hiding this comment.
Not really a big fan on how syrope config is set, specially those new full sections. I will let anyway @RyanDavies19 @mattEhall and @shousner to decide
There was a problem hiding this comment.
Thanks for the feedback. The additional sections were introduced to keep all Syrope model parameters within the existing input file, avoiding the need for a separate configuration file. This may not be the most consistent approach with the current input structure. An alternative would be to move the Syrope-related parameters into a separate file if that better aligns with the overall design.
There was a problem hiding this comment.
@zhilongwei, I think it would be better if all the Syrope inputs were a separate input file, which would be consistent with the approach used for a non-linear lookup table.
Then the main moordyn input file would read:
------------------------- LINE TYPES --------------------------------------------------
LineType Diam MassDenInAir EA BA/-zeta EI Can Cat Cdn Cdt
(-) (m) (kg/m) (-) (Pa-s/-) (n-m^2) (-) (-) (-) (-)
poly 0.203 40 SYROPE:input.dat|1.53e8|23.12 5.0e10|1.0e5 0.0 0.0 0.0 0.0 0.0
And then input.dat would read:
../owc.dat nonlinear stiffness lookup table path
-------------------------- SYROPE WORKING CURVES -------------------------------------------------
LineType WCType k1 k2
(-) (-) (-) (-)
poly QUADRATIC 0.25 1.0
-------------------------- SYROPE IC -------------------------------------------------
Line Tmax Tmean
(-) (N) (N)
1 1.3886e6 4.339e5
Note input.dat is just a placeholder, you could call the file whatever you wanted to.
There was a problem hiding this comment.
I am now thinking that the initial Tmax and Tmean should not be treated as line-type properties since they are line-specific. For example, different lines that share the same Syrope properties (e.g., original working curve, working curves, etc.) may still have different initial values of Tmax and Tmean. It may therefore be more appropriate to separate these parameters from the Syrope input file (input.dat). One idea is to add two additional fields in the Lines section (after LineOutputs). These fields would only be required and read when the corresponding line uses a Syrope-based line type.
An example is shown below.
------------------------- LINE TYPES --------------------------------------------------
LineType Diam MassDenInAir EA BA/-zeta EI Can Cat Cdn Cdt
(-) (m) (kg/m) (-) (Pa-s/-) (n-m^2) (-) (-) (-) (-)
poly 0.203 40 SYROPE:input.dat|1.53e8|23.12 5.0e10|1.0e5 0.0 0.0 0.0 0.0 0.0
The input.dat reads
-------------------------- SYROPE ORIGINAL WORKING CURVE -----------------------------------------
../owc.dat nonlinear stiffness lookup table path
-------------------------- SYROPE WORKING CURVES -------------------------------------------------
LineType WCType k1 k2
(-) (-) (-) (-)
poly QUADRATIC 0.25 1.0
--------------------------- need this line -------------------------------------------------
And the Line section reads
-------------------------- LINES -------------------------------------------------
Line LineType NodeA NodeB UnstrLen NumSegs Flags/Outputs Tmax Tmean
(-) (-) (-) (-) (m) (-) (-) (N) (N)
1 poly 2 1 1.0 1 tsc 1.5e6 8.0e5
2 poly 4 3 1.0 1 tsc 2.0e6 5.0e5
3 chain 6 5 1.0 1 tsc
Let me know your thoughts on this.
There was a problem hiding this comment.
I think that could work well. We already do a similar thing for VIV in the line properties section. I would say that if we do this, error handling should be added that logs when the syrope model is being used and throws a non-fatal warning if the Tmax and Tmin columns are detected without the syrope model activated. Similarly a fatal error should be thrown if Syrope is activated and these are not found.
And just for clean looking input files, in the docs and test cases, you should add a - in the column for a non-syrope lines:
-------------------------- LINES -------------------------------------------------
Line LineType NodeA NodeB UnstrLen NumSegs Flags/Outputs Tmax Tmean
(-) (-) (-) (-) (m) (-) (-) (N) (N)
1 poly 2 1 1.0 1 tsc 1.5e6 8.0e5
2 poly 4 3 1.0 1 tsc 2.0e6 5.0e5
3 chain 6 5 1.0 1 tsc - -
|
BTW @zhilongwei , please direct the PR to the dev branch (and rebase with it) please |
zhilongwei
force-pushed
the
features/syrope-for-polyester
branch
from
2963994 to
52eb76d
Compare
|
It seems that the new test |
|
Do kot worry about the test failing. Ryan will fix that eventually
…On Mon, 23 Mar 2026, 08:42 Zhilong Wei, ***@***.***> wrote:
*zhilongwei* left a comment (FloatingArrayDesign/MoorDyn#369)
<#369 (comment)>
It seems that the new test syrope takes a long time to finish, which also
failed locally with ctest -C RelWithDebInfo -T memcheck -j 4 -R syrope. I
will try to reduce the simulation duration and see. I am not sure why the
MoorDynF regression tests are failing, as they do not appear to be related
to the changes in MoorDynC.
—
Reply to this email directly, view it on GitHub
<#369?email_source=notifications&email_token=AAMXKKECSQ224PORW3S46YL4SDTETA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMJQHA3DANJYGYZKM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4108605862>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMXKKE5GD5QR3ZVGSWPRIL4SDTETAVCNFSM6AAAAACWYE22YGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DCMBYGYYDKOBWGI>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
@zhilongwei memcheck can be quite time consuming. If your test does not fit, it is not really a big deal. Just add it to the list of excluded tests here: https://github.com/FloatingArrayDesign/MoorDyn/blob/master/.github/workflows/memcheck.yml#L39 I will run it anyway with memcheck to be sure and let you know |
|
Yep, a lot of beef. The stdout of the test: The memory errors: I see a lot of problems reading the config and setting up the system. For the time being, please rebase with |
zhilongwei
force-pushed
the
features/syrope-for-polyester
branch
from
52eb76d to
1f52e7f
Compare
|
Hi @sanguinariojoe, thank you very much. I have rebased with the |
|
OK, I found the main problem @zhilongwei and fixed it on #371 . I am running the memcheck again. Meanwhile please rebase again to Then you can try to reduce the simulation time (even on the regular environment your new test is taking 60 seconds), or drop it from the memcheck tests. |
| `Hall, Matthew, Brian Duong, and Ericka Lozon, “Streamlined Loads Analysis of Floating Wind Turbines With Fiber Rope Mooring Lines.” In ASME 2023 | ||
| 5th International Offshore Wind Technical Conference, V001T01A029. Exeter, UK: American Society of Mechanical Engineers, 2023. <https://doi.org/10.1115/IOWTC2023-119524>`_ | ||
|
|
||
| Syrope model for polyester ropes: |
There was a problem hiding this comment.
Can you move this to underneath Modeling of Bi-stable Nonlinear Energy Sinks in MoorDyn? The references here should be listed in chronological order.
To that end, I think Implementation of bending stiffness modeling for power cables needs to be moved above Seabed friction and bathymetry approach used in v2. Feel free to make this change if you want.
|
Hi all, First off, the report is a great documentation of the code changes and validation. It will definitely be a useful reference for any future work building off of this. Thanks for putting it together! I left a few comments on input file formatting and documentation. I don't have time for a full code review, but I trust that @sanguinariojoe can find any major issues. After the docs changes are made this looks good to merge to me too! @zhilongwei, based on your report I am assuming there is a concurrent PR being prepared for OpenFAST? |
There was a problem hiding this comment.
Change the short description of EA to the following:
the line stiffness, product of elasticity modulus and cross-sectional area (N) --> the line stiffness, product of elasticity modulus and cross-sectional area (N), or nonlinear parameters (see descriptions below)
There was a problem hiding this comment.
Once you add the Syrope section to the Additional MoorDyn Files, can you add the following after the equation sentence (with a link to the Syrope section): This method can be used standalone, and is also part of the Syrope model described in <link to syrope in the Additional MoorDyn Files section>.
Change: is the slope of the load-stiffness curve. Both of these methods allow users to provide static --> is the slope of the load-stiffness curve. This method can be used standalone, and is also part of the Syrope model described in <link to syrope in the Additional MoorDyn Files section>. Both of these methods allow users to provide static
Thank you, @RyanDavies19. Yes, we have a concurrent PR for MoorDyn-F in OpenFAST that is nearly ready. We still need to update the Syrope input format there to align with the changes here. Once everything is finalized here, we will submit a corresponding PR to OpenFAST with the same functionality. |
|
Hi all, This is a fantastic new capability to have, and a good step in supporting more advanced options for elasticity. (I didn't come up with an approach for integrating a previous advanced elasticity model from @jnvn7.) The approach used here could be a good template to follow for if there other elasticity models added in the future as well. I appreciate the discussion about the input files. I like the approach of linking to a separate model-specific input file for the reasons you discussed. I feel hesitant about adding Tmax and Tmean as new core inputs in the LINES section because (1) they change the core input file format, (2) they aren't used in some cases and (3) they're more of a state/status than a design characteristic. I think having a separate SYROPE IC section for them in the syrope.dat file, in the format discussed earlier, is the better approach. E.g.: In this approach, the first column could also support a list of lines (similar to the format we use for specifying line failures), for user convenience. |
|
Guys, I have been thinking... From the following scheme on the report: 
It seems reasonable to let I really think that is the sensible way to proceed on MoorDynC, but it might be problematic on MoorDynF |
Thank you @mattEhall. This approach is feasible. However, it would require defining Tmax and Tmean for Syrope lines (in the LINE TYPES section) before the LINES section. As you pointed out, Tmax and Tmean are state variables rather than design parameters (or line properties), so they should ideally be defined separately from the Syrope properties. To preserve the core input file structure, it may still be acceptable to include them alongside the Syrope working curves, provided this is clearly documented and does not introduce confusion for users. |
Hi @sanguinariojoe, thank you for the suggestion. The method here (as in SIMA/RIFLEX), however, is a multi-stage method and requires a prior static analysis to find Tmean only. Tmax would still need to be provided. As MoorDyn is a time-domain solver, it is unable to guess the initial values. |
Well, it was worthy to ask! |
RyanDavies19
left a comment
RyanDavies19
left a comment
There was a problem hiding this comment.
Thanks for moving things around in the docs. All this looks good to me! I will defer to @mattEhall for the TMax0 and TMean0 placement location
|
Hi all, I am still hesitating about the suggestion to place Tmax and Tmean in the same file as Syrope working curves.
As an alternative, one possible approach is to introduce an optional SYROPE IC section in the main input file (similar to the FAILURE section), placed after the LINES section. For example: This section is only required when Syrope is used, and a warning will be raised if it is present but no Syrope line types are defined in the LINE TYPES section. I would appreciate your thoughts on this approach. Below is a realistic example that has been tested and run successfully: where the syrope.dat reads |
|
That approach makes sense to me, and follows the approach of optional input file sections commonly seen in the MoorDyn-F / OpenFAST side of things (see https://moordyn.readthedocs.io/en/latest/inputs.html#external-loads-moordyn-f-only, https://moordyn.readthedocs.io/en/latest/inputs.html#failure-moordyn-f-only, https://moordyn.readthedocs.io/en/latest/inputs.html#control-moordyn-f-only). Curious on others thoughts! |
|
MoordynC has optional sections too, like rods and bodies.
I would keep the input file as uncluttered as possible. But I suppose there
is no much of a better approach here.
So for me you can go ahead
…On Sun, 12 Apr 2026, 08:06 Ryan Davies, ***@***.***> wrote:
*RyanDavies19* left a comment (FloatingArrayDesign/MoorDyn#369)
<#369 (comment)>
That approach makes sense to me, and follows the approach of optional
input file sections commonly seen in the MoorDyn-F / OpenFAST side of
things (see
https://moordyn.readthedocs.io/en/latest/inputs.html#external-loads-moordyn-f-only,
https://moordyn.readthedocs.io/en/latest/inputs.html#failure-moordyn-f-only,
https://moordyn.readthedocs.io/en/latest/inputs.html#control-moordyn-f-only
).
Curious on others thoughts!
—
Reply to this email directly, view it on GitHub
<#369 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMXKKFSCZ5V4BW2CZGJXWD4VMW5FAVCNFSM6AAAAACWYE22YGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DEMZQHA3TQNZWGQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Well, it seems @zhilongwei has implemented the @mattEhall approach, so I suppose it is all green lights now. Tomorrow I'll check again for mem errors and if nobody has complained by then I will merge |
|
@zhilongwei , before I merge, please add your test the memcheck-excluded ones: https://github.com/FloatingArrayDesign/MoorDyn/blob/master/.github/workflows/memcheck.yml#L39 |
Have done so. Should I also rebase with dev again? |
4 participants
Feature or improvement description
This pull request implements the Syrope model for polyester mooring ropes in MoorDyn-C.
The implementation captures:
Impacted areas of the software
Additional supporting information
syrope, has been introduced. A standalone version of the test is also available at: https://github.com/zhilongwei/moordyn-syrope-tests.git, along with example input files for the Syrope model.ESOMOOR D5.1: Extended MoorDyn solver and validation report.
Generative AI usage
Test results
Notes for reviewers
elastic_modeltype,ELASTIC_SYROPE = 4, has been added alongside the existing three models. It is triggered exclusively when the Syrope model is specified through theEAfield in the input file.