Simultaneous Equations won't Solve

[ptc-1298530]

I'm new at this, so please bear with me. I'm running Mathcad 15 M010 (also tried on Prime 2.0 with the same results)... I'm attempting to use a solve block (Given/Find) to determine the necessary outside diameter of a pipe given a known loading case. When I try to solve the 3 simultaneous equations, I do not get the right answer - matter of fact, the values that I get aren't even valid given the equations I'm using. However, when I merge my equations together in a single equation the solution works fine. I've attached the Mathcad file (Simultaneous equation2.xmcd) with the issue so hopefully someone is up to teaching a rookie how to do this stuff. Thanks in advance.

[HarveyHensley]

Your initial guesses should be feasible values. Assume the dia.out, calc the guesses for I and A.a.

[RichardJ]

As Harvey says, your guesses are too far off. Numerical solvers for nonlinear equations are iterative. They start at your guesses, and head downhill on the objective function surface to find the minimum. In this case it finds a minimum, and then can't improve it, so it gives up. There is a bug here, because Find should report that no valid solution was found, and it doesn't. (In Mathcad 11, right before they rewrote the compute engine, it does report that it can't find a valid solution). In particular, your guesses for I and Aa are orders of magnitude off. Simply increasing I to 10, which is still way off, will get you the correct solution.

[ptc-1298530]

Thanks for the replies - yea I knew my guesses were way off because I was going to some extremes trying to diagnose what was going on with my original set of more logical knowns and guesses. How accurate do I need to be with my guesses, and is it important that I guess either low or high? Picture below (same equation but more reasonable values), if I guess 'I' to be a value of 1 as below, it does not solve right; if I guess it to be 0.1 it does solve right; and if I guess it to be .01 it does not solve right?!? I also never get an error saying it's not solving right. This could lead to some serious errors - anyone have more ideas? Thanks

[ptc-1298530]

It actually only solves correctly with "I" values guessed between 0.06 and 0.1?!?

[Fred_Kohlhepp]

You only have one equation, and one unknown--the diameter.

Recast your solve block:

[HarveyHensley · Accepted solution]

Nonlinear problems with multiple variables can be difficult. The search algorithm is going into non-feasible regions. You have prevented that in the second method by making the substitutions for I and A.a. Another way is to make I and A.a functions of either dia.in or a new variable that is the ratio of dia.in to dia.out. Then you have just one variable to find. With the ratio variable, you set the limits between 0 and 1 which is convenient for all cases.

[ptc-1298530]

Thanks for the clarification - I'm going to have to be more careful in setting up the equations in the future! The remaining question is why I don't get an error when it doesn't solve correctly? Reconfiguring my equations will help some, but it is impractical for me to check every solution in a large sheet to verify it solved correctly! I've lost confidence in the reported solutions at this stage.

[Fred_Kohlhepp]

I'm sorry!

With a fixed inside diameter, both inertia (I) and area (Aa) are direct functions of outside diameter.

So your simultaneous equations collapse (by substitution) into one equation with the outside diameter as the unknown. And that solve block works just fine. Then turning constraints into equations gives you area and inertia.

While what you wrote is correct, as Harvey said, you managed to confuse the solver--returning a negative value for inertia was a good clue. Properly simplified, the solver works correctly.

[HarveyHensley]

The solution it found may not have been an error, just not a realistic, physically possible solution. Mathcad will only report an error if there is a truly mathematical error. If you include enough constraints, then the solution should be okay. Also, you can print a check of the constraints as a routine check. In my reactor models, I check the atom balance for example. Don't give up on the solver. It is truly an amazing tool.

[RichardJ]

No, it was an error. The solution did not satisfy one of the required conditions (not even close). Find should have flagged it as "no solution found". In MC11, that's what you get. The fact that you don't get it in MC15 is a bug.

The results from solve blocks should always be checked. The checks can easily be programmed into Mathcad, so it is not so onerous to do them. Especially, checking for a physically realistic solution is always a good idea!

[HarveyHensley]

You are right about the error Richard. So this made me even more curious. I have attached a new version of the program that keeps the three equations but scales them to 1. That still wasn't enough to get solutions with a wide range for dia.in. Then I added calculated guesses for I and A.a based on the initial dia.in guess. That gives a robust result. I can even start with a dia.in larger than dia.out or with dia.in almost 0 and get the correct answer.

I think the problem with the Find algorithm is that it may not be handling the errors individually but is looking for a single error made up of the individual equation errors. They may have changed something for the error check between versions.

[RichardJ]

When they went from MC11 to MC12 the dynamic units checking was replaced with static unit checking (SUC, for short, because it's an appropriate acronym. SUC sucked so much that a "new" feature in Prime is dynamic unit checking). To do that a lot of the compute engine was rewritten. One consequence of that rewrite was that MC12 was an extremely buggy version. Another consequence was that the only error message a solve block ever returns is "variable not defined", regardless of what the actual error is (that was not the case in MC11). It seems another consequence is that it does not always correctly determine that the solution is not valid. In this case two of the errors are very large, so that is a problem.