Giter VIP home page Giter VIP logo

freewake's People

Contributors

bill-b avatar bramesfeld avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar

freewake's Issues

This condition doesn't work?

The value of k doesn't look right in some cases using the default input

while((panelPtr[k].left-1<=panel2[wing] && panelPtr[k].left-1 !=-1) \
|| (panelPtr[k].right-1<=panel2[wing] && panelPtr[k].right-1 !=-1))
{
panel2[wing]=k;
panel1[wing+1]=k+1;
panel2[wing+1]=k+1;
k++;
}

Are the CG and panels rotated correctly?

We move the CG to account for turning flight, and descending flight, but the CG is not rotated to account for bank angle or alpha (when horiz ==1).

We rotate panels (bank and alpha) about the global 0,0,0 origin, not the CG. Is this what we want?

induced velocity in FW18

add to induced_velocity.cpp line 146 'j++'
Otherwise, will not add up surface DVE velocities correctly.

Rudder deflection doesn't always work

Model the following panel (vertical stab with rudder def. 45deg) and run with phi = 45.0, circling,horizontal flight, alpha 10.

Panel #: 1. Number of elements across span n = 2 and chord m = 4
Neighbouring panels (0 for none) left: 0 right: 0
xleft yleft zleft chord epsilon Bound.Cond. Airfoil Hinge Deflection
5.500 0.000 0.000 0.350 0.000 100 2 0.700000 45
xright yright zright chord epsilon Bound.Cond. Airfoil Hinge Deflection
5.500 0.000 2.500 0.350 0.000 100 2 0.700000 45

The rudder deflects in the plane of the vstab, not out of the plane.
Maybe an issue here with quadrants:

ceps = cos(surfacePtr[l].epsilon); //needed for tempA below
seps = sin(surfacePtr[l].epsilon);
//computing the mid-span location of the DVE LE
//temporarily saved in xleft
tempA[0] = x1[0]+xLE[0]*tempS;
tempA[1] = x1[1]+xLE[1]*tempS;
tempA[2] = x1[2]+xLE[2]*tempS;
//vector from LE mid-span point to reference point
delX[0] = surfacePtr[l].xsi * ceps;
delX[1] = surfacePtr[l].xsi * seps * sin(nu2);
delX[2] = -surfacePtr[l].xsi * seps * cos(nu2);

image

FW aileron trim won't work with equal deflections

When roll trim is ON, the check we do to make sure there is an aileron will fail if there are two ailerons with equal but opposite deflection. (Ex. -5 and +5)

tempsum = 0;
for (i = info.panel1[0]; i <= info.panel2[0]; i++) { //for all panels on wing 1
tempsum = +panelPtr[i].deflect1;
}
if (tempsum == 0) {
printf("No aileron defined on wing 1.\n You must define a deflection on at least one panel on wing 1. \n");
scanf("%c", &answer);
exit(1);
}

Also unrelated but we can maybe decrease the allowed error on Cl for roll trim.

Adding calculation of area

a few ways to do this. I can calculate the panel areas and add them up, and also calculate the projected panel areas and add them up. These values will not change with camber or flap deflection.

We can also add up the DVE element areas. Those values would change with camber, and the projected areas would change with flap deflection.

Also, what will these values be used for? for example, what if we want to non-dimensionalize to just the wing area and not include the tail? how will the user approach this?

should uTE be nondimensionalized?

When moving the elements in the ind. drag computation, should uTE be nondimensionalized? U is nondimensionalized for the non circling case...

if(info.flagCIRC){ //Added by D.F.B. 03-2020 for circling flight
// NOTE: Move *induced point* in its own velocity direction
tempS=dot(delX,surfacePtr[index].uTE[k]);
scalar(surfacePtr[index].uTE[k],tempS,tempB);
} else{ // if not circling flight, move pts in freestream direction (U)
//delX projected into the freestream direction (magnitude)
tempS=dot(delX,surfacePtr[index].U);
//vector from TE of s(inducer) to TE of index (induced) projected into the freestream direction (with direction) to make tempB
scalar(surfacePtr[index].U,tempS,tempB);
}

Number of DVEs on flap

For the current version, the LE of the DVEs has to match hinge line. For example, chord 10, flap 20%, m=5 works fine; m=6 does not work
Suggestion, adjust DVEs on flap that at least one DVE on flap, otherwise round m*percentage of flap to full number.
Issue: DVEs of one span wise location will have different chords.

rotating panels in this order causes the panel to have sweep

Rotating in Z-X-Y causes the panels to have sweep when using a bank angle. Switching to Z-Y-X fixes this problem, but I don't know if it causes another problem. Z-Y-X is a more common order.

//rotate X1
rotateZ(panelPtr[panel].x1,psi,tempA);
rotateX(tempA,-nu,tempAA);
rotateY(tempAA,eps,panelPtr[panel].x1);
//rotate X2
rotateZ(panelPtr[panel].x2,psi,tempA);
rotateX(tempA,-nu,tempAA);
rotateY(tempAA,eps,panelPtr[panel].x2);
}//END loop over panels
// II. updated CG location (RefPt)
//rotate reference point (CG)
rotateZ(info.RefPt,psi,tempA);
rotateX(tempA,-nu,tempAA);
rotateY(tempAA,eps,info.RefPt);

Does beta work?

Beta has to be zero if using symmetry for force calcs:

if (info.sym==1 && info.beta == 0)

Not sure if lift is calculated correctly with beta:

//free stream lift
N_force[l][0] = N_free * sqrt(eN[0]*eN[0]+eN[2]*eN[2]);
if (eN[2]<0) N_force[l][0] *= -1; //neg. if resultend is downward
N_force[l][1] = dot(R,eL); //induced lift

We are not including the lift from the vortex sheets. Is this significant?

Calculation of 'r' vector

Since the gradient is used to calculate omega for only the XY components of velocity, we can define our gradient as Vk/ R, where Vk is Uinf*cos(alpha) during descending flight.

Since we want the 'r' vector in the xy plane, we should be calculating the 'r' vector as Uinf*cos(alpha) / gradient, which is equal to Vk/grad, and not Uinf/grad as is done now:

circCenter[1] = XCG[1]-info.Uinf/info.gradient;

And then we should not be multiplying the gradient by cos alpha here, because we will be calculating grad as Uinf cos(alpha) / R

omega[2] = -info.gradient*cos(info.alpha);

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.