Neuigkeiten rund um's Ranis

[Herbert Stammler]

Moin moin allerseits,

lange schon wurde es ruhig um neue Versionen des "Ranis", dem Berechnungsprogramm für Nurflügel. Nun gibt es viel Neues zu berichten!

Frank Ranis hat den Code an mich zur Pflege und Weiterentwicklung abgegeben. Nicht, ohne noch all seine letzten Neuerungen und Anpassungen mitzugeben. So können wir jetzt sehen, was seit langer Zeit entwickelt wurde und endlich öffentlich wird.

Die neuen Dateien findet Ihr (vorerst) hier: http://www.zanonia.de/nurfluegel.zip
Das Zip-File enthält die Exe, die (leicht veraltete) Hilfedatei und eine Default- Inidatei. Für das Update eines bestehenden Programms sollte zuerst das Verzeichnis gesichert und dann die neue nurfluegel.exe und nurfl.hlp als dem Zip eingefügt werden. So bleiben die Einstellungen der alten Ini-Datei erhalten.

Entsprechend der vielen inoffiziellen "Fixes" und Weiterentwicklungen ist die neue Versionsnummer 2.24, also nicht wundern wenn Ihr sie das erste Mal öffnet.

Was für Neuerungen hat Frank noch eingebaut?
Alles wird mir nicht einfallen, hier ein paar Schmankerl:

Da wäre die 3D-Ansicht, endlich kann man den Flügel quasi von allen Seiten anschauen und auch mal mit dem Auge "drüberpeilen".
Screenshot:

Der Eppler-Code ist jetzt direkt im Programm integriert, Frank hat ihn komplett neu geschrieben, damit dürfte auch das leidige "Win98-Kompatibilitätsmodus"-Einschalten wegfallen.

Ich habe an vielen Stellen am Layout und der Oberfläche gearbeitet, so sollten jetzt alle großen Fenster sauber skalierbar sein.

Experimentell habe ich den Button "nicht berechnen" aufgenommen, für alle die, die nicht ständig beim Ändern eines Werts auf die Berechnung warten wollen...

Jo, ansonsten, Anregungen und Tips sind natürlich immer willkommen, Fragen und Probleme lassen sich meist am besten einmal für alle hier im Forum besprechen. Bitte versteht mich, wenn ich Eure Mails nicht immer alle "zeitnah" oder überhaupt beantworten kann. Support kann unheimlich zeitaufwändig sein.

Der nächste große Schritt wurde von Frank ja schon begonnen, internationale Varianten in anderen Sprachen werden noch eine ganze Weile dauern, der Anfang ist aber gemacht.
Außerdem soll das Programm langfristig iterative Optimierungen lernen, das ist allerdings noch ein sehr, sehr weiter Weg.

Wenn Ihr Fehler oder Probleme mit der neuen Version habt, meldet Euch am besten direkt hier, auch wenn das Programm nur funktioniert würde ich mich über eine Meldung wie immer freuen.

cu2all
Herbert

ps: und das alles exklusiv zuerst hier in !

[ 23. Mai 2005, 22:05: Beitrag editiert von: Herbert Stammler ]

 

[Agent Smith]

Hallo,

Also es funktioniert .
(Unter win2000 - ebenso wie die vorgängerversion problemlos soweit ich das sehe).

Habe jetz nurmal kurz drüber geschaut, und werde mir die Sache morgen nochmal genauer ansehen, da ich zur Zeit knapp an Zeit bin.

Die 3D Ansicht ist interessant und hilft evtl. Eingabefehler zu entdecken. Interessantes Feature!

Allerdings habe ich jetzt erstmal die Schaltfläche zum berechnen gesucht - nach einem click auf manuell tat sich dann was. Etwas verwirrend zunächst, da ich halt den click auf "Profilwiderstand berechnen" gewohnt war.

In dem Zusammenhang ist mir bei der Profilwiderstandsberechnung folgendes aufgefallen " Mit Blasenber." Was genau verbirgt sich dahinter bzw, besser gesagt inwiefern wird das bei der Berechnung nun miteingeschlossen ?

 

[speedy573]

Hallo Herbert,

gute Neuigkeiten; toll dass du das Programm weiter betreust!

