Having trouble looping through this program

[msu12181]

Hi,

I am having trouble looping through this program. I am basically taking the FORTRAN approach (attached) and trying to implement it into MathCAD 14. I am confused on how to make some of the change over.

Any help would be greatly appreciated.

[Fred_Kohlhepp]

Addison Mauldin wrote:

Hi,

I am having trouble looping through this program. I am basically taking the FORTRAN approach (attached) and trying to implement it into MathCAD 14. I am confused on how to make some of the change over.

Any help would be greatly appreciated.

Why, Oh why, would you want to drive Mathcad to be like FORTRAN?

I started into your sheet, and immediately ran into some unit balance problems.

There are far better ways to use Mathcad to solve this problem; the first is to use units and built-in physical constants to shorten your path.

Please! Forget FORTRAN. Put your PDF paper notes into Mathcad. Then try again.

[msu12181]

Thank you very much Fred. Please forgive my ignorance. I don't have a programing background at all.

I am at the point now where I have the sheet implemented, all with units. I am getting stuck on how to pull roots with units attached.

Also, assuming once I get the roots, how do I proceed forward in Mathcad to handle the steps 7. and 8. in my .pdf file?

[Werner_E]

Addison Mauldin wrote:

Thank you very much Fred. Please forgive my ignorance. I don't have a programing background at all.

I am at the point now where I have the sheet implemented, all with units. I am getting stuck on how to pull roots with units attached.

Also, assuming once I get the roots, how do I proceed forward in Mathcad to handle the steps 7. and 8. in my .pdf file?

You wrote "polyroot times vector" and did not call "polyroot of vector".

But even if you would have done it the correct way it would have failed, because Mathcad can't handle vectors consisting of elements of different dimensions (as a .. e are).

So you have either get rid of the units in the coefficients alltogether or at least bring all to the same dimension. The result will be unitless and you have to add the correct unit (s is obviously 1/time so I suggested Hz or 1/sec) manually:

P.S.: The powers of s are powers of the unit seconds and have nothing to do with the variable s.

[msu12181]

Thanks Werner. I caught the same mistake just after I posted the previous msg in thread. I also realized that the only way to get the units out of the polyroots was to do as you did above by nondimensionalizing the coeffs. I am glad you did show the first on how to work "around" the units to get the roots in terms of a frequency. Thanks for your help.

[Fred_Kohlhepp]

I'm glad that others smarter than I have pitched in to help.

Welcome to Mathcad

[msu12181]

Since Werner was helpful in getting the roots in the correct units, I am wanting to revisit this looping action required to produce K_alpha and K_theta as in step 7 and 8 in my original pdf file. How do you do this in Mathcad 14 without going though some program loop as in FORTRAN? Trying to keep with Fred's original statement of keeping away from FORTRAN logic. Any suggestions?? (Sorry didn't get a chance to look at this over the weekend).

[msu12181]

I guess I am getting confused on how to get Mathcad to check the results to see if the roots validate (or not) the conditions. Based on those conditions, how do you proceed with the results and use those results to continue with the loop, thus generating the curve for K_alpha and K_theta?

[Fred_Kohlhepp]

If I understand your PDF file you're looking for flutter boundaries--values of K theta and K alpha where your polyroots vector suddenly gets healthy (no positive real roots.)

I converted from vectors to functions, then used a solve block (MATHCAD POWER!!!)

See if this can start you off.

[msu12181]

Yes, Fred you are on the right track and the plot should look like an ellipse. If your control surface (in this case a fin) is not stiff enough (K_theta) and starts to couple with the control loop frequency (K_alpha) that turns the fin, you could end up in this region. I am going back through right now trying to decipher what you have done. Thanks and maybe I can get this knocked out with a little more digging.

[Fred_Kohlhepp]

Good luck.

Sorry about the mess!

[msu12181]

Just out of curiousity and my ignorance (see original post), what is the deal with Mathcad not having a GOTO function in its programming toolbar? I have read somewhere that was frowned upon by traditional programers but never understood why. How do you get around this in your own Mathcad programs?

[Fred_Kohlhepp]

