Symbolic Solve question

[GregBohn]

Hi;

I am trying to use symbolic solve in MathCad 14 M020 and ran into a problem where it says the result is too large to display, and then ends up with the blinking 'light-bulb' for hours without producing a result (on a following operation involving the prior result).

I was hoping someone could look at this and let me know what I'm doing wrong. (Interrupting this often seems to crash MathCad itself after this when I try to do more work).

I'm attaching a V11 and a V14 version.

Basically, I'm starting with an equation that converts Kinematic viscosity in cSt to 'Saybolt Universal seconds'. I'm hoping to 'reverse' this to come up with an equation to return cSt when SUS is input.

Thanks;

-Greg

[TomGutman]

Yes, it should have worked. And it does work -- in MC13. Apparently the new symbolic processor in MC14 produces some result that cannot actually be assigned, even for symbolic use. Possibly one of the odd conditional constructs (which should occur only with the fully keyword, but seem to pop up otherwise anyway), possibly just overflowing some limit.

But note that you are effectively solving a quartic equation, and you should expect (and with MC13 you actually get) four solutions.

Additional notes: You can simplify things a bit by not solving for cSt in terms of SUS and Temp_Fact but rather in terms of a single variable SUS/Temp_Fact. Not that that helps in MC14, which still fails. Also, there is no need to split the definition of the function from the solution. You can define tghe solution directly as a function. It still doesn't work, but you do get a different error message.

I did not get the endless loop condition. That is probably just the instability of the symbolic processor and dependent on the history of its use. It is often necessary to close Mathcad and restart a new instance to clean up the symbolic processor after stressing it.
__________________
� � � � Tom Gutman

[AlvaroDíaz]

Try numerical solvers. Also, check TempFact, is in bot variables and constants font.


Alvaro

[GregBohn]

> and you should expect (and with MC13 you actually get) four solutions.

Thanks.

Does MC13 also produce the 'too large' warning as well? If not, since I don't have access to MC13, would it be too much trouble to extract those 4 solutions to a .mcd or xmcdz file so I could see if I could use any of them? 🙂

If they're impractically large, I understand that this isn't possible.

I suppose I could dig out and install my old MathCad 2001, if I could expect this to work any better (in the sense of producing a manageably sized symbolic result I could type directly into a MC14 worksheet).

Otherwise I guess I'll fall back to the numeric solve block.

Thanks again;

-Greg

[AlvaroDíaz]

On 5/7/2009 2:20:16 PM, gbohn wrote:
>Otherwise I guess I'll fall back to the numeric solve block.

polyroot function added, all solutions in numerical evaluation, without calling symbolics.

Alvaro.

[GregBohn]

> polyroot function added, all solutions in numerical evaluation, without calling symbolics.

Thanks. I see that of the four solutions found, two are imaginary, one is positive, and one is negative.

For my purposes here, only the one positive (non-imaginary) result applies.

Originally, I was hoping to get MathCAD to show me a (hopefully simple) 'reverse' equation to use. But, these other methods will let me solve my problem numerically instead.

Thanks.

-Greg

[TomGutman]

Quartics rarely have reasonable solutions. FWIW I've done the copy and paste as requested. I haven't bothered selecting the desired root -- I doubt you really want to use this expression.

I suggest finding a reasonable approximation function, one or two digits accuracy, over the range of interest and then using that as a guess value for root or find. Since this is clearly an empirical formula anyway, you might be able to find a polynomial or rational polynomial approximation that is close enough for your purposes. You could do a bit better if you could get the original data on which this approximation is based, as that would avoid adding the error in the inverse approximation to the error in the given formula.
__________________
� � � � Tom Gutman

[ptc-1368288]

... if things could be scaled around 0 here is the series required for Lagrange inversion. Nice and simple, but it does not work or nothing comes out ! The Lagrange inverser is proven to work from other projects done. Doing something really wrong. Sorry for that yet.

Version 11.2a, your modules disabled.

jmG

[ptc-1368288]

... I have another inverser to be tried.

jmG

[ptc-1368288]

NOT 'reverse'... but ! Inverse !