Anregung:
Hätte mir schon öfters gewünscht ein Übergabefile (z.B. ein einfaches Textfile) der berechneten Werte (vor allem der Auftriebsverteilung) zu haben mit dem man dann z.B. die Festigkeit in Excel rechnen kann. Mit der alten Version ist das doch etwas sehr zu Fuss
Das Prog rechnet nämlich ganz brav auch normale Flügel.....

Machbar?

Gruß
Mike

 

[portobello]

Jo, ansonsten, Anregungen und Tips sind natürlich immer willkommen
=================================================

Hallo Herbert,

wie schon gesagt, es läuft. Auf 3D könnte ich schon verzichten.
Mein Wunsch: die Gradzahlen der Verwindung auch in mm in einem kleinen Nebenfenster.
Die Flügelliste zum Ausdrucken.
Profile und Konstruktion, wäre zu aufwendig. Das geht mit Sielemann recht gut.

Grüße, Wilbert

 

[Ted]

Hallo Herbert.

Bisher läuft alles nach einem Kurztest problemlos. Schön finde ich den Button "nicht rechnen", der das Arbeiten deutlich beschleunigt.

Ein Punkt, der mich immer genervt hat, ist, daß besonders bei Flächen mit vielen Einzeltrapezen bei jedem Knick wieder das Profil eingegeben werden muß. Ok, ich kann auch am Anfang Wurzelrippe und Randbogen definieren und habe dann überall das gleiche Profil, aber dann steht bei Zwischenrippen immer nur "Strak", und das ist nicht gerade aussagekräftig.
Ich würde mir bei der Profilauswahl noch einen Button wünschen "Profil für kompletten Flügel nutzen". Verstanden?

Ungünstig finde ich den großen Abstand zwischen dem Eingabefeld für Balkenposition Y und dem Button "Knickstelle setzen". Der Button wäre direkt neben dem Eingabefeld besser aufgehoben (das könnte man dann auch bei der Klappendefinition so umsetzen). Damit würde man sich so einige Mausarbeit sparen.

Ted

 

[NuriULF]

Hallo, das sind aber gute Neuigkeiten !
Hab es eben mal kurz angetestet - sieht richtig gut aus.
Vor allem finde ich die (jetzt endlich richtige) Integration des Eppler-Codes spitze. Hatte bei mir bisher nie funktioniert. Und jetzt läuft es sogar mit WINE unter Linux
Nur ein Bug ist offensichtlich erhalten geblieben - beenden läßt sich das Programm nicht, es bleibt einfach hängen. Das hab ich schon auf vielen verschiedenen Platformen beobachtet. Ist aber nicht so wichtig - man hört ja eigentlich nicht freiwillig auf.
Großes Lob

 

[Cascada]

goil, jetzt seh ich endlich mal was ich da fapriziere, die Sache mit 3D is genial, dickes Fettes Lob!!

 

[NuriULF]

Moin,
Gestern abend noch etwas gründlicher angesehen. Und ein paar Verbesserungsvorschläge hab ich auch.

1) ein kleiner Bug : wenn man einen Flügel lädt, wird die Anzahl der berechneten Stützstellen in der Anzeige nicht aktualisiert, intern wird der Wert aber richtig geladen und verwendet. D.h. wenn man etwas mit 15 Stützstellen rechnet, ein altes Projekt mit 127 Stützstellen lädt, steht immer noch 15 in der Anzeige und man wundert sich nur warum's so lange rechnet.

2) Mir gefällt die Normierung der Widerstände nicht. Erstens sind die Werte zu klein und daher zu ungenau angezeigt (gestern gesehen cwp 0.0004 ein Stückchen weiter 0.0005 ...) und zum anderen kann man sie nicht direkt z.B. mit anderen Polaren vergleichen. Mir ist schon klar, daß man so normieren möchte, weil man dann sieht, daß ein Flügelstück mit geringerer Tiefe aber größerem cwp genauso viel zum Gesamtwiderstand beiträgt, wie ein tieferes aber Widerstandsärmeres. Aber wenn ich das beurteilen will sehe ich mit sowieso den ausgerechnetet Gesamt-cWP an. An den einzelnen Stützstellen hätte ich lieber die nicht-normierten Werte.

