Could this be extended to 2 rotor case

[chandukec]

Hello,
Thanks for the turbineFoam, I installed it correctly in OpenFOAM 1906 with your help. Was trying the tutorials of this and wondering that could this be extended for the 2 rotor case? Suppose I had two turbines located at "x" meter with the nacelle, tower etc, is this doable from the existing version? Do I need to change the source for making this happen or how will this work? Any help or comments?

[petebachant]

Do you mean two rotors on the same tower, or two separate turbines?

I have an example case for the latter here: https://github.com/petebachant/NTNU-HAWT-turbinesFoam

For a multi-rotor turbine, you could define multiple rotors and any number of arbitrary actuator lines to represent a tower structure.

[chandukec]

Thanks for your reply. I mean two rotor (turbine) on same tower. I think as of now I am still not clear and specific in my question. Will it be fine if I keep posting queries here, or some other platform is available?

[chandukec]

Also if I am running this tutorial case https://github.com/petebachant/NTNU-HAWT-turbinesFoam, through run.py it gives me this error:
File "run.py", line 36
res[f"vel_mag_{idx}"]=row.vel_mag
Syntax Error: invalidSyntax
I am using Python 2.7.16. Is this the correct way to run this tutorial or I am terribly missing something.

[petebachant]

Sure, feel free to post here. It serves as a history if others encounter the same issues.

As for Python, that case is setup to run with Python 3. If you have the ability I'd recommend upgrading since Python 2.7 is now deprecated. I like the Anaconda distribution.

[chandukec]

Ok, thanks, I doubt that my difficulties will eat up all the spaces.:P
Meanwhile, I tried with Python3, it gives me an error which says:
Traceback (most recent call last):
File "run.py", line 8, in
import numpy as np
ModuleNotFoundError: No module named 'numpy'
Also, I think two turbine with same nacelle will not solved by this tutorial set I guess?
Could you suggest some likely tutorials that will help me to follow the two turbine with same nacelle case?

[petebachant]

I'd recommend installing Anaconda, which will include Numpy, so you don't have any issues with dependencies, or you can install the dependencies manually using pip.

For setting up two rotors, I'd say the process would be something like:

1. Create one turbine with no tower or nacelle.
2. Create another one identical, but with a different origin. You can use the macro substitution syntax in the fvOptions dictionary to copy all parameters from one, then change only the origin. Alternately, you can modify the NTNU case to create fvOptions programmatically for doing things like parameter sweeps.
3. Build some additional actuator lines for the tower, support structures, and nacelle. See the static actuator line tutorial case for how to define these.

[chandukec]

Thanks, so I started the first step (one turbine with no tower or nacelle). I am trying with the horizontal axis turbine, thus trying the tutorial axialFlowTurbineAL. Now the blade that I am using has not the uniform cross-section. I am taking some cross sections and trying the Qblade to extract the Cl Cd curves. Now, what I understood is that I had to change the blockMesh and SHM according to my need. And primarily change the fvOptions. What I understood is that:

In the fvOptions, the "nElements" refers to the number of slices takes in the blade for getting the Cl and Cd curves. And for giving the input at these locations (radial distance, twist angle), "elementData" file is there. So effectively I need to make a file similar to "elementData" in which I had to input the locations, twist corresponding to the slice. Sorry but, what is "chordMount" in this?
I am also a bit confused in the "nElements" and the number of Reynolds number defined at these elements. Can I have the input set similar of "crossFlowTurbineAL" to that of "axialFlowTurbineAL", what I mean is that could I have the varying Reynolds number and correspondingly different Cl, Cd curves etc. And the cylinder part is here to include the drag created at the root of the blade? Sorry for these set of questions. Is this the appropriate place to ask these many questions?

[petebachant]

chordMount means the location of the element along the imaginary line describing the geometry, typically the quarter chord, or 0.25.

nElements means how many actuator line elements with which to divide the geometry defined in elementData.

