Controller (DISCON) distribution

[rafmudaf]

The DISCON controller libraries are currently distributed through GitHub Releases for Windows. However, they are not distributed for Linux and macOS. What is the preferred method for distributing these library files? How should this relate to ROSCO controller files?

Package Managers

OpenFAST glue code is distributed through conda for macOS and Linux and Homebrew for macOS. The module drivers are distributed only through conda for both platforms. At the moment, OpenFAST is distributed for Apple chips only via Homebrew. Given these ecosystems, it would be ideal to also install the controller libraries in this way either as a separate target or included in the openfast targets. One difficulty is that then users would need to either update their ServoDyn file to point to the installed location which can be tricky to find or copy the file to their case folder.

GitHub Release

This is straightforward, but it has been nice to have only Windows related things on GitHub Release for simplicity. Another thing to consider is we'll need to include Apple chip binaries. Also, macOS will add the com.apple.quarantine attribute to downloaded binaries so we'll have to add instructions on removing that: xattr -d com.apple.quarantine <path_to_library>. This is simple, but it's another thing that users need to do.

[rafmudaf]

cc @deslaughter @andrew-platt @dzalkind

[rafmudaf]

@dzalkind and I spoke about this last week and debated whether it's worth moving entirely to using the ROSCO controller with OpenFAST. ROSCO is already compiled and distributed through conda via conda-forge for all operating systems, but I don't see a specific osx-arm64 label.

@andrew-platt @deslaughter do you have any input here?
@deslaughter could you comment on the complexity of building for Apple Arm chips with conda-forge? Is it simply finding the right toolchain?

[rafmudaf]

Of course, one major part of this would be to create the ROSCO input file that is equivalent or as close as possible to the existing controllers.

[rafmudaf]

I just want to clarify what I mean by "moving entirely to using ROSCO". This would not involve any change to the OpenFAST code, but it would involve guiding users to install ROSCO directly. It's entirely a documentation thing. Currently, we have poor documentation for how to obtain the controllers on all platforms. I'm suggesting that we consider writing documentation for installing ROSCO either as a required or optional dependency of OpenFAST.

[deslaughter]

If OpenFAST is going to use the ROSCO controller, could we just add it as a module so that it gets built and distributed along with the rest of OpenFAST? Or add it as a submodule? I think it will be confusing to ask users to download and install a separate repository to get the controller to run the regression tests. On the other hand, distributing everything through Conda-Forge would be pretty easy, just add a dependency in OpenFAST so that ROSCO gets installed with it.

Adding support for Apple Silicon is trivial, at least it was for OpenFAST (conda-forge/openfast-feedstock#33). There's an article about it at https://conda-forge.org/blog/posts/2020-10-29-macos-arm64/, and essentially it requires adding the following lines to conda-forge.yml:

build_platform:
  osx_arm64: osx_64
test: native_and_emulated

OpenFAST also needed to add a flag to link with libquadmath, but I don't think ROSCO uses quad-precision variables so it wouldn't apply.

[dzalkind]

Thanks for the tip, @deslaughter! I'm struggling a bit on the conda-forge side of ROSCO. Once that's settled, I'd be happy to figure out how to package it with OpenFAST. Adding it as a dependency sounds the most straightforward, but I'm not aware of all the potential consequences.