3) Eine Idee hätte ich noch für die Klappen-Berechnung. Man könnte eine Möglichkeit vorsehen, die Klappen einer Gruppe zur Simulation eines Queruder-Ausschlages antisymmetrisch zu fahren. Wenn man viele Stützstellen (wegen Verwindung) und eine lange Klappe hat, ist das Eingeben eines QR-Ausschlages von Hand echt nervend.Man könnte einen Schalter symm./antisymm. vorsehen oder die Gruppendefinition so abändern, daß nicht die Klappen beider Seiten zur Gruppe hinzugenommen werden. Dann kann man z.B. eine Gruppe für die rechte und eine für die linke Klappe machen und damit auch gemische QR/HR Ausschläge rechnen.

Alles in allem aber nochmal herzlichen Dank an diejenigen, die sich die Arbeit machen, uns allen ein so nützliches Werkzeug in die Hand zu geben.

 

[Herbert Stammler]

Moin moin allerseits,

Vielen Dank zuerst für das Feedback. Freut mich natürlich daß es Euch gefällt.

Also der Reihe nach...

Ich habe auf die im ersten Beitrag genannte URL eine neue Version hochgeladen, V2_24a. Sie enthält zwei Bugfixes, ansonsten keine neuen Funktionen. Bitte trotzdem updaten.

Original erstellt von Mario Roos:
In dem Zusammenhang ist mir bei der Profilwiderstandsberechnung folgendes aufgefallen " Mit Blasenber." Was genau verbirgt sich dahinter bzw, besser gesagt inwiefern wird das bei der Berechnung nun miteingeschlossen ?

Das kann ich Dir leider auch nicht so genau sagen, ich würde jetzt gerne an Frank verweisen, der verweist jedoch im Quelltext auf MiMö... Soweit ich das im Code verstehe, wird dort bei bestimmten Randparametern eine Blasenwarnung auf dem Flügel ausgegeben, allerdings ist der passende Button zum Anschalten dieser Grafik noch deaktiviert/versteckt. Ich muß da mal Frank zu fragen.

Original erstellt von speedy573:
Übergabefile (z.B. ein einfaches Textfile) der berechneten Werte (vor allem der Auftriebsverteilung)

Ja, soetwas möchte ich auch haben. Halt so, daß man möglichst viele Werte raus und auch wieder rein kriegt! Da wird sich mit der Zeit was tun, vorher muß ich noch an vielen Stellen genauer hinschauen und mich mehr in den Code einarbeiten. Ist vorgemerkt.

Original erstellt von portobello:
die Gradzahlen der Verwindung auch in mm in einem kleinen Nebenfenster.

Ok, also die Flügelliste ist kein Problem, siehe auch eins weiter oben, dabei scheint die Flügelliste sogar schneller realisierbar. Ist vorgemerkt.

Original erstellt von portobello:
Die Flügelliste zum Ausdrucken.

Verwindung in mm, hmmm, verstehe ich es richtig daß Du damit den Höhenunterschied zwischen Nasen- und Endleiste meinst? Die Definition ist hier ganz wichtig, nicht daß zum Schluss jemand hinten die "mm" unterlegt und vorne den Flügel auf dem "Profilbauch" auflegt... Aber machbar wird das sein. Ist vorgemerkt.

Original erstellt von Ted:
Ein Punkt, der mich immer genervt hat, ist, daß besonders bei Flächen mit vielen Einzeltrapezen bei jedem Knick wieder das Profil eingegeben werden muß. Ok, ich kann auch am Anfang Wurzelrippe und Randbogen definieren und habe dann überall das gleiche Profil, aber dann steht bei Zwischenrippen immer nur "Strak", und das ist nicht gerade aussagekräftig.
Ich würde mir bei der Profilauswahl noch einen Button wünschen "Profil für kompletten Flügel nutzen". Verstanden?

Verstanden. Ich muß noch schauen, ob die erste oder zweite Variante einfacher realisierbar ist, vermutlich wird's eher die erste werden, also nach der Regel: Sobald eine neue Knickstelle erstellt wird und die benachbarten Knickstellen das gleiche Profil haben, erhält die neue Knickstelle dasselbe Profil und wird nicht als "strak" geführt. Ich weiß daß das nur was für die Psychologie ist... mich hat das aber auch schon manchmal gestört.

