ACCEPTED SOLUTION
Accepted Solutions
The "undefined variable" error is the only error a solve block will ever yield - no matter what the real cause for failing may be. If you right click the error and chose "Trace error" you (sometimes) see whats really going on - no solution was found because you are working at the limits of the tolerance settings.
In your case you are dealing with rather big and also some very small numbers and especially when you work with units this very often throws a solve block off the track.
I wonder why you would use a solve block anyway, given that you can solve those equations directly very easy by hand (and if not you can use the symbolics solve - see at the top).
You may also use the symbolic solver for your specific task.
See attchment.
The "undefined variable" error is the only error a solve block will ever yield - no matter what the real cause for failing may be. If you right click the error and chose "Trace error" you (sometimes) see whats really going on - no solution was found because you are working at the limits of the tolerance settings.
In your case you are dealing with rather big and also some very small numbers and especially when you work with units this very often throws a solve block off the track.
I wonder why you would use a solve block anyway, given that you can solve those equations directly very easy by hand (and if not you can use the symbolics solve - see at the top).
You may also use the symbolic solver for your specific task.
See attchment.
Similar approach but included units. I have used the symbolic Find function while Werner has used the Symbolic Solve function.
At least you variation 
.
Mike Armstrong wrote:
Similar approach but included units. I have used the symbolic Find function while Werner has used the Symbolic Solve function.
At least you variation
Best to solve this kind of equations without any "Find" or "solve" but using direct assigments - the equations are easy enough.
And with real tough, complicated equations, Mathcad's symbolics unfortunately ever so often tends to fail 
Werner Exinger wrote:
Mike Armstrong wrote:
Similar approach but included units. I have used the symbolic Find function while Werner has used the Symbolic Solve function.
At least you variation
Best to solve this kind of equations without any "Find" or "solve" but using direct assigments - the equations are easy enough.
Fully agreed on.
Mike Armstrong wrote:
Try solving symbolically. I have stripped the units for ease of understanding.
Without units the first solve block gets a solution numerically, too, without any modification whatsoever.
To make the second solve block work numerically, you have to provide a decent guess value and set CTOL way up to 10 (from the default 10^-3)!!
Adding units will increase the problem, though.
Werner Exinger wrote:
Mike Armstrong wrote:
Try solving symbolically. I have stripped the units for ease of understanding.
Without units the first solve block gets a solution numerically, too, without any modification whatsoever.
To make the second solve block work numerically, you have to provide a decent guess value and set CTOL way up to 10 (from the default 10^-3)!!
Adding units will increase the problem, though.
Are you sure? Mine does not find a solution and I think you are missing T.i from first equation.
Mike Armstrong wrote:
Werner Exinger wrote:
Mike Armstrong wrote:
Try solving symbolically. I have stripped the units for ease of understanding.
Without units the first solve block gets a solution numerically, too, without any modification whatsoever.
To make the second solve block work numerically, you have to provide a decent guess value and set CTOL way up to 10 (from the default 10^-3)!!
Adding units will increase the problem, though.
Are you sure? Mine does not find a solution and I think you are missing T.i from first equation.
You are right! T.i is missing because I used the sheet you posted and the variable is already missing there 
With T.i in place we would have to set CTOL up to 10^2 to get a numerical solution.
Werner Exinger wrote:
You are right! T.i is missing because I used the sheet you posted and the variable is already missing there
With T.i in place we would have to set CTOL up to 10^2 to get a numerical solution.
Oops. I must have deleted it by mistake in my first sheet. At least my second sheet is correct.
Mike Armstrong wrote:
Werner Exinger wrote:
With T.i in place we would have to set CTOL up to 10^2 to get a numerical solution.
I don't see the logic with having to change CTOL locally in the worksheet. Would it not be a better solution to have the numerically processor non-dependant, as with the symbolic processor?
Guess thats a more subtle problem. The algorithms used by the symbolics may fail while the numeric approximation algorithms still yield a result. The problem here is the absolute tolerance value used while a relative tolerance value would be more preferable (but probably may lead to other problems).
A standard way out here is to use MinErr instead of Find. Don't know why I didn't thought of it in the first place - probably because my first thought was "why a solve block at all?".
Werner Exinger wrote:
Mike Armstrong wrote:
Werner Exinger wrote:
With T.i in place we would have to set CTOL up to 10^2 to get a numerical solution.
I don't see the logic with having to change CTOL locally in the worksheet. Would it not be a better solution to have the numerically processor non-dependant, as with the symbolic processor?
Guess thats a more subtle problem. The algorithms used by the symbolics may fail while the numeric approximation algorithms still yield a result. The problem here is the absolute tolerance value used while a relative tolerance value would be more preferable (but probably may lead to other problems).
Right I get you. So it is good practice you try and solve numerically before trying symbolically?
Werner Exinger wrote:
A standard way out here is to use MinErr instead of Find. Don't know why I didn't thought of it in the first place - probably because my first thought was "why a solve block at all?".
I also attempt this route first, but seem to shy away from it when I get a result. Is it safe to rely on Minerr?
Right I get you. So it is good practice you try and solve numerically before trying symbolically?
Why not the other way round? If the symbolics yield a result I would trust it the most (at least thats as it should be). But we know there are cases where the symbolics fails and the numerics gives us a result. And we also have it the other way round like in this example.
I also attempt this route first, but seem to shy away from it when I get a result. Is it safe to rely on Minerr?
Within Mathcad's usual numeric precision and tolerance I would say, yes. At least we get the best result Mathcad is able to find, no matter if the difference to the last but one value in the iteration is smaller than CTOL or not. Double checking the result it it fits the problem is a must anyway.
Werner Exinger wrote:
Right I get you. So it is good practice you try and solve numerically before trying symbolically?
Why not the other way round? If the symbolics yield a result I would trust it the most (at least thats as it should be). But we know there are cases where the symbolics fails and the numerics gives us a result. And we also have it the other way round like in this example.
I also attempt this route first, but seem to shy away from it when I get a result. Is it safe to rely on Minerr?
Within Mathcad's usual numeric precision and tolerance I would say, yes. At least we get the best result Mathcad is able to find, no matter if the difference to the last but one value in the iteration is smaller than CTOL or not. Double checking the result it it fits the problem is a must anyway.
In this instance it has worked, but I have seen results in the past which are incorrect. As you said, double checking is a must.
