See Holierhoek et al. (2013).

There will need to be a measure of the distance from the end to each actuatorLineElement.

Forces should only be added every time step.

In its calculate method, the relative velocity needs to be calculated such that if the upstream velocity is in the chord--span plane, the angle of attack is zero.

Should write at end

Could give Strouhal number as input in dictionary.

A simple linear regression could be a good first guess.

Lots of leftover stuff in there from rotorDiskSource.

Should be actuator lines, created with createStruts method.

Will need to identify distance to end elements for actuator line sources.

Need to finish #18 first

Similar to how frontalArea is computed, we can simply use the max radius from the blade geometry, rather than defining it in the dictionary explicitly.

Would be nice to be able to easily obtain characteristics as a function of angle of attack and Reynolds number. How would this be stored though?

Should coefficient data be entered as an argument here? We should plan for a future Reynolds number correction model (#13). That model could act upon the static data before being sent to the dynamic model.

However, The coefficient data could be sent to the dynamic model upon construction, but it will still need to correct various constants for Reynolds number effects, e.g., S1, S2, and alpha1 for the LB model.

Add the modifications from Sheng et al. (2008) that are described in Dyachuk et al. (2014).

Need to access deltaT.

Currently only one profile can be used per actuator line, which may be a problem for axial-flow turbines in particular. It could be possible to do this without any blending.

Currently, each blade (actuatorLineSource) will write its own force field, but it would be good to see them all combined. This may require that actuatorLineSource has a method to access its force field rather than its force vector only.

Both axial- and cross-flow turbines do essentially the same thing(rotate, addSup), except for their createBlades method and the existence of shafts, towers, struts, etc.

This should be included in airfoil tables and in the actuator line and actuator line element objects.

Probably due to incorrect orientation.

Should implement the Sheng-Galbraith-Coton modified version as well, maybe as a different model altogether.

Now that the actuator line can inject turbulence, the turbine AL models should also. We will need an addSup method that takes a scalar field equation argument, which also rotates and calculates performance for the turbulence generating actuator lines. This multiplies the amount of calculations by the number of source terms, but shouldn't be too bad resource-wise.

This will also be read from fvOptions, creating a group of turbines. Will have its own performance metrics. Maybe should have a supercontroller to change turbine operating parameters to optimize array performance.

Put amplitude and phase in dictionary. Of course it would be better to have a generator model, but this could suffice if the fluctuations are know a priori.

Need to calculate torque, C_P, C_D, etc., print to Info, and write to file with writeData().

Use corrections from CACTUS first.

Something to place inside constant/dynamicMeshDict that will modulate a rotating mesh region based on the torque on surfaces inside, along with control parameters of a generator. Should write electrical performance.

For example, chord_.

Use local mesh size to find the epsilon parameter based on recommendations from SOWFA.

No idea what this would entail, but using an actuator line model would certainly be a relevant part of wind plant optimization.

Technically the turbulence model accepts other types of fvOptions besides sources.

Continuing from #9, we need to know how much k and epsilon should be injected based on the foil performance.

Use an actuator line with coefficient data from a cylinder.

Could lookup C_l and C_d for a section based on more parameters, e.g.:

• Reynolds number
• Pitch rate
• Local turbulence quantities

First will be modified Leishmann-Beddoes.

See implementation in Murry and Barone (2011), where it is called the Boeing-Vertol model.

This is a swept surface blade element model, where rather than rotating blades, the average force is constant in time, which is useful for steady state solvers, e.g., simpleFoam.

writeData seems to be reserved for all fvOptions to write their coefficients.

Unless OpenFOAM does this first, then turbulence generation can be handled with their models.

See the crossFlowTurbineAL tutorial. On one half of the rotation, the force vectors are reversed.

Would write something like

time,u_rel,alpha, cl, cd

in postProcessing/actuatorLines/{startTime}/{name}.csv.

If encountering stall, e.g., inject lots of k. Will need to identify which equations are being input to addSup methods.

Should be more descriptive.