And yes, you can specify multiple Reynolds number airfoil data in axialFlowTurbineAL identically as crossFlowTurbineAL. Here is a sample case from another user who did that: https://github.com/hcOnel/NREL5MW-turbinesFoam

[chandukec]

Thanks a lot for your continuous help, but still I am not clear with the usage and/or terminology of nElements and elementData, I will look closely into that and ask you, is it fine?
However, I tried to run the aforementioned case with "anaconda" as you have suggested and I am getting the error:
Matplotlib is building the font cache using fc-list. This may take a moment.
Traceback (most recent call last):
File "run.py", line 11, in
import foampy
ModuleNotFoundError: No module named 'foampy'
I am not very comfortable with the Python, thus just wandering am I missing something in between?

[petebachant]

Sure, you can continue to ask questions here. No problem.

As for the missing import, that can be solved by running pip install foampy in a terminal.

[chandukec]

Thanks a lot.
Sorry, but again it throws the following error:
Traceback (most recent call last):
File "run.py", line 14, in
from pynhtf import processing as pr
File "/home/NTNU-HAWT-turbinesFoam-master/pynhtf/processing.py", line 12, in
from pxl import fdiff
ModuleNotFoundError: No module named 'pxl'

[petebachant]

Ah, yes. Any time you get an error like that, it usually can be fixed with a pip install .... In this case, use

pip install pxl

[chandukec]

Great, thanks! worked perfectly.
If instead of RANS, I intend to run the LES, so you have something particular to comment/suggestion/tutorial case etc. on LES scheme, time stepping, grid resolution etc? I think I have gone through your recent paper titled "Near-wake flow simulation of a vertical axis turbine using an actuator line model" . And in that, (please correct me), then you are suggesting that the LES scheme hardly matters.

[petebachant]

The particular SGS model does seem to have a large effect on the stability of things like tip vortices, but I'm not sure the sensitivity to numerical schemes. Typically, for LES, we use 2nd order accurate schemes, which seem to remain stable since these meshes are simple. There is quite a bit of research in the literature on simulating HAWTs with actuator lines and LES. There are some references in this paper as well: https://arxiv.org/abs/1605.01449

[chandukec]

Sorry for my unclear question. I intend to ask the suitable LES model like, kEqn, WALE, SpalartAllmarasIDDES. Also wanted you to kindly comment regarding typical grid and time resolution for LES simulations. I tried with the kEqn LES model, but could not see the Tip Vortices etc. thus wondering if some thing else is missing from my part.

[chandukec]

Sorry, I still have doubt with the ChordMount, in the previous post you have mentioned that, typically it is one fourth of the chord length, but if I look at the tutorial case you have suggested https://github.com/hcOnel/NREL5MW-turbinesFoam , then this looks very different.
Also, how is the twist calculated here, I am calculating it as:
theta/twist = atan(abs(yleading-ytrailing)/abs(xleading-xtrailing))360.0/(2.0pi);
but this value seems to be always positive, so do I need to add a negative sign or this is (180-theta/twist)? Sorry again for these naive questions.

[petebachant]

For a HAWT, 0.5 could certainly be used. If you imagine a straight line from the axis out to the blade tip defining the geometry, the chord mount defines at each cross-section the distance from the leading edge to that geometric line (the actuator line.)

Twist is calculated like blade pitch, twisting about the actuator line, minimizing angle of attack as twist increases--for a constant TSR. It is also defined in degrees.

[chandukec]

Ok, many thanks for the help and reply. With your help I am able to simulate a RANS case for single rotor and 2 rotor case is in progress (without hub, tower etc). Many thanks for it.
ChordMount=0.5 constant?, since the chord length is varying, so will it be 0.5*chordlength or fixed 0.5? I still have some doubts with the twist and will clarify once I will go through it more carefully.

[petebachant]

Yep, the chordMount is the fraction of the chord length, which can vary along the actuator line.

[chandukec]

