 Rank: Newbie
Groups: Registered
Joined: 21/04/2010(UTC)
Posts: 7
|
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. Edited by user 29 January 2012 11:16:09(UTC)
| Reason: Not specified
|
|
|
|
|
|
  Rank: Administration Groups: Registered, Advanced Member Joined: 23/06/2009(UTC) Posts: 1,740   Was thanked: 318 time(s) in 268 post(s)
|
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 t.2←τ+1/ω*atan(A.2/B.2) 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 Edited by user 29 January 2012 14:03:42(UTC)
| Reason: Not specified |
When Sisyphus climbed to the top of a hill, they said: "Wrong boulder!" |
|
|
|
|
|
Rank: Newbie
Groups: Registered
Joined: 21/04/2010(UTC)
Posts: 7
|
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
|
|
|
|
|
|
Rank: Administration Groups: Registered, Advanced Member Joined: 23/06/2009(UTC) Posts: 1,740 Was thanked: 318 time(s) in 268 post(s)
|
Hello Denis, Nexus 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 Edited by user 29 January 2012 15:45:45(UTC)
| Reason: Not specified |
When Sisyphus climbed to the top of a hill, they said: "Wrong boulder!" |
|
|
|
|
|
 Rank: Administration Groups: Developers, Registered, Knovel Developers, Administrators, Advanced Member Joined: 11/07/2008(UTC) Posts: 1,616  Was thanked: 1978 time(s) in 666 post(s)
|
Fixed in SMath Studio 0.94.
Best regards.
|
 1 user thanked Andrey Ivashov for this useful post.
|
|
|
|
Forum Jump
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.