Original erstellt von Ted:
Ungünstig finde ich den großen Abstand zwischen dem Eingabefeld für Balkenposition Y und dem Button "Knickstelle setzen". Der Button wäre direkt neben dem Eingabefeld besser aufgehoben (das könnte man dann auch bei der Klappendefinition so umsetzen). Damit würde man sich so einige Mausarbeit sparen.

Stimmt, ich werd' sowieso noch die Eingabenfelder pflegen und wenn ich sowieso noch die "mm" für Wilbert einbaue, muß ich das Layout nochmal anpacken... Ist vorgemerkt.

Original erstellt von NuriULF:
Und jetzt läuft es sogar mit WINE unter Linux
Nur ein Bug ist offensichtlich erhalten geblieben - beenden läßt sich das Programm nicht, es bleibt einfach hängen.

Interessant... bei mir ist das Programm beim Beenden noch nie hängen geblieben, jedoch hab ich jetzt mal an einer kritischen Stelle was geändert, in der neuen V2_24a könnte es besser sein. Bitte einfach mal ausprobieren.

Original erstellt von NuriULF:
ein kleiner Bug : wenn man einen Flügel lädt, wird die Anzahl der berechneten Stützstellen in der Anzeige nicht aktualisiert, intern wird der Wert aber richtig geladen und verwendet. D.h. wenn man etwas mit 15 Stützstellen rechnet, ein altes Projekt mit 127 Stützstellen lädt, steht immer noch 15 in der Anzeige und man wundert sich nur warum's so lange rechnet.

Wird mit der V2_24a gefixt, Danke für den Tip!

Original erstellt von NuriULF:
Mir gefällt die Normierung der Widerstände nicht. Erstens sind die Werte zu klein und daher zu ungenau angezeigt (gestern gesehen cwp 0.0004 ein Stückchen weiter 0.0005 ...) und zum anderen kann man sie nicht direkt z.B. mit anderen Polaren vergleichen. Mir ist schon klar, daß man so normieren möchte, weil man dann sieht, daß ein Flügelstück mit geringerer Tiefe aber größerem cwp genauso viel zum Gesamtwiderstand beiträgt, wie ein tieferes aber Widerstandsärmeres. Aber wenn ich das beurteilen will sehe ich mit sowieso den ausgerechnetet Gesamt-cWP an. An den einzelnen Stützstellen hätte ich lieber die nicht-normierten Werte.

Ok, verstanden. Ist vorgemerkt.

Original erstellt von NuriULF:
Eine Idee hätte ich noch für die Klappen-Berechnung. Man könnte eine Möglichkeit vorsehen, die Klappen einer Gruppe zur Simulation eines Queruder-Ausschlages antisymmetrisch zu fahren. ... Dann kann man z.B. eine Gruppe für die rechte und eine für die linke Klappe machen und damit auch gemische QR/HR Ausschläge rechnen.

Das geht schon genau so wie Du beschreibst. Bitte stelle die Box "Eingaben" auf "asymmetrisch" um, dann kannst Du für jede Flächenseite einzelne Änderungen durchführen, sowohl in der Geometrie als auch bei den Klappendefinitionen. Und nicht vergessen wieder nach der Gruppendefinition der Klappen auf "symmetrisch" zurückzuswitchen... sonst wird der Flügel nur zu leicht krumm.

cu2all
Herbert

 

[Eberhard Mauk]

Hallo Herbert,

Hab in den letzten Tagen das Neue Ranis etwas genauer betrachtet.
Als insgesamt ist das ein deutlicher Schritt nach vorne.
Ich finde dann mit meinem ME Betriebssystem einige Maskenfehler, im Eppler Programm sind beispielsweise die Polaren nicht Weis unterlegt, sondern haben die Farbe der Systemfenster aus Windows. Nur die Textstellen sind weis.
Wer dann wie ich, seine Farben vom Standard Windows abweichend etwas exotisch gewählt hat,
guckt sich die Augen aus dem Kopf.

