OpenTurbine Development Plan (FY23 Q2 Milestone)

[michaelasprague]

Creating a preliminary OpenTurbine development plan is an early milestone in the project (FY23 Q2); the target in the current funding is land-based wind, the the software needs to be positioned for expansion to floating offshore wind.

Milestone: Complete development plan for OpenTurbine for land-based wind:

• choice of programming language
• pathway for GPU-based simulations
• software requirements
• application programming interface (API) design
• use cases
• benchmark/verification/validation simulation cases
• key numerical algorithms for time integration and coupling of structural and control modules
• baseline mathematical models for a simple land-based turbine
• minimal/baseline set of requirements for turbine definition

[ashesh2512]

Regarding input file parsing, what are the options currently being considered? Yaml tends to rely heavily on indentation, and with nalu-wind, we are already noticing that it is easy to be "careless" and run into syntax errors which are difficult to track down as the complexity of the input file increases. Is creating our own parser an option?

[rafmudaf]

I agree that complex file structures can be cumbersome in yaml files. However, it is a fairly ubiquitous file format with an ecosystem of tools for construction and validation including schemas for validating key-values pairs and data types.

I suggest we identify the content for the OpenTurbine input file outside of the context of the file format. If it is complex and there's good reason for the complexity, I'm open to some sort of custom parser. Otherwise, I will push for using a typical file format with an existing processor so that we can largely avoid having to recreate yet another input file system.

[faisal-bhuiyan]

@ashesh2512 @rafmudaf I am familiar with a JSON based input/output parser using this library, however, I don't think it's much different than a YAML based library. Could you guys tell me a little bit about the existing infrastructure for handling IO code in ExaWind (i.e. serialization and deserialization)?

Also, I can look into identifying the contents for the OpenTurbine input file and report back here.

[ashesh2512]

Here is an example of the IO mapping that would be needed to interface with designs used in the community - https://github.com/IEAWindTask37/IEA-15-240-RWT/blob/master/WT_Ontology/IEA-15-240-RWT.yaml

[jjonkman]

Have you considered programming language capability that supports automatic differentiation--so as to automatically calculate the Jacobians needed for stiff time integration and linearization of the structural equations of motion?

[ashesh2512]

Seconding Jason's point, we should look a bit into this - https://github.com/autodiff/autodiff

[michaelasprague]

We have been considering this, but we've pretty much locked on to C++, which has libraries like that mentioned by Ashesh.

It is still an open question to me if there will be a speed advantage for the particular operators here that auto differentiation will provide a run time speed advantage over analytical Jacobians (though there's clearly a development speed advantage).

[faisal-bhuiyan]

@michaelasprague A quick clarification question - for analytical Jacobians, is your vision is to pre-compute them (via some Python package or Julia) and supply them to the cpp source code? If this is the case then we will need only the spatial derivatives of the shape functions of the elements we will be implementing, correct?

[michaelasprague]

Analytical jacobians in the sense describe here would be derived "by hand" (as in BeamDyn), and not via auto differentiation. It is much more complicated than just derivatives of shape functions.

[faisal-bhuiyan]

@michaelasprague I think the above will definitely produce faster run times. However, imo, we should spend some time to automate the analytical Jacobian calculation via a Python script for example and verify some cases with hand calculations to make our lives easy and reduce the chances of making errors.

[faisal-bhuiyan]

Scope and breakdown of work for application programming interface (API) design task

Relevant discussion from the FY23 AOP for OpenTurbine regarding the scope of this task:

• Task 3.3: Application Programming Interface (API) definition:

  • This task will finalize and communicate the internal and external APIs in OpenTurbine.
  • The APIs will be documented and included as part of the Developer’s Guide in Task 1.2.
  • Examples of using the external APIs to couple with other models will be included. A focus will be on ensuring that OpenTurbine is seamlessly coupled to other WETO models such as ExaWind CFD codes (amr-wind for actuator-line based turbine representation and nalu-wind for blade-resolved turbine representation) as well as OpenFAST.

Breakdown of work for overall Application Programming Interface (API) design task:

• Should we opt for yaml based input files?
  -> The 15MW RWT definition based on yaml is huge - there might be issues with parsing such large yaml files. The idea of a home-grown parser following AMReX might be useful here.
  -> Is the 15MW yaml file and example of a new standard? This will likely be discussed at WESC and there may be push for broader adoption.

  • To start things off, we could have a small input file, but will likely need to expand approach later to handle full-turbine yaml file - either straight from yaml or build/transfer for our own parser.
  • We could still use our own yaml format; we will likely need a pre-processor to translate, e.g., the 15MW RWT file to OpenTurbine format (seems the likely candidate at this point).
  • We can start creating some yaml input files for early test cases? E.g., beam under tip load

• Backend design: general flexible multibody dynamics code with a time domain solver
  -> We need an input file format for the FEA solver (separate from the one described in next task)

  • Need to define an FEA input file schema

• Frontend design: We will need to run OpenTurbine stand-alone simulations and CFD coupled simulations -> User input file and coupling with CFD codes

  • Need to define a user-facing input file schema (containing description of turbine-components, material-properties, mesh controls, loads and bcs, solver-controls, outputs etc.)
  • Need to couple with CFD via actuator-line and blade-resolved turbine representation
    -> What is there now in amr-wind and nalu-wind? What data is passed (in space and time)?

• Documentation for internal API
  -> We could leverage Doxygen for it, as established in this PR for OpenTurbine.

@michaelasprague @rafmudaf @ashesh2512 - let me know if the above breakdown looks reasonable to you guys.