I was told once (circa 1983) that a "good" programmer would never need an unconditional "GOTO" statement, that all things could be handled by cases, when, and if then.

That's about the time I stopped programming (in FORTRAN and BASIC.) I'm not sure, but I don't think "C" and its variants have an un directed transfer statement. I have done a bit of LabView (a GUI front end for essentially C) and there isn't one there. So Mathcad is not alone.

I tried to clean up and annotate yesterday's sheet.

[StuartBruff]

Mathcad doesn't have a 'goto' because we let humans program computers and 'goto' is considered a hazard when put in the hands of the average programmer. Humans are reasonably adept at understanding code if the structure is obvious, with reasonably self-contained blocks of code. Incorrectly used 'goto's often lead to code that is difficult at best, and impossible at worst, to read and understand. A really "good" piece of FORTRAN can completely obfuscate the code's structure by having links from just about anywhere to just about anywhere else. This particular coding paradigm is known as "Spaghetti Programming" and often arises when the programmer designs, codes and debugs a program on the fly ("ooh! forgot about that! I know, I'll just loop back here ... but then I've got jump back out of the loop to this bit").

As a major goal of software is to allow some poor soul (who didn't write the program) to to fix or enhance it at some stage, it is considered helpful if they can actually understand it. It is a huge bonus if the original programmer can also understand it after leaving it alone for two days. Hence, because of their encouragement of badly structured programs, 'goto's are strongly discouraged. I've converted a number of FORTRAN programs to Mathcad and, IMO, they're usually a lot simpler and easier to understand when the 'goto's have gone.

Stuart

[msu12181]

I agree with that 100%. While in undergraduate school, I cut my teeth on Mathcad (very basic and simple stuff; definitely nothing like this). Believe it or not, we were one of the first classes to go through the whole program of study without having to take FORTRAN, or any programming language class for that matter. It is for this reason when I am now in the work force that I don't understand legacy code like the one presented here. When I try is when I have to come here to get you all to help out me out of my mess. I am grateful for this forum and all of you guys!

[msu12181]

I've converted a number of FORTRAN programs to Mathcad and, IMO, they're usually a lot simpler and easier to understand when the 'goto's have gone.

Stuart

You are more than welcome to try your hand at this one 🙂 Partial done but not understand how to do part 7 and 8 in pdf.

[Fred_Kohlhepp]

I can write the program, but the results don't make sense.

[RichardJ]

In addition to Stuart's points, if you see a GOTO "Label", you know where program control goes to. However, if you see the "label", there is no way to know where control came from except by searching through the (possibly very large amount of) code. It makes programs very hard to understand and/or debug. The only valid reason to use GOTO statements is when you know that someone you really hate will have to modify your code later, after you have left. Then you should use them copiously

[StuartBruff]

Ah, a man after my own heart!

Oh, there is one other major reason to use GOTO to excess ... Job Security.

[msu12181]

So thanks goes out to Fred again for helping me along. I think I am on the tip of putting this one to bed, finally .

Question: How do you get the Mathcad program loop to return every value for K_theta and Real for each iteration on K_alpha? In other words, I would like to see, for each value of K_alpha, a vector of K_theta and a vector of Real (yes I know this is a tremendous amount of data and yea I would make my steps alot bigger for i regarding K_alpha, say on the order of only 10 steps total). To simplify that amount of data, for each value of K_alpha, I would only like to see the associated values of K_theta only when Real =1. Not too much to ask for right, ?

[Werner_E]

Addison Mauldin wrote:

So thanks goes out to Fred again for helping me along. I think I am on the tip of putting this one to bed, finally .

Question: How do you get the Mathcad program loop to return every value for K_theta and Real for each iteration on K_alpha? In other words, I would like to see, for each value of K_alpha, a vector of K_theta and a vector of Real (yes I know this is a tremendous amount of data and yea I would make my steps alot bigger for i regarding K_alpha, say on the order of only 10 steps total). To simplify that amount of data, for each value of K_alpha, I would only like to see the associated values of K_theta only when Real =1. Not too much to ask for right, ?

Maybe like this.

[msu12181]

So there is probably a more compact way to do this, but I finally got the result I was looking to get. Thanks again for all the help especially to Fred and Werner.