What you are trying to do, as far as I got it, you are trying to solve for cSt given SSU ... is it ? No software will do as there are so many roots. We have in Mathcad the Lagrange 7 terms series inversion, that would do if the function can be converted in McLaurin series. As far as now: no luck because you have a rational P(x)/Q(x). But it can be done otherwise by taking instead a Cheby equivalent function ... at that point then we will have an equivalent polynomial therefore expandable in series.

Another approach is to convert your function in Fourier polynomial ... bingo again for Lagrange. There are other ways... for a point value, Given/Find should do. You could discretize and solve for a range and if sufficiently linear, then linterp. You could also "RootScan" for a very fine data solution thenthenthen, get a fit.

Apparent simple tasks do require quite a toolbox !

This project is estimated one day (per say). What that means to you is to decide you pursue the project or not. If so, you must supply the SSU data set. If lucky with no surprise, it might take only few minutes because of the unimaginable toolbox there is in this collab.

"I'll probably end up creating a solve block with a 'given.... find()' section, but I was hoping I could get Mathcad to provide an (adequate) equation for finding cSt when given SUS".

Like explained, it is not mathematically possible to ! Inverse ! that function directly as you attempted.

jmG

[ptc-1368288]

On 5/7/2009 12:42:21 PM, gbohn wrote:
>...
> Thanks;

> -Greg
____________________________________

What you have there is a very minute fraction of a much larger and complete set of model sheets about inversing function. This expos� is in fact very close to the "Trace tracking tool" and the contour plot in the 3D. A supplementary example is left for your interest. As a matter of fact it does inverse your function with great elegance and robustness. For your case, it is not necessary to TOL < default 0.001. As such it is "Target value", but it is easy to discretize and tabulate. Oh ! the series got truncated from my previous attempt with Lagrange but if you want it at your full original, no problem.

Enjoy this precious tool, only hinted in the collab but never published. Was finally much less time consuming than expected ! You had another front end factor in your function, but as it was not qualified neither quantified, just ignored it.

jmG

[ptc-1368288]

The attached Given/Find solver application is iterative. A construct of great elegance, modular, discretized for export . Finally a continued fraction is given. For that last formula, the steps are not shown and the reason is that ! NO collab 14 ! have ever replied on that kind of work done with Thiele, replying: works/DOES NOT WORK ! So, this time, nobody will see what's under the hood.

Created 11.2a, saved for many precious 2001i collabs.

jmG

[ptc-1368288]

... the series is not convergent and really for the birds. Here is the way to construct as you didn't hint about 'T'. As simple as the previous post (not the Mach number). The Maple RootOf was mystic to many collabs for years, but few months ago I exploited it to its full power and flexibility. An incredible piece of symbolic solve.

Try it on your own, I will help.
If your 14 turns red, I will reconstruct.

What's red in 11.2a is the 'f' in f(x) but that does not matter. You have to range 'x' for an eventual reconstructed inverse function ...if that's what you are looking for. I can do it "general", but too many collabs come with problems, they get gorgeous solutions from many hours of multi-collaboration but very few come back letting us know if they are gone with the wind or gone fishing for ever.

A bit of abstract woud help, what is SUS ? what is cSt ? I understand cSt = centiStokes ! For what purpose do you need to get cSt out of SUS ? Will it be useful for the public or simply an in-house utility. Sometimes we do things for personal use and suddenly they explode as a breakthrough in the public domain, you see my points.

Resume:
Come back, if your 14 stalls, my next door has a 500 HP stagger.

jmG

[ptc-1368288]

... here is your project done. Please read all the notes, especially about "initial". You just need to add the limits for 'SUS' and 'T'. The names of your variables has been preserved. A little abstract or hint from you would be appreciated because I will add to my collection to illustrate as general "function solver".

It would easy to construct some table of conversion.

jmG

[ptc-1368288]

... few things added to reply in advance more questions, like view the inverse function and about a function for it.

jmG

[GregBohn]

> A bit of abstract woud help, what is SUS ? what is cSt ? I understand cSt = centiStokes !
> For what purpose do you need to get cSt out of SUS ? Will it be useful for the public or simply
> an in-house utility. Sometimes we do things for personal use and suddenly
> they explode as a breakthrough in the public domain, you see my points.