Ansonsten hab ich wie im bisherigen Ranis, das Problem, das ein Kontrollflügel, z.B mit 2,5 x 0,5 Meter.

mit einem Tragenden Profil hier testweise zB. NACA 2412 das um -2,1 Grad Profil- Alpha 0 hätte
bei Gewicht 0,01 kg und CA 0 einen Alpha von etwa -1,44 anstelle der -2 Grad ausweist.

Bei dem Beispiel ist das dann ein um ca. 1/2 Grad fehlerhafter Anstellwinkel bei 128 Wirbelstellen.
Wobei egal ist um welches tragende Profil es sich handelt. Es gibt immer ähnliche Abweichungen zum Profil Alpha 0 wenn ich den Grenzfall Ca Null zur Kontrolle rechnen lasse.
Erst wenn ich ein Symetrisches Profil nehme verschwindet diese Abweichung und der bei Ca 0 ausgewiesene Anstellwinkel ist dann auch gleich dem Profil Alpha Null wie es auch beim endlichen Modellflügel als Grenzfall sein sollte.

Wenn ich diesen Fehler auf einen realen Modellflügel mit demselben Profil übertrage für den ich eine EWD rechne, ist das eine so hohe Abweichung, das ein Leitwerkler mit tragendem Profil der mit Ranis gerechnet wird grundsätzlich eine fehlerhafte EWD hat.
Immerhin ist ein EWD Fehler von 1/2 Grad zB für einen Jet oder ein Großmodell und auch sonst für einen Leitwerkler nicht tollerabel.
Die Flügelgeometrie ist dann bei einer Kontrolle nach obigem Muster mit Verwindung Null und obiger Werteeingabe auch egal, die Abweichungen zum Profil- Alpha Null bleiben einfach.

Da meine manuellen EWD Berechnungen mit Basis Eppler Polaren für bereits fliegende Modelle ebenfalls diese Abweichung zur Ranis Berechnung ausweisen, gehe ich von einem grundsätzlichen Problem im Ranis aus.
Es kann jetzt sein, das die Berechnungsmethode im Ranis da an ihre Grenzen stößt, aber das wüsste ich gerne genauer, auch wüsste ich gerne, ob die mit obigem Testschema ermittelte Abweichung bei einem Profil X auf einen realen Flügel mit demselben Profil und Geometrie mit Schränkung als Korrekturwert anwendbar ist.

Ich würde mich freuen, wenn man dieses Problem hier genauer beleuchten könnte.

Gruß
Eberhard Mauk

Hier Die Maske mit dem Testflügel.
Darauf ist auch zu erkennen, das beim Drücken des Maximieren Buttens rechts oben, der weise Grafik
Bereich nicht mit vergrößert wird.

 

[deftones]

Moin Eberhard,

ich denke die Ranisergebnisse müssten so passen. Zuerst musst Du bei den Auslegungseinstellungen auch das Ca mit dem schwarzen Punkt versehen. Dann sieht die Sache schon mal so aus wie im Bild. Die Abweichung die da noch vorhanden ist, kommt aus der Gleichung für den effektiven Anstellwinkel alpha_e:

alpha_e(y)=alpha_g(y)-alpha_i(y)

Das alpha_i ist der induzierte Anstellwinkel, der aus der Auftriebsverteilung des Flügels kommt und daher immer verschieden Null für ein Ca ungleich Null ist. Die einzige Ausnahme ist der Ellipsenflügel. Daher kann der resultierende, angezeigte, effektive Anstellwinkel alpha_e an der jeweiligen Stelle nie den 2D Profildaten entsprechen.
So, ich gehe jetzt in den kühlen Keller Leitwerke schleifen. Das musste ich hier im Nurflügelforum noch mal loswerden...

Ciao

Benjamin

 

[Eberhard Mauk]

@ Benjamin,
jetzt rechnest dein Beispiel nochmals mit 127 Wirbelstellen, dann merkst auch du das was nischt stimmt.
Kann doch net sein, das ich mit 15 rechnen soll, wo die Genauigkeit dann bei steigendem CA, Pfeilung, Schränkung usw. immer schlechter wird.

