F.M. wrote:
Hello Mr. Stefan, maxiter is a scalar or a vector?
He is never using the scalar "maxiter" (the worksheet variable) as argument of his function when calling it.
He is always using
which IS a vector
Its a bit strange, and confusing indeed. The global worksheet variable "maxiter" is a scalar, but the formal function argument "maxiter" always is a vector. Again same name for different things. So in this respect all is OK (given we are looking for the error in his sheet), apart from the fact, that its a very bad habit doing things like that.
Werner
Thats exactly what can happen if you are using your vectors from the very beginning. You end up with data structures which are hard to keep track of.
The problem is, that you are comparing a vector with a scalar (Mathcad is telling you so more or less anyway).
d.m is a nested vector and a.m a regular vector .So a.m[s is a scalar, but d.m[s is a 2 x 1 vector and of course you can not compare those.
Delete the index s (marked in red) and I think you get what you intended
If the title of your file is a question addressed at me, the answer is "no".
Its only partly what I was talking in the other threrad and I think its a good idea to modularize your monster programs (they will be monsters once you implement all input arguments) by defining auxiliary functions.
But what I meant was that you also make Iter() a function taking ALL relevant arguments and Iter() should work with scalar arguments only (you avoid errors like this one that way - all are scalars). So you would get rid of your s-loop and it would be a good idea to define (and test) that new Iter() function right before you define any variables. That way Iter() cannot use any worksheet variables (you will immediately get an error as those variables are not yet defined) but relies solely on its arguments.
When this function(s) works OK for a set of scalar arguments, then its time to define your variables (the 2 x 1 vectors) and feed them into your function using vectorization.
At least thats the way I would try to do the job but maybe I am wrong. Honestly I have only looked very shortly at your Iteration_not_working.xmcd.zip file in the other thread Re: recursivic Calculation as the routine was far too large, cluttered and complicated for me to debug. It would be necessary to check all variables for consistency concerning data strucure and units and it sure is a good idea to split the calculation in a couple of smaller, more handsome parts using functions.
Werner
Keine Notwendigkeit, einen Vektor mit den Elementen alle gleich zu erstellen. Einfach verwenden die Konstante maxiter.
Shouldn't those two values (and others) be the same?
I can't spot any difference in the input data
What about the values for M.E, S.bo, p.D ? They are all the same. So at the time there would be no vector be needed for them. Are they subject to be changed later (different values in one vector)? If not, you should replace them for scalars.
You are right Werner. The reason is that I used a very great tolerance. If I use a much smaller tolerance, the result is more satisfactory.
Although I don't know what is a.m, I would introduce a relative tolerance to be compared with that obtained between the calculated diameter of the bolt and a.m, and stop the iterations when the latter is less than or equal to the given tolerance. As you can see in the program, the operations are all between scalar variables (elements of vectors) with indices.
Es gibt keine wesentlichen Änderungen im Vergleich zu früheren Versionen. Dies ist vielleicht abhängig von der Unkenntnis des Problems, und das Fehlen einer Beschreibung der Daten.
Best regards
F,M.
> Später muss ich die Rechnung noch um andere sachen erweitern, sodas sich dann viele andere Abbruchkriterien für die Kraft habe. (Schraubenverbindung, Bauteilfestigkeit etc.
Ja. daher ist es sinnvoll, die dazu nötigen Berechnungen (wie hier eben den Bolzendurchmesser) in Funktionen auszulagern, um das eigentliche Iterationsprogramm möglichst übersichtlich zu halten.
Ich denke ja noch immer, dass die Aufgabe(n) trotz unterschiedlichster Abbruchkriterien doch mit einem Lösungsblock realisierbar sein könnte. Für den Bolzendurchmesser allein hab ich das ja in dem anderen Thread gezeigt, wie es gehen könnte.
> Die sachen lassen sich nciht direkt lösen und müssen itertaiv bestimmt werden.
Naja, zumindest für Kraft/Bolzendm. stimmt das nicht. Auch da hatte ich ja schon eine direkte Formel zur Berechnung angegeben. Allerdings wird es bei zusätzlichen anderen Kriterien wohl so sein, dass man tatsächlich keine direkte Berechnungsformel angeben kann.
Aber vielleicht können wir ja zumindest die Angelegenheit hier doch noch zufriedenstellend abschließen.
Im Anhang meine Lösungsvariante, welche hoffentlich auch demonstriert, was ich mit meinen bisherigen Anmerkungen meinte.
Zunächst ist die Dmberechnung und auch die OK/NOK "Berechnung" ausgelagert, da ich sie in meiner Routine mehr als einmal benutze. Danach folgt die von mir immer wieder "eingeforderte" Berechnungsroutine, die nur und ausschließlich auf skalaren Größen operiert. Diese wird vorzugsweise oberhalb der Definition der Eingabevariablen geschrieben, damit man nicht irrtümlich etwas benutzt, das nicht als Parameter übergeben wird. Diese Routine, die also nur einen Satz Daten berücksichtigt, habe ich "Iter_single" genannt:
Du siehst, dass ich hier nicht mit F.alt und F.neu herumeiere, ein F reicht völlig. Nur, um nach den Abbruch noch den vorherigen Wert zur Verfügung zu haben, speichere ich jeweils den letzten Wert von F, bei dem der Vergleich noch OK war, in einer Variablen F.OK. Und nur diese und der zu diesem Wert gehörige Durchmesser und OK-Wert werden dann zurückgegeben. Deshalb müssen diese nach der for-Schleife neuerlich berechnet werden. Man könnte alternativ so wie das F.OK auch ein d.OK und vl ein OK.OK mitführen und sich damit diese Neuberechnung ersparen
Probleme kann es hier geben, wenn bereits der Initialwert zu einem zu großen Durchmesser führt (als F,OK wird dann 0 angenommen). Das sollte man der Ordnung halber vl noch abfangen. Ich wähle aber bei den folgenden Aufrufen ohnehin immer 0 N als Initial-Wert, da passiert das offenbar nicht.
Jetzt gibt es mehrere Möglichkeiten, diese Routine zu verwenden. Entweder tatsächlich nur mit einem Datensatz
oder aber mit Vektoren als aktuelle Parameter, dann aber muss der Aufruf vektorisiert werden
Hier sieht man jetzt schon die Problematik - das Ergebnis ist eine verschachtelte Matrix. Wir erhalten einen Vektor dessen Einträge jeweils 1 x 5 Matrizen sind. Das ist für weitere Berechnungen und Ausgaben recht unhandlich, weswegen ich noch eine eigene Routine "Iter" nachgeschaltet habe. Diese ruft "Iter_single" in jedem Fall vektorisiert auf, prüft danach, ob das Ergbenis eine verschachtelte Matrix ist und schreibt diese dann gegebenenfalls in eine normale Matrix um.
Ich hab der Rückgabematrix auch noch einen Zeile mit Spaltenköpfen spendiert.
Die Routine "Iter" kann jetzt also sowohl mit skalaren Werten, als auch mit (gleich großen) Vektoren aufgerufen werden. Wenn ein Eingabevektor nur aus lauter gleichen Einträgen bestehen würde, kannst du stattdessen auch einfach nur den skalaren Wert hinschreiben, so wie ich das mit F.init und maxiter gemacht habe:
Mit deinen Werten ergibt sich dann folgende Tabelle:
Das wärs eigentlich auch schon. Schmerzlos und im Grunde recht kurze Routinen.
Ich hab auch noch als Alternative eine weiter Funktion "Iter_neu" geschrieben. Diese orientiert sich an deinem ursprünglichen Ansatz indem sie die Vektoreingabewerte mit einer Schleife (ich hab den Schleiferzähler s als Name übernommen) einzeln abklappert, damit die Funktion Iter_single aufruft und die Ergebnisse gleich in einer Matrix (auch mit Spaltenköpfen) aufsammelt. "Iter_neu" hat eigentlich keine Vorteile gegenüber "Iter". Im Gegenteil, denn "Iter_neu" kann nicht mit lauter skalaren Werten aufgerufen werden, sondern es müssen hier F.init und maxiter Skalare sein und die anderen Parameter müssen (gleichgroße) Vektoren sein. Also ist "Iter_neu" eher eingeschränkt und weniger flexibel.
Hoffe, dass wir damit diesen Thread erledigen können.
LG
Werner
Eine Ergänzung noch dazu, nämlich eine weitere Möglichkeit, nach dem Abbruch der for-Schleife zu einem gültigen F-Wert zu kommen und diesen auch noch genauer als auf 100N genau zu bekommen.
Nachdem die for-Schleife abgebrochen wurde, geht es in eine neue Schleife, die solange F um 1N verringert, bis der Vergleich von d und a ein "OK" ergibt. Auf diese Weise hast du nun die Kraft F auf 1 N genau. Das ist jetzt sozusagen die verfeinerte Version meines allerersten Vorschlags zur Rückgabe des letzten gültigen F-Werts, den ich bereits in dem anderen Thread gemacht hatte. Dort hatte ich gemeint, dass du mit F doch nur einen Schritt, also 100 N, zurückgehen musst.
Ich habe mir hier nicht die Mühe gemacht, den Iterationszähler "i" in dieser zweiten Schleife weiter hinauf (oder runter?) zu zählen, weil ich ohnedies nicht verstehe, warum du diesen Zähler überhaupt ausgibst. Wenn du mit 0N als Startwert beginnst, immer um 100N erhöhst und es stellt sich dann F=983400 N ein, dann ist doch ohnedies klar, dass F eben 9834-Mal erhöht wurde und nach deiner Zählweise sind das dann 9835 Iterationsschritte.
Hier die neue "Iter_single2":
Die neue "Iter2" ist gegenüber "Iter" unverändert, nur ruft sie eben "Iter_single2" auf.
Hier zum Vergleich die Ergebnisse von "Iter" und die genaueren von "Iter2" (noch genauer machts ein Lösungsblock 😉
Der Unterschied zwischen a.m und d.m ist nun schon so klein, dass er kleiner als ein Mikrometer ist und daher in der Tabelle nicht mehr zu erkennen ist.
WE