Right now I'm a bit overwhelmed with the bounty of results provided. I need to spend some time looking over and understanding how the solutions provided work. Thanks to everyone for helping!

What I can do now (relatively) quickly is to fill you in on my understanding of the history of SUS/SSU and cSt.

I started looking at this when I was setting up a sheet with various methods I have found for predicting the viscosity/thickness of a blend of two different viscosity component liquids (such as motor oils).

I came across one blend formula I wanted to try that specified the viscosity in 'Saybolt Universal Seconds'.

In the 'old' days, a popular way to measure Viscosity (at least in the US petroleum industry) was with a device called a 'Saybolt Viscometer'. This contraption measured viscosity by timing how long it took for a specific amount of liquid to drain through an orifice under the influence of gravity (at specific temperatures).

The results were recorded in Saybolt Universal Seconds (sometimes also known as Saybolt Seconds Universal as well). Eventually this became defunct and was replaced with the use of the centistoke units (so you no longer had a unit based on the results from a type of device as much as a physical property).

Formulas were empirically devised in the industry to convert between cSt and SUS to allow old published works to still be used. I've only found a few of these these formulas, and some are much more accurate than others (or have differing ranges over which they are accurate).

At least, that's my understanding...

I came across what looks like the most accurate conversion formula I've seen so far. But, it's only in the form of taking the cSt value, and returning the equivalent SUS from this.

I erroneously thought that there might be an inverse form that wouldn't be much worse than the original...

In my case, I don't really need the conversion other than to convert from cSt (on input) to SUS for the blend formula, and then take the results in SUS and convert that back to cSt for the result.

So, a relatively simple SUS to cSt formula might have some interested parties, but I would have to guess that it's probably a limited group. (Perhaps of octogenarians who remember using SUS 🙂

At any rate, I plan to look over the various solutions. It'll just take me some time to look over the bounty of worksheets...

Thanks;

-Greg

[ptc-1368288]

All that clears few items:

1. Set init 100
2. 2 < cSt < 100
3. 32.66 < SUS < 462.9
4. Your formula gives 32.6, 463.5 ... Not bad
5. not bad either at cSt = 20
6. Your formula seems suffering from truncated coefficients.
7. Your formula is for T = 1 but T should in reality be related to a ratio of actual temperature vs the reference T of the SUS data.
8. An "InverseFunction" formula can be provided in other to have a transportable tool. I might do tomorrow or sometimes soon.
9. All that said, here is the revised sheet.
10 Note that the "root" as provided is "Target value" in Excel.
11. We can extract an equivalent "Inverse data set" from Given/Find.

Amazing that the designers of the cSt ==> SUS didn't figure to provide the inverse SUS <== cSt. Maybe not needed at the time of the slide rules as there were so many designed for specific applications.

jmG

[GregBohn]

> didn't hint about 'T'

The short .mcd file attached shows the slightly 'fuller' form of the equation where the calculation of the 'Temperature correction Factor' is included.

It basically takes the matching temperature that the measurement was taken under and applies a temperature correction factor that's required. I originally showed this as a direct value of 1.0066.

(I did this in MC 14 M020 and saved in MC11 format.)

-Greg

[ptc-1368288]

Your T = 1.0066 does not change anything (visibly).
Simplify the T = 0.9939 + 6.1e^-5.
I guessed (but not sure) it was linear. It seems possible to Minerr the cSt formula. One way or another it is already Minerred, but what can be done is forcing the formula to pass exactly at a reference point, per say cSt = 20 .

I like very much your step by step guidance.

jmG

[TomGutman]

The key questions are what range of cSt (or equivalently SUS) you need, and what accuracy you need.

A quick plot shows that for large values of cSt SUS asymptotically approaches just the linear term in the equation. That suggests that you could get a good fit with a simple rational polynomial.

But what of the blending formula? What is its range of applicability? It is quite possible that it is simpler in cSt units, and has just been adjusted for use with SUS units.
__________________
� � � � Tom Gutman