Bei dem Grenzfall bedeutet die Differenz von 0,6 Grad des Flügel Alpha zum Profil Alpha Null bei CA NULL Rechnung, das die mit der Auftriebsverteilung insbesondere bei CA Null nicht mehr erklärbar ist.
Diese Abweichung hast ja schon als EWD bei nem 20 kg Flieger.
Das heist dann, wenn ich mich nach dir richte, das die EWD einen 100 % igen Fehler hätte.

Kann doch auch nicht sein, das ich zwischen 15 und 127 Wirbel zur Berechnung solch einen Unterschied bekomme, da weis doch keiner, der diese Grenzfallkonztrolle nicht jedesmal macht, was richtig und was falsch ist. Und schon gar nicht weis Mann was bei steigendem ALPHA, Schränkung, Pfeilung usw richtig ist.

Dies Problem ist übrigens beim Alten u Neuen Ranis gleich.

Gruß
Eberhard

PS: hier das Bild für dich nochmals mit Punkt bei CA sogar mit Wert Null und 127 Wirbel.
Wo der Punkt ist ist Wurscht, wichtig ist was in den Feldern steht und gerechnet wurde.

[ 28. Mai 2005, 13:05: Beitrag editiert von: Eberhard Mauk ]

 

[deftones]

Hallo Eberhard,

ich glaube wir reden hier aneinander vorbei und/oder ich hab Dein Problem noch nicht ganz verstanden.
Du erwartest, dass Du ein CA=0 vom Gesamtflügel eingibst und dann den Anstellwinkel rausbekommst? Meiner Meinung nach ist es völlig korrekt, dass man eine CA=0 nicht eingeben kann, denn da gibts auch keinen Auftriebsbeiwert/Zirkulation zu berechnen.

Benjamin

 

[Eberhard Mauk]

Nee,

Als Grenzfall, muss Ranis beim ungeschränkten Flügel mit tragendem Profil BEI CA 0 , denselben FLÜGEL-Nullauftriebswinkel haben, wie der Profil Alpha 0.

Als Beispiel, NACA 2412 Apha Null = -2,1.. Grad
Ein Flügel mit dem Profil kann dann keinen anderen Nullauftriebswinkel als diese -2,1 Grad haben.

Ranis weist aber bei 127 Wirbeln einen deutlich abweichenden Wert aus.

Dazu kommt noch, das mit wenig Wirbeln gerechnet dabei genauere Werte raus kommen, als mit vielen Wirbeln. Speziell bei dieser Grenzfallberechnung, stimmt dann schon von der Seite her was nicht.
Zumindest bei diesem Grenzfall muss mit egal wieviel Wirbeln gerechnet wird, derselbe Wert
bei der Grenzfallberechnung raus kommen.

Da dieses nicht der Fall ist,
muss ein systematischer Fehler zugrunde liegen.

Zumindest der der Ranis zur Auslegung für Leitwerkler nutzen will, sollte wissen wohin die Reise geht. Beim NURI trimmst 2-3 Klicks, dann stimmts vieleicht wieder, trotzdem ist das auch da ein Fehler der dazu führt, das das Produkt anders fliegt als es gedacht war. Mag da vieleicht nicht schlimm sein, aber beim Leitwerkler ist eine vorne weg 1/2 Grad falsche EWD was grausliges.
Dabei wäre Ranis ohne dies Problem eine wirklich schöne Sache.

Gruß
Eberhard

PS: hab mir grad mal die Mühe gemacht zum obigen Test/Beispielflügel das Modell gegen zu rechnen.

Gewicht 20 kg Flügelfläche obige 1,25 m²
V= 40 m/s NACA 2412

Ergebniss manuelle Berechnung mit der Hand am Arm:
EWD - 1,1 Grad für CA 0,085
So fliegt das dann als Schleppmaschine auch ohne jegliches Nachtrimmen.

RANIS mit 15 Wirbeln gibt bei 40 m/s aus;
CA= 0,16
Anstellwinkel/EWD 0,157 Grad Plus

Ich sag da mal UPS... Abweichung zum realen Flieger 1,25 Grad.... Heftig

RANIS mit 127 Wirbeln gibt aus:
CA= 0,16
Anstellwinkel/EWD 0,544 Grad Plus
Abweichung zum realen Flieger 1,65 Grad
Da sag ich dann UPS UPS... noch heftiger.

