Discussion on repository name and python vs matlab

[ebranlard]

We have more and more python-scripts available to deal with OpenFAST simulations, but no repository for it. Some options would be to either:

1. Create a python-toolbox repository
2. Rename matlab-toolbox to openfast-toolbox. Then we could either gather code by: 2.1 language (e.g. a folder matlab and a folder python at the root 2.2 functionality (e.g. folders io , mbc, areoacoustics, preprocessors.

If you think of other options, I can add them to this post. I'd be happy to hear the opinion of people listening to this channel (for instance: @bjonkman, @andrew-platt , @jjonkman , @ptrbortolotti, @nikhar-abbas, @gbarter, @kshaler, @evan-gaertner, @ewquon)

Hopefully we can come up with some kind of consensus on what to do about matlab/python. Then I'd suggest we sit down and decide on an architecture. On the python side, I'd like to aim for a repository with unit tests and continuous integration, and a couple of examples. Hopefully we can find a balance between adding a lot of inconsistent scripts and having a too restrictive framework that no one dares using or pushing to.

I believe the repository should stay fairly small and OpenFAST-focused: read/write files, generate cases, postprocess them. Some of these steps might involve generic tools, which we can extract from other repositories without actively developing on them. Otherwise things might run out of proportion.

But that's already too much details.. I just want to start a discussion on where to put our python scripts. Let me know your thoughts.

Examples of repositories with potential overlap

• DTU Wind energy toolbox https://gitlab.windenergy.dtu.dk/toolbox/WindEnergyToolbox
• ROSCO_toolbox https://github.com/NREL/ROSCO_toolbox
• WISDEM https://github.com/wisdem/wisdem Some of my repos that I'm happy to move around:
• Wind energy IO: https://github.com/ebranlard/weio
• FASTlib: https://github.com/ebranlard/welib/tree/master/welib/fastlib and more

[ewquon]

For too long, I’ve had too many personal and group repositories for different projects, and at some point Matt C, Paula, Paul F, and I had all separately talked about creating a repository of wind tools. On my end, I already have python tools in https://github.com/NWTC/datatools and https://github.com/a2e-mmc/mmctools

As a side project, I’ve been (slowly) working recently on consolidating all of these tools while developing new capabilities. I think this would be a good home: https://github.com/NREL/windtools

• It has a good, easy-to-remember name
• It lives under the public NREL github organization, which is apparently preferred over the NWTC organization (I am told)

I think the structure would be something like this:

• windtools.common
• windtools.SOWFA6.*
• windtools.nalu.*
• windtools.openfast.*
• etc...

My $0.02.

[ewquon]

And if there are any concerns about "I'm an XYZ engineer, and I use tool A; why do I need tools B, C, and D?" then I would consider windtools to be a wind engineering analog to a python package like scipy.

[jjonkman]

I agree that there should be a central repository for python scripts used in conjunction with OpenFAST. I would not touch the MATLAB toolbox, which is mostly maintained by @bjonkman, but create a similar one for python...ideally with a similar set of functionality. If this new python toolbox is not hosted on https://github.com/OpenFAST, then it should at least be linked to from https://github.com/OpenFAST.

[bjonkman]

I don't have strong opinions on how NREL organizes this, but I will add a few things to consider.

• I personally find the number of repositories and their current organization on https://github.com/NREL to be overwhelming, so I would very much appreciate an obvious link from https://github.com/OpenFAST. If people don't know the repo is there, they won't use it.

• If the Matlab and python tools are consolidated into a single repository, I would want them to be somewhat in-sync (e.g., w.r.t. OpenFAST version compatibility). If people aren't familiar with both toolboxes and both languages, that might be a pain.

• Engineers and researchers tend to want to make their own versions of plotting tools (and sometimes reading, too). People like to customize how they see and use data, and it's often easier in the short term to write your own code than update someone else's (lets consider why there are so many different scripts now!).

I definitely think it is a worthwhile goal to consolidate these tools, but the bigger issue may be getting people to agree on what that should look like so that they will all use it. After you've agreed on the repository location, it may be worthwhile to start with a discussion on how people want the data structures organized--comparing the existing scripts--and agreeing on those common building blocks first.

[evan-gaertner]

I'll plug AeroelasticSE within WISDEM, the OpenFAST driver that we wrote for use in our aeroelastic design studies.

• It has the core capabilities that Emmanuel mentioned, reading/writing input files, changing variables values, running FAST, and processing the output
• It was previously backwards compatible with FAST7 and FAST8, this hasn't been maintained, but easily could be
• It has Case Generators, which create the test matrices of variable changes for a large studies, including scripting of a decent subset of the IEC DLCs
• Support for parallelization of OpenFAST simulations, either locally with Multiprocessing or with MPI.
• In addition to running FAST, it can similarly drive TurbSim and we wrote pyIECWind, which generates IEC wind profiles like the IECWind fortran code.

My first task at NREL was cleaning up AeroelasticSE, it was a pretty hacked together spaghetti code when I started. There are certainly opportunities to improve it further, especially with regard to documentation and examples, but I see it as a great starting point for whatever official repo gets created. Its currently a part of WISDEM, but I think we'd definitely be open to rebranding and relocating it to be more under the OpenFAST umbrella.

[rafmudaf]

Thanks for the input. Per @jjonkman's suggestion, I've creating a separate repository for a future Python-based toolset at https://github.com/openfast/python-toolbox, though it's currently empty.

I've also been working on improving the Python tools for driving the regression tests. That library is minimal as the regression test requirements are relatively simple, but it can serve as a basis for building up a more full featured Python toolbox. Once the foundation is set, I'll share it here and then we can work through establishing the data structures and building out the API.

[ebranlard]

I'm fine with the idea of a separate repository for now, with very basic functionalities, just to get people to use it to build their own more advanced scripts (like Bonnie mentioned, everyone likes their own scripts) . We can always merge this later with the matlab tools and the windtools. As long as we have something going, I'm happy :)

[ebranlard]

Hi all,

We've started adding more functionalities to the python-toolbox. There is still much work to be done to add examples, unit tests, documentation, and more scripts. Some links to the repositories mentioned in this thread are given in the README. Feel free to add more openfast scripts to the python-toolbox!