[ptc-1368288]

On 5/9/2009 2:27:37 AM, Tom_Gutman wrote:
>The key questions are what
>range of cSt (or equivalently SUS)
....
>__________________
>� � � � Tom Gutman

___________________

cSt 2 ......100
SUS 32.66 ...462.9

XY data table from source at the bottom.

jmG

[GregBohn]

> TEST-SUS-V11[JMG](4).MCD (25KB



This gives me some red sections when I open this in MC14 M020. I have attached two screen shoots.



Is this expected?



-Greg

[ptc-1368288]

On 5/10/2009 12:07:30 PM, gbohn wrote:
>> TEST-SUS-V11[JMG](4).MCD (25KB

This gives me some red sections when I open this in MC14 M020. I have attached two screen shoots.

Is this expected?

-Greg
_______________________

The first error was expected and is normal because your Mathcad/MuPad where MuPad is just a piece of crap ! It clearly identifies that MuPad has not general symbolic algebra engine. Just few bits and pieces. That's why Mathcad does not exist anymore after version 11.2a. However if they had maintained the more general Given/Find from the original Mathsoft, you will be able to achieve the same or near the same.

For the 2nd error message, it means you have to define a function of f(�F):=

What it means: you can make it work for the 2nd error message, and ignore the first one, because foreseeing that I did the reconstruct and it seems my reonstruct works for you. Simply that you can't do general solving becuse of MuPad .

What you can do is make your own (or at least start) Gven/find solver. You have no symbolic extractor and by same token, yourself and all 14 users will remain ignorant about the symbolic algebra solver that others like Maple have. Like not knowing that the moon has an hidden face. Not that important either, Mathematica can't do.

BTW, I have checked for a better approximation of the SUS/cSt data. The best would leave � 0.125 ... better than yours. I have been tempted to exhaust the toolbox for better fitting but can't do that much better because of the 2 decimals in the SUS data table. Maybe not needed to be that much better either ! I can't understand why the SUS ==> cSt is not linear, except that for SUS being zombie collection and/or bad lab equipment at the time it was done.

jmG

[ptc-1368288]

... plug that in your MuPad.



If an error message again, that will confirm definitively and definitely that MuPad has no symbolic algebra solver. I wish I had been little bird ... is it Maple who decided that PTC would be incapable or PTC deciding "f... " Maple ? Whatever, Mathcad went RIP in April 2006.

jmG

[GregBohn]

> I can't understand why the SUS ==> cSt is not linear, except
>that for SUS being zombie collection and/or bad lab equipment at the time it was done.

(I thought I posted a reply this morning, but I don't see it. So, I'm creating another reply).

I'm just doing this as a hobby, so I'm not a definitive source. But, my guess is that the design of the Saybolt viscometer results in the non-linearity.

For one thing, drawings I've seen seem to indicate that it had a relatively short nozzle. The glass viscometers I use (Cannon-Fenske Routine) have a much longer capillary tube. There and also specified ranges on the 'rate of sheer' in the fluid. If the fluid becomes turbulent, that would alter the timing from optimal as well. (They attempt to maintain a laminar flow).

I'm thinking the Saybolt was something that was adequate for the Industry needs at the time, but turned out to be non-linear across the entire range.

I've discovered that the more precisely you try to measure something, the more 'secondary factors' need to be taken into account. Like 'air buoyancy' and 'True mass' corrections that need to be done when you do something as seemingly simple as precisely weigh an object.

Today, I see glass capillary viscometers (for measuring kinematic viscosity) that cover down to 0.5 cSt. But, each 'size' usually only covers about a 5x range. I think some of this comes simply from the number of seconds the limits take (too few or too many to be practical). But, I think some of this if from the various factors affecting accuracy that come into play when you go outside those limits.

That's my theory anyway...

-Greg

[ptc-1368288]

� you got it right Greg,

Each physical primary device is only good in very short range and the overlapping from one type to another is not guaranteed and the final combination is another problem. Being that close to linear but not being, there is a snake in the garden. The conversion formula is home made,the first term is the "linear term", from which they have concluded an error plot and superposed a correction term.

jmG