Hi guys,
Think I've found a calculation error / bug (using version 0.9 of SMath).

Please see attached the following calculation Shock_absorber_calculation_error. I am talking about result that is marked with green. If calculation for delta_max uses time constant t2 that was calculated with previous functions, delta_max result is wrong.

Now, if you take a look at Shock_absorber_good_result. If I introduce explicitely t2 constant instead of calculated result (marked with blue), delta_max gives the right answer.

Any ideas?
Thanks,

Denis.

Hello Denis,

The first remedy in these situations is to use Optimization|Symbolic,Numeric,None. If this does not help just try to use eval(). In this particular case the expression
[MATH=eng]t.2←τ+1/ω*atan(A.2/B.2)[/MATH]
will simply get "Units don't match" if you try to set it as Optimization|Numeric. Rather peculiar thing with this expression. Every expression or asignment before will not complain if we put Optimization|Numeric but this one will.
I just get everything before as Optimization|Numeric but, surprisingly, the last one must be Optimization|Symbolic and to use eval() with atan()

If you use Symbolic|Numeric it will not work. If you use Symbolic|None the numerical results will report "Units don't match" but the next one will give the correct result.

Rather tricky I must say. I think that the safest way is to use "Optimization|Numeric" when using complicated expressions using units and functions like exponential, logarithmic, trigonometric etc. we have to be extra careful. If we get some difference between symbolic and numeric we have to try all the things. I hope that something can be corrected by Andrey regarding this issue.

Regards,
Radovan

Hello Radovan,
Thank you for the detailed answer. I understand what are you doing technically, but don't understand what was the problem and how to avoid it in the future. For this particular problem I could compare it with output from another program and to debug accordingly. What you are saying is that we need to compare the "convergence" of results by comparing symbolic and numerical oprimization, and if these don't match we got a problem?

Regards,
Denis

Hello Denis,

Wrote

I understand what are you doing technically, but don't understand what was the problem and how to avoid it in the future. For this particular problem I could compare it with output from another program and to debug accordingly. What you are saying is that we need to compare the "convergence" of results by comparing symbolic and numerical oprimization, and if these don't match we got a problem?

SMath deals with his own symbolic engine. Numerical optimization, eval() and units have been introduced afterwards and it is just like a "patch" to the symbolic engine - as far as I understood these things. As SMath works this way, It was realized by many users that there might be problems and both symbolic and numeric will not agree sometimes. I do not know the reason and the most precise answer can give you Andrey, the SMath creator and maintainer.

In this particular cases, when you are interested in only numerical values and work with units - it is advisable to use Optimization|Numeric. If this does not work, like in your case, just "trial end error" will help. To be honest, after your example I think that there are some problems regarding this. I agree that if these don't match we got a problem or SMath failed - rather problematic. The most alarming thing here is that you got the answer but the wrong one. It seems that there is room to improve these things in SMath.

Regards,
Radovan

Fixed in SMath Studio 0.94.

Best regards.