Also Im Ernst, wer nur etwas Erfahrung mit der Konstruktion von Leitwerklern hat, weis, das die EWD bei obigem Beispiel im Minus-Bereich liegen muss.

Wobei ich dann mit beiden Ranis Berechnungen auf Kriegsfuß stehe. Weder das Ergebnis mit 15 Wirbeln, noch das mit 127 Wirbeln ist realistisch.
Wobei das Ergebniss mit 15 Wirbeln näher am
Fliegenden Objekt liegt als das mit der eigentlich genaueren Berechnung mit 127 Wirbeln.

Bei der Betrachtung fällt dann auf, das die CA Differenz ziemlich genau den doppelten Wert hat als das fliegende Modell.

CA 0,085 Manuelle Rechnung, Ranis CA 0,16

[ 29. Mai 2005, 00:28: Beitrag editiert von: Eberhard Mauk ]

 

[Hartmut Siegmann]

Als Beispiel, NACA 2412 Apha Null = -2,1.. Grad
Ein Flügel mit dem Profil kann dann keinen anderen Nullauftriebswinkel als diese -2,1 Grad haben.

Das ist falsch!

Der Denkfehler: Die Auftriebsverteilung/Zirkulationsverteilung ist niemals exakt rechteckig/trapezförmig! Zum Randbogen hin nimmt die Zirkulation ab und auch bei der Grenzbetrachtung gegen cA=0 (Nullauftriebswinkel Tragflügel) hat man immer noch diese Zirkulationsabnahme (ca(y) ungleich Null!), die im Endeffekt dann zu einem anderen Nullauftriebswinkel führen muss als beim unendlichen Tragflügel.

Deswegen weichen Nullauftriebswinkel vom Profil (=unendlicher Tragflügel) und vom endlichen Tragflügel stets voneinander ab.

Dazu kommt noch, das mit wenig Wirbeln gerechnet dabei genauere Werte raus kommen, als mit vielen Wirbeln. Speziell bei dieser Grenzfallberechnung, stimmt dann schon von der Seite her was nicht.

Irrtum, siehe oben.

Das 127-Wirbel Resultat ist das "richtigere", wenn ich das einmal so salopp formulieren darf.

Da dieses nicht der Fall ist,
muss ein systematischer Fehler zugrunde liegen.

Es liegt ein systematischer Denkfehler vor - kein Programmfehler!

......................
PS: Rechenbeispiel:

Ich sag da mal UPS... Abweichung zum realen Flieger 1,25 Grad.... Heftig

(...)

Also Im Ernst, wer nur etwas Erfahrung mit der Konstruktion von Leitwerklern hat, weis, das die EWD bei obigem Beispiel im Minus-Bereich liegen muss.

Auch das stimmt nicht: Du hast den Abwindwinkel am Höhenleitwerk vergessen! Du betrachtest hier im Ranis ausschließlich einen Tragflügel ohne Nachlauf und damit ohne Abwindwinkel hinter dem Tragflügel. Das aber genau darf man nicht vernachlässigen! Wenn man das tut, sollte man sich nicht über vermeintlich "falsche" Ergebnisse wundern!

Wobei ich dann mit beiden Ranis Berechnungen auf Kriegsfuß stehe. Weder das Ergebnis mit 15 Wirbeln, noch das mit 127 Wirbeln ist realistisch.

Wenn ich die Erde als Scheibe annehme, bekomme ich auch immer unrealistische Ergebnisse heraus.

Der "Ranis" mit dem Truckenbrodt als Rechenverfahren (ein um Pfeilungseffekte erweitertes Traglinienverfahren, Basis ist Multhopp) berechnet endliche, gepfeilte und ebene (V-Form = 0°) Tragflügel ohne Nachlauf-Relaxation. Damit sind ausschließlich allein fliegende Flügel der genannten Konfiguration zu betrachten. Und mit recht vielen Wirbeln kommen sogar mit höherwertigen Rechenverfahren (Wirbelleiterverfahren) vergleichbare Ergebnisse für diesen Tragflächentyp heraus.

