Merge dev and update r-test #20
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- Tension amplitudes were sometimes changing, typically at 512 s. - This was likely caused by use of single-precision time variable with MD_Input_ExtrapInterp. - All time variables are now double precision, solving the problem.
…CF-mods2 - This brings in the initial active tension capability and the MoorDyn driver. - Much of this will be overwritten shortly by MoorDyn v2 code.
… changes and to hard-code a simple wave kinematics grid to pass this info to MoorDyn for buoyancy cans.
… turbine positions:
- New variable WaveFieldMod is passed through FAST.Farm into each OpenFAST instance
to each HydroDyn module where it can adjust phases in the complex wave elevation
amplitudes in Waves and Waves2.
- This adds a new line for Mod_WaveField below the line for Mod_AmbWind in the
FAST.Farm primary input file:
- Mod_WaveField Wave field handling (-) (switch) {1: use individual HydroDyn inputs
without adjustment, 2: adjust wave phases based on turbine offsets from farm origin}
…e. Still some things to work out for buoyancy can applications.
… parameters of the Waves module. This makes it quicker to adjust the grid settings and recompile. Also fixed the allocation oversight that prevented WaveMod=0 cases from running (given this wave grid functionality).
…locating all mooring models' inputs.
- Solved memory bug in WameMod=0 case by reordering htings. - Removing unnecessary USE WAVES and specifying "only..." in MD. - In MD, now using WaveTimes array rather than (J-1)*dtWave. - Fixed error in MD Rod Froude Krylov force calculation (was 50% too small)
This brings the latest TCF-mods2 work along with everything else in dev into the MoorDyn v2 branch.
…t/openfast into MDv2 - Not yet tested. Need to resolve some compile issues first.
- Set up new control section in MoorDyn input file parsing. - A couple adjustments to stage-setting for future farm-level mooring capability with FAST.Farm.
- Created a MoorDyn instance in FAST.Farm that can do array-level moorings. - Modified MoorDyn to take an array of all platform-related inputs/outputs. - In normal MoorDyn use in FAST, only the first entry of these arrays is used. - in FAST.Farm use of the farm-level MoorDyn, the arrays are size nTurbines and they facilitate coupling with each turbine. - Modified FAST_Solver etc. to support the new array format - Various modifications in FAST.Farm to support the farm-level mooring capability. - New MoorDyn coupling functions are in FAST_Farm_Subs. - Made a separate workflow in FARM_UpdateStates to support the necessary substepping between all FAST instances and MoorDyn, at new introduced timestep DT_mooring, which is between DT_low and DT_FAST. Included a modified OpenMP nested parallel approach to keep the FAST instances in parallel while having a longer-term parallel AWAE call. - Some bugs still. Currently hitting a mesh issue with the farm-level MoorDyn mesh mapping I set up. "MD_2_FWrap:MeshMapCreate:MeshMap%MapLoads not allocated because no nodes were found to map."
…OpenFAST tests that were removed. - 5MW_ITIBarge_DLL_WTurb_WavesIrr_py - hd_5MW_ITIBarge_DLL_WTurb_WavesIrr - hd_5MW_OC4Jckt_DLL_WTurb_WavesIrr_MGrowth
This will help a bit in minimizing a race condition during test running. See comments in PR OpenFAST#1199
Use dt_out when storing OpenFAST outputs in Python interface
If a turbine is using SubDyn, the shared moorings connection will be to the platform reference point and not the SubDyn structure. This can lead to some incorrect behaviour if the mooring connections need to be at points on a flexible platform.
@deslaughter found this issue in the PR
Reg-test scripts modification to help avoid race condition and cleanup of caselist
Small improvements for -VTKLin visualization outputs
Fix HD added mass on member end (Close OpenFAST#992)
Merge dev into MDv2-farm to update MDv2-farm in preparation for merging into dev for v3.3
Rather than porting everything over, we are simply linking to the other set of documentation that goes with the MoorDyn C++ version.
Not sure it was necessary to really spell out all the MD changes, but I did anyhow
MoorDyn v2 + shared moorings + wave propagation in FAST.Farm
bjonkman
pushed a commit
that referenced
this pull request
Feb 6, 2024
Fix issues to get C++ API to run
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Feature or improvement description
This pull request merges the current
devbranch and also updates the two AOC regression test case baselines - see OpenFAST#1042.