I have a few questions regarding the FAST development source code and its repository.
a. Is this the location of the FAST source code development repository: github.com/NWTC?
b. Is the source code of the latest version of the standalone AeroDyn module and the AeroDyn source code within the latest version of FAST identical? In other words is the code here: github.com/NWTC/FAST/tree/maste … es/AeroDyn?
c. Same question as above but with respect to all other modules, especially ElastoDyn.
d. At the moment the FAST (and respective standalone module) source code generates an executable file. Have you considered creating a dll of FAST (or FAST modules) and then exposing the main coupling subroutines?
e. According to slide 53 of this document: wind.nrel.gov/public/jjonkman/P … onkman.pdf there are tasks remaining to establish a development community. Have you made progress on any of these?
Here are my answers to your questions:
a. Yes, although we may be moving to github.com/openFAST at some point.
d. Yes we’ve talked about this, but have not really pursued it.
e. We’ve transitioned from SVN to github for source-code control as part of the transition to the open-source developer community. Most of the to-do items identified in the presentation we will be working on this coming year. We do have some money for work in this area.
We have made some modifications to a local copy of the AeroDyn source code to couple it to our own software that is currently under development.
We intend to make this software publicly available shortly.
To honor the Apache 2.0 software license terms we believe the best way to share our source code changes would be to make a branch on your git repository (github.com/NWTC) and push the changes here.
Is this approach suitable for you or can you advise an alternative?
I think the approach you propose is fine for now. Please let us know when your changes are ready for us to review.
We are working to make the open-source community around FAST-development much more vibrant. A new github repository is being developed to support this: github.com/OpenFAST/OpenFAST (still a work-in-progress). While the approach for general developers to contribute source-code changes has not been fully fleshed out, the approach will likely involve (1) forking the OpenFAST repo to your own github organization, (2) pushing your changes their, and (3) doing a pull request to inform us that your changes are ready to be reviewed and included in the main OpenFAST repo. Details will be forthcoming.
Our changes are ready for review now. We have been working from AeroDyn source that we downloaded as an archive from the AeroDyn site: (nwtc.nrel.gov/AeroDyn) as version v15.02.04.
We wish to add one file (AeroDyn_Link.f90) and modify another (AeroDyn_Driver_Subs.f90) (see Source.zip (10.7 KB))
We made the following changes to AeroDyn_Driver_Subs.f90:
Thanks in advance,
Thanks for sharing your source code. From my quick look, it looks like the change to AeroDyn_Driver_Subs.f90 is minimal. And AeroDyn_Link.f90 seems to be some sort of AeroDyn wrapper to replace AeroDyn_Driver.f90 for interfacing AeroDyn to some other software. Am I correct?
The AeroDyn driver is meant to be a simple code that calls AeroDyn for running in standalone mode. When coupling AeroDyn to another software, it is often easiest to simply call the AeroDyn routines e.g. AD_Init, AD_End, AD_UpdateStates, and AD_CalcOutput by the other software directly. Is there a reason you modified the AeroDyn driver rather than just call the AeroDyn routines directly?
Regardless, AeroDyn_Link.f90 seems to useful only for interfacing AeroDyn to your other software. It may make more sense for you to distribute AeroDyn_Link.f90 with your software rather than with AeroDyn itself. What do you think?
Yes, AeroDyn_Link.f90 is a modification of AeroDyn_Driver.f90 which effectively splits the main program into separate subroutines. It adds no real functionality to AeroDyn and is a wrapper as you suggest.
So yes, I’m pretty sure we can simply ship the source files with our own application as you suggest.
Dear Jason Jonkman, Ph.D.
I wish you a successful New Year. I have here some different results for the FEAMooring. I would like to test Certification Test #23 with FAST_v8 and with latest version OpenFAST. From the figures it is apparent that, for MaxIter=100 (representing Maximum number of static iterations) OpenFAST will fail.
I already increased the number of MaxIter, i.e. 1000. And then, convergence problem is solved with the number of final iterations = 676. I also compiled the codes on Windows with using Microsoft Visual Studio from NREL-supported OpenFAST simulation code. As you see, (figure -d), I have a different number for the iteration.
Could you recommend me any Configuration Properties for the compiling options?
Thank you for your help in this matter.