In the tutorial case "axialFlowTurbineAL" when I intend to plot the results using "plot.py" (provided in the tutorial directory), it successfully plots the "plot_cp" and "plot_spanwise", but while plotting the "plot_meancontquiv", it throws an error which says:
File "plot.py", line 20, in plot_meancontquiv
data = calcwake(t1=0.4)
NameError: name 'calcwake' is not defined
Could you kindly help.

[petebachant]

Ah, that plotting function shouldn't really be there. This repo should have the wake plotting working: https://github.com/petebachant/NTNU-HAWT-turbinesFoam

[chandukec]

Sorry Sir, but unfortunately, using this python script only the performances of the two turbines are outputted/plotted. If I tried to plot "wake", then it complains about:
FileNotFoundError: [Errno 2] No such file or directory: 'postProcessing/sets'
And if I tried to plot spanwise then, it shows error:
File "/home/csp/OpenFOAM/csp-v1906/run/alm_trail/NTNU-HAWT-turbinesFoam-master/pynhtf/plotting.py", line 52, in plot_spanwise
i = int(e.replace("blade1Element", "").replace(".csv", ""))
ValueError: invalid literal for int() with base 10: 'turbine2.blade1.element17'
Rest also I think are not working, is some directory or files that has to be included is being missed by me? Thanks for your constant help!

[chandukec]

Any suggestion/comment on the previous problem? Another issue which is troubling me is that, when I converted this 2 rotor case from RANS to LES, the value of coefficient of power (Cp) seems to be under predicted by LES. The value of Cp from RANS is 0.4, from LES is 0.36, and from the experiment its 0.4 (for 1 turbine, similarly its same for the second turbine). I tried to use about 5 million cells, used K-eqn model for LES simulations and used time stepping close of half of the present set up. I would have expected that the results from LES much better than RANS. Have I done some thing terribly wrong? Could you kindly comment or suggest some thing in this regard.

[petebachant]

I doubt you've done anything terribly wrong, as I've seen similar discrepancies in RANS/LES Cp values. It's possible that ALM/LES is not better at predicting absolute performance of rotors, but is more geared towards studying wakes. Ultimately, lower performance could be caused by lower relative velocity at the actuator lines, or a different flow direction changing angle of attack off the optimum. I recommend digging deeper into the flow data seen by each element along with its computed angle of attack.

I will take a look at the NTNU case and see if I can get the plotting working. Feel free to raise more specific issues in that case's issue tracker.

[chandukec]

Thanks for your insight in this regard. Now I am trying with approx. 10 million cells for LES case and will update the pic in this thread . Meanwhile regarding the plotting issue, out of 9 plots, only 4 are working which are: perf, blade-perf, perf-curves and perf-curves-exp; other 5 plots like wake, spanwise, strut-perf, recover, meancontquiv are not working. Also it seems that "controlDict.recovery" is missing in the system folder. Thanks again for your continuous support and help.

[chandukec]

Just a quick and again naive query. Since I am trying to run the LES simulations using 9 million points and unfortunately after 3-4 days the simulation stops due to may be electricity failure. Thus I wanted to re-run the sims from the latest time step, is there any way to do this? I tried through these 2 ways:

1. removing log files of the meshes, re running all the utilities, changing the start time in the control dic
2. using pyhton run.py --leaves-mesh
   But unfortunately nothing works. Is some thing can be done in this regard?

[petebachant]

Unfortunately not at the moment. The actuator line modeling stuff doesn't have the ability to restart from an arbitrary time. It probably wouldn't be too difficult to implement, but I was always running simulations from zero.

As a workaround, you could copy the case to a new one and restart from latestTime, but the turbine will start from zero azimuth again unless you set azimuthalOffset for all the blades accordingly.

Definitely room for improvement there.

[chandukec]

Thanks a lot for your insight. But if my hub diameter is 1.2 m, are you suggesting to artificially putting the hub diameter something 1.3 m or so? Also I should try using the end effects on, which you have already coded in the fvOptions, I guess?