Eberhard, auch wenn Deine Thesen leider ausnahmslos auf dem Altar der Aerodynamik geopfert werden mussten , sind sie dennoch eine gute Grundlage zu zeigen, was man mit dem "Ranis" nicht tun darf.
Siggi

 

[Reto Schmid]

Hallo Herbert,

toll das sich jemand dem Programm angenommen hat.
Wenn ich ein Flügel definieren möchte bekomme ich häufig diesen Fehler:

Hast du von diesem Fehler schon mal gehört?
Was muss ich machen, damit dieser nicht eintritt?

Danke für eine Antwort.

Gruss

Reto

 

[Herbert Stammler]

Moin moin Reto,

Original erstellt von Reto Schmid:
Wenn ich ein Flügel definieren möchte bekomme ich häufig diesen Fehler:
/Bild/
Hast du von diesem Fehler schon mal gehört?
Was muss ich machen, damit dieser nicht eintritt?

Hm, komisch. *grübel*

Soweit ich das sehe passiert Dir das immer zu Beginn, könntest Du den genauen Ablauf (also was Du wann wo eingibst und drückst) mal auflisten und hier reinsetzen oder mir mailen? Ich glaube da steckt irgendwo der Wurm in der Reihenfolge... und ich weiß nicht, wo ich da anfangen sollte zu suchen. Bei mir kann ich alle Variationen von 0,75 (auch mit Punkt getrennt, Leerzeichen davor/dahinter) eingeben und es klappt...

Also, wäre schön wenn Du Dir die Mühe machen könntest, sonst komme ich da glaube ich nicht so schnell weiter.

cu
Herbert

 

[NuriULF]

Moin,

also den Fehler "kein gültiger Gleitkommawert" kenne ich auch zur Genüge. Tritt genau dann auf, wenn man die y-Koordinate einer Knickstelle von Hand eingeben will - nur nicht immer. Wenn man dann hartnäckig genug auf OK drückt und weitermacht, bekommt man irgendwann zu sehen "'y in m' ist kein gültiger Gleitkommawert". Das hilft vielleicht beim suchen. Ansonsten läßt sich das Problem häufig vermeiden, indem man den Cursor setzt (y eingeben) und mit +/- etwas hin und her schiebt, bevor man den Knick setzt. Ist aber mehr so ein Notbehelf.

@Herbert:
danke für den Tipp mit den asymmetrischen Eingaben, nach der Lage des Feldes hatte ich geschlußfolgert, daß es sich auf die Geometrie beziehe und nicht auf die Klappen wirkt. Kann man vielleicht umsortieren.

 

[Herbert Stammler]

Moin moin nochmal,

vielen Dank für die Hinweise zu dem "ist kein gültiger..."-Fehler, es sieht so aus als wäre er nicht so leicht zu kriegen... da wird vermutlich nur konsequentes Aufräumen helfen, irgendwas scheint da hin und wieder einfach nicht so zu tun wie es soll. Also: Ist vorgemerkt. Aber wann und ob es besser wird weiß ich noch nicht.

Reto, ich habe die Datei aus Deiner Mail und Deine Beschreibung bei mir getestet, funktioniert alles ohne Fehler... scheint also auch irgendwie am Rechner und vielleicht am Betriebssystem zu liegen. Ich habe XP SP2, was habt Ihr, die den Fehler häufiger seht?

Original erstellt von NuriULF:
danke für den Tipp mit den asymmetrischen Eingaben, nach der Lage des Feldes hatte ich geschlußfolgert, daß es sich auf die Geometrie beziehe und nicht auf die Klappen wirkt. Kann man vielleicht umsortieren.

Sogar noch besser, die "asymmetrischen Eingaben" beziehen sich nicht nur auf die Klappen, sondern auf alle geometrischen Eingaben, man kann also damit sowohl asymmetrische Flächen erstellen als auch asymmetrische bzw. gegensinnige Klappenausschläge erzeugen.

cu2all
Herbert

ps: Schon 200 Downloads der 2_24!

 

[Reto Schmid]

Ich habe XP SP2, was habt Ihr, die den Fehler häufiger seht?

Herbert XP SP2 ist bei mir auch installiert.
Hast du mal ein Screen shot wie der Flügel aussieht?

Gruss

Reto