Dear Jason,
I am a PhD candidate, writing my thesis on extending FAST’ s source code in order to conduct aero-hydro-servo-elastic analysis of combined floating systems. To achieve this, I want to utilize the “general modes’ approach”, which practically means that I have to extend the equation of motion to more Degrees of Freedom (DOFs).
I work with FAST version 8 and I noticed that the files having ‘Types’ suffix (e.g. ‘HydroDyn_Types.f90’) contain the following message:
“WARNING This file is generated automatically by the FAST registry. Do not edit. Your changes to this file will be lost.”
Indeed, when I change the dimensions of several matrices included in the FAST’ s equations (across all the file types where such matrices exist) and rebuild the solution, a kind of error message appears and I am asked to reload the ‘Types’ files as they were before my changes.
My question is whether I am doing something wrong that prohibits me from running the new code or there is no possibility to change the matrices’ dimensions? If the answer is the second one, what are my alternatives? Can I do what I want by working on FAST version 7 or any other version of FAST?
Thanks a lot in advance!
Nikos Mantadakis
Dear Nikos,
What do you mean by “combined floating systems”?
You should never change the *_Types.f90 files manually, as these files are auto-generated by the FAST registry as part of the build process. Instead, change the corresponding registry input file (*_Registry.txt) and associated module-level and glue-code-level source code that makes use of these data types. I would definitely recommend changing OpenFAST rather than FAST v8 or FAST v7.
The substructure for a floating wind turbine has historically been modeled in FAST as a rigid body with hydrodynamic loads lumped at a point, which enables the tool to predict the global response of the floating substructure but not the structural loads within its individual members. But please be aware that we are currently working on the implementation of floating substructure flexibility and member-level loads into OpenFAST to enable the design and optimization of floating substructures–especially next-generation floating wind technologies that show promise to be streamlined, flexible, and cost-effective. While this functionality is not yet available, you can read about the work in our recent paper published and presented at IOWTC 2019: nrel.gov/docs/fy20osti/74380.pdf. More recently, we presented on the theoretical details of the implementation at DeepWind 2020, but this paper is still under review before publication. In this work, we’re modeling the structural dynamics of floating substructures via an extension of the SubDyn module and the hydrodynamics through an extension of the HydroDyn module. The HydroDyn module changes do not include the “genaralized modes approach”, but they do include multiple potential-flow bodies (the so-called “N-Body” option in WAMIT).
Best regards,
Dear Nikos,
The paper associated with the DeepWind presentation mentioned in the prior forum post has now been published as an NREL technical report: see: nrel.gov/docs/fy20osti/76822.pdf.
Best regards,
Dear Jason,
First of all, I want to thank you very much for all your feedback and also give my real apologies for not replying to your previous answer!
I would like to further specify you what I want to do: I want to conduct a Wind-Wave analysis for a wind turbine connected together with several WECs. For this purpose, I want to consider this configuration as a single body with N DOFs. In this way, I will consider the 6 DOFs of the turbine’s platform as the rigid DOFs and the relative motions between each WEC and the turbine’s platform as flexible N-6 DOFs (the analysis procedure will resemble to this of a flexible spar). The reason that I want to try this approach through my PhD thesis is that I believe that the computational time will be decreased.
I have downloaded the OpenFAST version 2.3.0 and I still have the same problem, which is that when I change the Registry files (e.g. Registry_Types.f90 and Registry.txt) and try to rebuild the solution, an error message appears and I am asked to reload the Registry files as they were before my changes. Therefore, I have the following questions:
-
Both in the FAST v8 and now in OpenFAST I change both the Registry_Types.f90 and the Registry.txt files together with the associated modules. However, what is the “glue-code-level source code”? (Apologies if this question is trivial).
-
Both in the Registry_Types.f90 and the Registry.txt files I set the matrices’ dimension that I want to extend as N instead of 6 (in my case N is the total number of DOFs, which it will be given by the user and is read at the start of FAST’s extended code). Is there any possibility that this causes the problem? Maybe should I give as dimension the number of DOFs directly (e.g. 10)?
-
As I see at the paper that you sent to me on October 1st, analysis can be conducted for 6xN DOFs, where in your case N stands for the number of bodies. Is this possible in the OpenFAST version 2.3.0 that I have downloaded or do I need a newer version? I ask this because in FAST_Prog.f90 module, in line 40, a variable called NumTurbines is set to one (1). Could be set as greater than one (1) and take in this way into consideration the extra bodies that are mentioned in your paper?
-
If I am doing something wrong, then if I fixed it, can I apply the methology that I want also to the previous versions of FAST (e.g. FAST v8) ?
-
Even if there is no possibility to extend the equation of motion in the way that I wanted to, can I utilize the multi-body option that you added in OpenFAST and consider the DOFs of the extra bodies (e.g. in my case the WECs) as flexible ones?
If any of my questions remains unclear to you, please let me know.
Thank you very much in advance for your time!
Kind Regards,
Nikos Mantadakis
Dear Nikos,
Here are my answers to your questions:
-
As I said in my post dated Jul 14, 2020 above, you should never manually change the *_Types.f90 files. Instead, you only change the corresponding Registry (*_Registry.txt) file. The *_Types.f90 files are autogenerated by the registry based on the information in the *_Registry.txt files. By “glue code”, I mean the FAST library source code contained in the following source files: FAST_Lin.f90, FAST_Mods.f90, FAST_Solver.f90, and FAST_Subs.f90.
-
Which matrices are you trying to extend? Are you adding structural DOFs to the ElastoDyn module or something else? Do you expect to apply hydrodynamic loads to these extra DOFs by also changing the HydroDyn module? What you are proposing is likely a highly involved task. And I would recommend that you take advantage of the new capability for modeling floating substructure flexibility and member-level loads (perhaps with enhancements, if needed), rather than starting from scratch.
-
No, the new capability we’ve added for modeling floating substructure flexibility and member-level loads has been developed as a branch of OpenFAST and has not yet been migrated to the master branch. A pull request to migrate this new capability into the dev branch of OpenFAST has been initiated–see: github.com/OpenFAST/openfast/pull/537, but reviews are still being made and bugs are still being worked before this version is accepted into dev and eventually promoted to master. Variable NumTurbines in FAST_Prog.f90 is quite different altogether, used by FAST.Farm and the CFD wrappers to OpenFAST for modeling multiple wind turbines in a wind farm. It doesn’t sound like you should change that.
-
OpenFAST is built on FAST v8, and so, there are many similarities between the two. However, the FAST v8 code development has ceased and all current code development is in OpenFAST, so, I would focus on OpenFAST.
-
Yes, this is what I am recommending in (2). I’d probably have to understand more how you want to model the WECs to provide additional guidance.
Best regards,
Dear Jason,
Thank you very much for all your comments. There have been pretty enlighting. Please see below further information about which matrices I want to extend:
-
I want to extend the matrices of Mass, Hydrostatic Stiffness, Added Mass and Radiation Damping of the wind turbine’s platform. For example, if there is a wind turbine and 2 heaving WECs, I want to consider these WECs as connected to the turbine’s platform, configuring a single body of 6 DOFs (i.e. the real DOFs of the platform) plus 2 extra (flexible) DOFs which represent the relative motion between each WEC and the platform. As a result, the hydrodynamic problem will be solving an 8X8 equation system instead of a 6X6. Is it possible to do such by extendig the current version of either OpenFAST or FAST v8? If the answer is positive, can I do such by using a new variable containing the number of extra DOFs that the user wants or should I use directly the number of extra DOFs (e.g. 2)?
Please note that the wind turbine will still be rigidly connected to the tower (I am not going to change anything at the superstructure).
-
My second question is if you could inform me about when (approximately) the newer version of OpenFAST having the multi-body option will be officially released.
Thank you very much in advance!
Kind Regards,
Nikos Mantadakis
Dear Nikos,
Here are my answers to your questions:
-
So, how do you envision these addition (flexible) DOFs be specified? Are they beam elements, mass-spring-damper elements, or something else? Are you expecting hydrodynamic loads to be applied to these extra DOFs through a generalized modes approach, or can they be specified with the N-body approach or a strip-theory approach? In the new capability we’ve added for modeling floating substructure flexibility and member-level loads, the addition DOFs (beyond the 6 rigid-body DOFs) can be specified in SubDyn as Craig-Bampton modes from a reduction of the beam finite element model of the substructure (in addition to beams and cantilevered joints, rigid link elements, pretensioned cable elements, and various joints (revolute, universal, ball) have also been added). And the hydrodynamic loads can be applied via the N-body option or via strip theory. Are these features satisfactory for you or do you need something else?
-
The initial pull request has been made (linked in my prior post) and the upgrades are still in the process of being verified and validated. I suspect this process will extend through the next month or so, with a release sometime in November.
Best regards,
Dear Jason,
Thanks a lot for your prompt reply.
Firstly, I want to utilize the generalized mode approach. As for the new release sometime in November, I will also conduct the same analysis using it.
Therefore, my question for the time being is whether I am able to achieve the generalized mode approach using the current version (2.3.0) of OpenFAST.
Thank you very much in advance.
Best Regards,
Nikos Mantadakis
Dear Nikos,
The generalized modes approach is not supported in either OpenFAST v2.3 (or v2.4), or in the new capability we’ve added for modeling floating substructure flexibility and member-level loads. (We chose instead to implement the N-body approach in the new capability.) Adding the generalized mode approach would require a large change to the source code. You may want to consider using the N-body approach we’ve added in the new capability instead.
Best regards,
Dear Jason,
I do understand that the generalized modes approach is not supported by FAST and that if I want to go with it, then I have to do a lot of work on the source code. However, irrespectively of the amount of work that I a have to do, my question is if you believe that following the procedure I mentioned in my previous replies, I will be able to extend appropriately the FAST’s code. After that, I am going to compare my results to these of the upcoming release of FAST containing the multi-body option.
I am looking forward for your response.
Best Regards,
Nikos Mantadakis
Dear Nikos,
I’m sure it is possible to add additional DOFs and the generalized modes approach to OpenFAST, with work. If you intend to make such a change to the source code, I would recommend starting with the version where we added our capability for modeling floating substructure flexibility and member-level loads (github.com/OpenFAST/openfast/pull/537), rather than starting with an older version.
As you could probably tell based on my prior comments/questions, I’m not sure I’ve fully understood how you intend to make the changes you are proposing. I’ve summarized the changes I would expect to be required at a very high level below:
- SubDyn – This is where you should add the new structural DOFs you want (mass-spring damper elements?). This would require changing the input file/processing, adding DOFs and associated equations of motion, ensuring that these additions are compatible with the underlying reduction approach used by SubDyn (Guyan reduction, Craig-Bampton reduction, and Static Improvement Method), and modifying the input and output meshes (to ensure that the motions of the new DOFs are output and the hydrodynamic loads applied to the new DOFs are input).
- HydroDyn - This is where you should add the new hydrodynamic models you want (generalized modes approach). This would requiring changing the input file/processing, changing how the WAMIT data is processed to compute hydrodynamic loads, and modifying the input and output meshes (to ensure that the motions of the new DOFs are input and the hydrodynamic loads applied to the new DOFs are output).
- Glue Code - This is where the coupling between the new inputs and outputs in SubDyn and HydroDyn (fluid-structure interaction) would occur. Assuming you don’t add new meshes (instead, only modify existing meshes), you may not need to change anything here.
Best regards,
Dear Jason,
Thank you very much for your comments. There have been very helpful! I will start based on what you told me and in case of any serious problem, I will ask you again.
Thank you once again!
Kind Regards,
Nikos Mantadakis
Dear Jason,
Following the conversation we had around 1.5 year ago, I did change properly for my case the source code of OpenFAST and now I am in the point of my PhD that I should run the first analyses. However, I still have some issues.
Specifically, although I managed to solve all the issues during the Debug procedure, the following error pops up:
"fatal error LNK1181: cannot open input file ‘C:\Users\Nikos Mantadakis\Desktop\openfast-2.3.0 - change - BACKUP - Copy\build\bin\Registry.lib’ LINK. "
Unfortunately, I can not find this “Registry.lib” file anywhere in the OpenFAST documentation I downloaded.
I tried to rename some already existed libraries to “Registry.lib” just in order to see if the message will vanish. Indeed, when I do such, the solution is built, however when I run the .exe of OpenFAST, several errors come up when it comes to HydroDyn part execution (I attach in the current e-mail a relative screenshot of these messages).
Thus, my questions are two:
-
Is it possible that these errors are due to the wrong file “Registry.lib” that I renamed? (I believe that ‘yes’ is the obvious answer to this question, but I also want your opinion) and
-
Where/How can I find the correct “Registry.lib” file?
Thank you very much in advance.
Sincerely,
Nikos Mantadakis
Nikos,
The OpenFAST Visual Studio solution should not be trying to link Registry.lib into the main executable. There was an OpenFAST pull request that addressed this problem: Update Visual Studio build files for newer versions of Visual Studio by bjonkman · Pull Request #510 · OpenFAST/openfast · GitHub.
If you don’t want to pull that code, you can modify the OpenFAST project’s build dependencies using the instructions here: Build issue · Issue #509 · OpenFAST/openfast · GitHub
Dear Bonnie,
Thank you very much for your prompt and enlightening reply! I will try in the ways you proposed me and if I have any further problems, I will let you know.
Sincerely,
Nikos
Dear Jason/Bonnie,
After making some new changes in the code, it seems that the run goes a bit further. However, I still have issues. Specifically, the following message pops up:
“forrtl: severe (408): fort: (11): Subscript #2 of the array PTFMADDEDMASS has value -842150451 which is less than the lower bound of 1”
After a search that I made in internet, I found some information about several properties that I should change (so called “fertilizers”), but I am not sure what exactly I should do. Can you please give me some feedback?
Thank you very much in advance.
Sincerely,
Nikos Mantadakis
Dear @Nikos.Mantadakis,
I’m not sure how you changed the source code, but PtfmAddedMass is a 6x6 matrix input to the ElastoDyn module. From the error message, it sounds like you’ve set an index to this array outside of the bounds (both indices must be between 1 and 6).
Best regards,
Dear Jason,
Since I am trying to extend the source code of OpenFAST in order to run the analysis of a turbine together with a WEC by utilizing the generalized modes approach (e.g. Newman, 1977), I am changing the dimensions of all the relative matrices (the maximum of the indices should now be 7 instead of 6). Therefore, I suppose that the dimension of the matrix would not be a problem (PtfmAddedMass relates to the turbine’s platform, whose matrices’ dimensions I have already changed). Is there any possibility that something else goes wrong, such as specifical parameters of the Debugger that I should change inside the Visual Studio’s environment?
Best Regards,
Nikos
Dear Jason,
I have just found out a way to surmound the problem we discussed before. The problem was in the nodes when assemblying the turbine’s platform with the tower. Anyway, a new problem came up. Now the run seems to proceed but something goes wrong with the torque and pitch control (for your convenience I attach the relevant screenshot)
The truth is that for the time being, some of my inputs are random, just to see whether the new code is going to run or no (however the input I believe that it is not irrational). Is there any possibility that the problem derives from that or what else? In general, I do not know what to do, so any hinge from you would be very helpful!
Thak you very much once again!
Best,
Nikos
Dear @Nikos.Mantadakis,
The error you show is not with the controller; rather, the error is regarding the ED_HD_InputOutputSolve, i.e. in the coupling between ElastoDyn and HydroDyn. Are you getting this error from the original source code or after you made changes?
Best regards,