[petebachant]

are you suggesting to artificially putting the hub diameter something 1.3 m or so?

You could try it. The force tapers off like a Gaussian, so it's not a perfect representation of the true geometry.

Also I should try using the end effects on, which you have already coded in the fvOptions, I guess?

Yep, you have control over whether you want them applied at the root and/or the tip. If you apply at the root, lift will taper off there, which will decrease the strength of that vortex.

        endEffects
        {
            active          on;
            endEffectsModel Glauert; // Glauert || Shen || liftingLine
            GlauertCoeffs
            {
                tipEffects  on;
                rootEffects on;
            }
            ShenCoeffs
            {
                c1          0.125;
                c2          21;
                tipEffects  on;
                rootEffects on;
            }
        }

[chandukec]

Many thanks for your help. I will try, implement and update you.

[chandukec]

Thanks a lot for all your help. I think you already answered that "could this be extended to include the cavitation effect". But now since I am trying the tidal turbine and I need to work for the cavitation effect, could you kindly suggest what should I do to run the turbinesFoam using interPhaseChangeFoam? Will it be difficult/time taking ?

[petebachant]

Since interPhaseChangeFoam uses fvOptions, this should work out of the box. #305 could be relevant.

[chandukec]

Thanks a lot for your help and the link. This is indeed a great help.

[chandukec]

I am facing a strange issue regarding the twist/pitch. When I am using no twist condition (twist angle/pitch =0 ) throughout the span of blade it looks fine (fine in the sense that the turbulent structures are there), whereas if I am putting the twist (let us suppose the twist angle/pitch varying from -6.6 to -9.0) the flow doesn't look correct (correct in the sense that the structures seems to vanish and the flow doesn't look turbulent). Here are the two pictures of it, 1 without twist/pitch=0 and other with twist. Could you kindly suggest/comment some thing?

[petebachant]

This could be perfectly normal. If the blades are stalling, they could be imparting more force on the flow to create larger looking isosurfaces. Better to compare to experiments using Cp, Cd, mean velocity, turbulence intensity, etc., or at least be aware of the threshold and quantity of your isosurfaces to compare to other visualizations.

[chandukec]

Thanks a lot, but in other words is the "twist stopping the tip vortex from breaking down" ?

