SOWFA code reusability: why only one class ?

[Prabs8815]

Hello all,

It has been a while since i am trying to understand, simultaneously work with SOWFA and using openFOAM 2.0. I am trying develop one more turbine model using libraries of SOWFA but this is requiring me to completely modify the dimension of the arrays (DynamicLists) of different variables and the code instances where these variables are used in SOWFA. Since my current aim is only to model and play with the turbine part all the extra features which SOWFA has to simulate a whole farm with ABL are irrelevant at the moment. Here the issue is, since the whole code is organized in such a way that turbine array is the object of horizontalAxisWindTurbineALM.C class, all the member functions and object instantiations including the points on actuator line are accessed through a multi dimensional array with three/four dimensional indices. With this background information, i kindly request the feedback of the community on the following,

1. In the aspect of code re-usability, if one tries to re-code it as 4 separate classes for turbine array, turbine, blade and points will one still be able to use the variables/ member functions of SOWFA ? (with changed array/list dimensions) What might be the challenges with this approach, if the ultimate plan is to merge the re-coded part to original SOWFA solvers for performing ABL farm simulations ?

2. Is there any simple working turbine model available from initial code revisions of SOWFA which doesn't use any member function like findControlProcNo and rather calculates the forces corresponding to all the control points in one processor ?

3. I have observed that SOWFA-6 is in dev-branch, apart from making it as one solver, may i please know what other improvements are you planning to do specifically related to the turbine models ?

Would be looking forward for your comments and recommendations. Thank you and keep SOWFAing !!

[petebachant]

Note that this is why I ended up writing turbinesFoam, along with the ability to use actuator lines in the fvOptions framework to put them into OpenFOAM's built-in solvers. It would be great to unify the two though. turbinesFoam has classes for turbine, actuator line, actuator line element, which could be reused in a turbineArray class.