When I am trying to run the "interPhaseChangeFoam" to include the effect of cavitation, although I am not getting any errors but but it is not at all simulating any thing, the log file corresponding to it is attached herewith. I also refereed the link that you have suggested ( #305 ) but was not able to resolve that. Any suggestion/comment will be a great help.
log_interPhaseChangeFoam.txt

[petebachant]

What OpenFOAM version are you running? I've never used interPhaseChangeFoam, but the latest dev version appears to use fvOptions in the UEqn, so it should work: https://github.com/OpenFOAM/OpenFOAM-dev/blob/master/applications/solvers/multiphase/interPhaseChangeFoam/UEqn.H

[chandukec]

Thanks for the reply. I am using OpenFOAM 19.06, however it seems that the turbinesFOAM is able to recognize the interPhaseChangeFoam but not able to perform simulations properly. In addition I have some problems with the NTNU case which I am explaining in next post to avoid confusion.

[chandukec]

Coming back to the two rotor case NTNU case https://github.com/petebachant/NTNU-HAWT-turbinesFoam, there are some doubts:

1. What you think should be the minimum nelements in fvoptions, since if I am trying with only 10 then I am getting many breaks in the actuator line of the blades.
2. Sorry for asking this query multiple times, but from which axis the twist is defined, is it from the axis of rotation (-1,0,0) or from the vertical axis (0,0,1)? I am asking this since I am struggling with negative Cp value.
3. Since I am getting -ve Cp value thus I am thinking of actually printing the power values in the postProceesing folder like you are writing the Cp values, how to make this possible and how to compile it with these changes? Is it tough or doable ? Or any other easy fix for that?

[petebachant]

1. 10 seems reasonable. If you see the force field has gaps in it, it may be worth increasing.
2. If you look at the createBlades method, the blades are created vertically then rotated to their azimuth value. The twist is set to be consistent with the NTNU paper, though I have heard this may be opposite to how NREL defines it. You may need to flip the sign if the rotor rotates the opposite direction.
3. Power will be simply 0.5 * rho * A * Cp * U_infty**3. Since all are constant except U_infty in incompressible flow, dimensional power won't contain any more information. If Cp is negative, it's probably true that twist is opposite. As in 2, I recommend double checking the axialFlowTurbineALSource::createBlades method.

[chandukec]

Thanks a lot for your reply and help. I am trying to model a 2 turbines system in which one turbine is rotating in clockwise and other anti-clockwise direction (or vice-versa) and are located at a separation of 1D, my problems are:

1. Even if I flipped the twist angles in all combinations still I am getting Cp +ve for 2 turbine and -ve for 1 turbine. For making the turbine 2 to rotate in counter direction as that of 1st turbines I changed axis of rotation (-1, 0, 0) to (1, 0, 0). Reference axis for twist is troubling me a lot.
2. I tried to change the axis of rotation (-1,0,0) and vertical axis (0,0,1) but there is no change for Cp, since I found that (in src/fvoptions/axialFlowTurbineALsource.c) for calculations of Cp, power etc., the magnitude of these values are taken, not sure if I am making sense or looking it in a correct way.
3. I understand the Tip speed ratio (TSR) for turbine1 is defined asthe ratio of \omega*R and inlet velocity, but for turbine2 the inlet velocity is considered as the same that of turbine1, I think that this is based on the assumption that since the turbine1 and turbine2 are separated by 3D distance and turbine2 will feel the same inlet as that of turbine1. Am I correct? If this is true then how will I define the TSR2 for turbine2 in case when the turbines are located at the distance of D instead of 3D?
4. To find out the power, I am changing the axialFlowTurbineALSource.C to compute and write the Torque*\omega. Is this correct?

[petebachant]

I understand the Tip speed ratio (TSR) for turbine1 is defined asthe ratio of \omega*R and inlet velocity, but for turbine2 the inlet velocity is considered as the same that of turbine1, I think that this is based on the assumption that since the turbine1 and turbine2 are separated by 3D distance and turbine2 will feel the same inlet as that of turbine1. Am I correct? If this is true then how will I define the TSR2 for turbine2 in case when the turbines are located at the distance of D instead of 3D?

You're correct that TSR is always defined in terms of freeStreamVelocity, which you can set differently for turbine 2 if it is operating in a wake, or you can guess at the correct TSR. A better solution would be to model an actual rotor speed controller, but that is on the to-do list.

To find out the power, I am changing the axialFlowTurbineALSource.C to compute and write the Torque*\omega. Is this correct?

I would simply multiply the values when post processing using power = Cp * 0.5 * frontalArea * mag(freeStreamVelocity)^3.

[chandukec]

Thanks a lot for your reply and help. In the previous comment you said that
Cp=0.5 * rho * A * Cp * U_infty**3
while in this comment you described it as Cp=0.5 * A * Cp * U_infty**3 so the factor of rho is missing. If I remember correctly you explained me earlier that in the in-compressible system this won't matter, could you please extend the clarification so that I understand it better. Sorry for my ignorance.

Also I am find it difficult to include the "cavitation" effect in the case using "interPhaseChangeFoam" should I open another thread relating to this?

[petebachant]

Sorry about that. Yeah, you can assume a value of rho and use that in the equation if you want to compare to, e.g., an experiment.

I'd say for the cavitation question, it certainly makes sense to open a new issue. I'm honestly not very familiar with the topic so it may be worth asking on the CFD Online forums.

[chandukec]

Thanks a lot for your timely help. If I look at the "axialFlowturbineALSource.c" then it seems that it is looking for "rhoRef" in the input/source (not sure) as:

scalar rhoRef;
    coeffs_.lookup("rhoRef") >> rhoRef;
    torqueCoefficient_ = torque_/(0.5*rhoRef*frontalArea_*rotorRadius_* magSqr(freeStreamVelocity_));

for calculating the Cp. To calculate the value of power if I assume, \rho =1000 Kg/m^3; U_inf =2.5 m/s, R = 9.5 m (as per the input) and from the code output I am getting the Cp=0.1956, then from hand calculation I am getting Power = 433267.35 and if I am writing it explicitly in the code from:

power_=torque_*omega_
I am getting 433.48, so it's a factor of 1000 apart. I am guessing I am terribly doing wrong some where in understanding the \rho factor.

[petebachant]

If there a rhoRef defined in fvOptions?

[chandukec]

No, it's not there in fvoptions.

[petebachant]

Alright, so to be clear, rhoRef will not affect the simulation, power or torque coefficients, since the solver uses force per unit density. It is merely a reference value. If you want to know what the power would be in any given fluid, you can use whatever density you like to compute dimensional power in post processing.

If you define rhoRef in axialFlowTurbineALCoeffs, however, you should obtain the dimensional values you expect for that density. But again, there will be no effect on the flow field, so it is easier to simply multiply in post-processing.

[chandukec]

Thanks a lot for this clarification. In the same context, what will be the unit of forces (fx, fy, fz) in the "postProcessing/actuatorLineElements/0" (turbine1.blade1.element0.csv, turbine1.blade1.element1.csv etc)? Also for a single turbine and single blade, sorry but I don't understand why there be 3 time data ? I was expecting that the data for the single turbine and for 3 blades data will be there. Extremely sorry for asking these naive queries.

[petebachant]

Thanks a lot for this clarification. In the same context, what will be the unit of forces (fx, fy, fz) in the "postProcessing/actuatorLineElements/0" (turbine1.blade1.element0.csv, turbine1.blade1.element1.csv etc)? Also for a single turbine and single blade, sorry but I don't understand why there be 3 time data ? I was expecting that the data for the single turbine and for 3 blades data will be there. Extremely sorry for asking these naive queries.

Those units should be force per unit density for incompressible flow, and Newtons for compressible or multiphase flow.

For writing individual force data from each blade that need to be specified for each blade, and you'll see in some tutorials that it is turned off for blade 2 and 3 since they will be the same.

        blades
        {
            blade1
            {
                writePerf   true;  // <-- Write blade performance
                writeElementPerf true;  // <--Write element performance
                nElements   28;
                elementProfiles
                (
                    cylinder
                    S826
                    S826
                    S826
                    S826
                    S826
                    S826
                    S826
                    S826
                    S826
                    S826
                    S826
                    S826
                    S826
                );
                elementData
                (
                    #include "elementData"
                );
            }
            blade2
            {
                $blade1;
                writePerf   false;  // <--Copied blade1 but overwritten to false
                writeElementPerf false;  // <--Copied blade1 but overwritten to false
                azimuthalOffset 120.0;
            }
            blade3
            {
                $blade2;
                azimuthalOffset 240.0;
            }
        }

[chandukec]

Thanks a lot for your help. As you have mentioned that by stating the "writePerf false;" we can shut off the writing of the performance for the blades 2 and 3. But even though I am making this, it is writing the data for 3 times at a single time, I have attached the corresponding excel sheet herewith, please have a look. Sorry, I think I am missing something.

[petebachant]

Ah, yes. That is due to additional PIMPLE correctors. I couldn't find any way to tell which was the last iteration, so I had to write performance for each. The last should be taken as the actual value. If reading the data in pandas, you can do a df.groupby("time").last() to reduce the DataFrame.

[chandukec]

Thanks a lot, I should have figured that out, extremely sorry for that.

[chandukec]

Hello again, Sorry for asking this question again, I still have trouble to define the "twist", specifically I understand that the twist is the angle between the plane of rotation and the chord of the hydrofoil/aerofoil. Could you please help if it is positive or negative in clockwise direction ---viewing from the tip. Also when I am simply changing the twist angle (from +ve to -ve) I am seeing an additional/unusual tip vortex away from the tip/root (at z=-6), please see the attached figure, however in the former case (when twist = +ve), I could see nice large and small vortices. Based on my limited understanding I guess the solver is identifying the end of blades at z=-6 for -ve twist case, but strangely it doesn't while twist is +ve? Or is it possible to have these 1 + 1(tip vortices at the end of the blade at z=-9..5) usual behaviour? Any help will surely make my day. Thanks in advance.

[petebachant]

A typical turbine blade should have negative twist for most of the span, regardless of rotation direction:

// Blade element data
// axialDistance, radius, azimuth, chord, chordMount, twist
(0.0    0.0075      0.0     0.0135      0.25    0.0)
(0.0    0.049       0.0     0.0135      0.25    0.0)
(0.0    0.054999    0.0     0.0495      0.25    -38.0)
(0.0    0.0675      0.0     0.081432    0.25    -37.055)
(0.0    0.0824985   0.0     0.08011     0.25    -32.544)
(0.0    0.0975015   0.0     0.077013    0.25    -28.677)
(0.0    0.1125      0.0     0.073125    0.25    -25.262)
(0.0    0.1274985   0.0     0.0690075   0.25    -22.43)
(0.0    0.1425015   0.0     0.064953    0.25    -19.988)
(0.0    0.1575      0.0     0.061101    0.25    -18.034)
(0.0    0.1724985   0.0     0.057519    0.25    -16.349)
(0.0    0.1875015   0.0     0.054225    0.25    -14.663)
(0.0    0.2025      0.0     0.0512055   0.25    -13.067)
(0.0    0.2174985   0.0     0.048447    0.25    -11.829)
(0.0    0.2325015   0.0     0.0459315   0.25    -10.753)
(0.0    0.2475      0.0     0.043632    0.25    -9.8177)
(0.0    0.2624985   0.0     0.0415287   0.25    -8.8827)
(0.0    0.2775015   0.0     0.0396009   0.25    -7.9877)
(0.0    0.2925      0.0     0.0378306   0.25    -7.2527)
(0.0    0.3074985   0.0     0.0362007   0.25    -6.565)
(0.0    0.3225015   0.0     0.0346968   0.25    -5.9187)
(0.0    0.3375      0.0     0.0333063   0.25    -5.3045)
(0.0    0.3524985   0.0     0.0320171   0.25    -4.7185)
(0.0    0.3675015   0.0     0.03081915  0.25    -4.1316)
(0.0    0.3825      0.0     0.02970405  0.25    -3.5439)
(0.0    0.3974985   0.0     0.02866365  0.25    -2.9433)
(0.0    0.4125015   0.0     0.0276912   0.25    -2.2185)
(0.0    0.4275      0.0     0.0267804   0.25    -1.097)
(0.0    0.4424985   0.0     0.02592585  0.25    0.71674)

This is opposite with e.g., the NREL 5 MW definition, which defines twist as positive.

[sreeraj37]

Hi @chandukec ,
I am also working in the twin rotor case. I ran into few issues which you have already came across which was discussed elaborately in this discussion forum. Thanks for that.
I assume that you must have faced many issues which you must have sorted out by yourself while you were performing twin rotor simulations. It would be helpful if you can write those too in this forum or can I contact you in some other way for some of my obvious queries. So that I can consolidate the possible queries, errors and it's corrections and I can post in this forum it self.
It would be helpful if I can reach you . You can contact through my below mail IDs:
amy207563@iitd.ac.in
sreeraj.sreeraj3@gmail.com

Thanks,
Sree Raj

[chandukec]

@sreeraj37 Sure, considering the fact I am still a learner and @petebachant is really much more knowledgeable (in fact the creator ) and helping guy as compared to me, thus feel free to post in this forum which could eventually be helpful to other fellows.