  Rank: Advanced Member Groups: Registered
Joined: 25/09/2013(UTC) Posts: 325  Location: IL Was thanked: 19 time(s) in 17 post(s)
|
See attached calculation. I seem to have an issue with the 4 term summation inside the for loop. I can't figure out the issue. Does anyone know the correct way to solve this? Thanks!
|
|
|
|
|
|
Rank: Advanced Member Groups: Registered
Joined: 15/04/2012(UTC) Posts: 1,985  Was thanked: 1124 time(s) in 721 post(s)
|
The problem is in the sum under "Torsional Shear force". The sum in the denominator runs from 1 to # of columns in your data matrix. However, the quantities under the sum are known only up to current n. If you replace n for the upper sum limit then you get a result. However, I don't know if that is what you want. mkraska attached the following image(s): |
|
|
|
|
|
|
Rank: Advanced Member Groups: Registered
Joined: 25/09/2013(UTC) Posts: 325 Location: IL Was thanked: 19 time(s) in 17 post(s)
|
Martin,
You show "n" in your image however in the calculation I use "cols(MWallinfo#)" so it should sum from 1 to 6 (which happens to be the number of columns in MWallinfo#).
Unless I'm missing something?
Is there a better way to do this? Basically the denominator should be the sum of R*r^2. I've tried placing this sum elsewhere, etc. and nothing seems to work. Not sure what I'm doing wrong. Even if I replace "cols(MWallinfo#)" (above the summation) with 6 I still receive an error.
|
|
|
|
|
|
Rank: Advanced Member Groups: Registered
Joined: 17/01/2013(UTC) Posts: 296   Location: Khabarovsk, Russia Was thanked: 151 time(s) in 107 post(s)
|
Well,
the problem is in dimensions of R,w# and r,w#.
The summation needs them both to have at least cols(MWallinfo#) items in 1st row.
But they are filled along the iterations.
At first iteration, first member of r,w# is zero. (All members of R,w# are non-zero). SMath seem to stop evaluating when the dividend is zero...? Maybe it uses some (incorrect) optimisation?
Second iteration follows the same path, but on third iteration the third element of r,w# is 8*10^-14 m, so the calculation of divider starts and gives the error.
Try to pot trace(n,R.w#,r.w#) just before the summation line in your calculation, and see the trace window result. |
Best regards,
Mike Kaganski |
|
|
|
|
|
Rank: Advanced Member Groups: Registered
Joined: 25/09/2013(UTC) Posts: 325 Location: IL Was thanked: 19 time(s) in 17 post(s)
|
Mike,
I see. What you're saying makes sense. So really I should break the for loop before the summation. And then I can start another for loop after.
Thanks.
|
|
|
|
|
|
Rank: Advanced Member Groups: Registered
Joined: 25/09/2013(UTC) Posts: 325 Location: IL Was thanked: 19 time(s) in 17 post(s)
|
While the calculation still has a ways to go, I've pushed believe I pushed past the summation issues. Mayme there is a better way though... Attached is the updated routine.
|
|
|
|
|
|
Rank: Advanced Member Groups: Registered
Joined: 25/09/2013(UTC) Posts: 325 Location: IL Was thanked: 19 time(s) in 17 post(s)
|
I know have a very long run time for this particular set of information. Description: Stopped working Problem signature: Problem Event Name: APPCRASH Application Name: SMathStudio_Desktop.exe Application Version: 1.1.27.0 Application Timestamp: 53f63c27 Fault Module Name: KERNELBASE.dll Fault Module Version: 6.1.7601.18015 Fault Module Timestamp: 50b8479b Exception Code: e053534f Exception Offset: 0000000000009e5d OS Version: 6.1.7601.2.1.0.256.48 Locale ID: 1033 Also I have a separate function outside of the main function. Is it better to put this function inside the main function or leave it separate? Does it matter? Edited by user 01 December 2014 21:45:04(UTC)
| Reason: Not specified
|
|
|
|
|
|
Rank: Advanced Member Groups: Registered
Joined: 25/09/2013(UTC) Posts: 325 Location: IL Was thanked: 19 time(s) in 17 post(s)
|
Any idea on why this won't converge to an answer? Seems to work for other input but something is going on that I can't seem to figure out.
Thanks again!
|
|
|
|
|
|
 Rank: Advanced Member Groups: Registered, Advanced Member Joined: 13/01/2012(UTC) Posts: 2,647  Location: Italy Was thanked: 1329 time(s) in 875 post(s)
|
Basically, you have to place an eval() outside each sum() - thus when you made calculations of rigidities. Without, SMath output very high numbers and so "result is above max allowed positive number" errors are triggered in the functions. I suspect this is because units with high powers are involved. You can see what happens in the 3 last images attached. Maybe the numbers of not evaluated R.totY# are correct, but further calculation not allowed (if you copy the output from the trace window, and you try to get a result, you get the error). Also, all the optimizations are set to "numeric" in the attached worksheet (average calculation time on opened worksheet: 0.45s). BTW, debugged with the trace() function. Best regards, Davide P.S.: issue opened ( SS-1249) Edited by user 20 August 2016 20:30:47(UTC)
| Reason: Not specified File Attachment(s): Davide Carpi attached the following image(s): |
If you like my plugins consider to support SMath Studio buying a plan; to offer me a coffee: paypal.me/dcprojects |
|
|
|
|
|
Rank: Advanced Member Groups: Registered
Joined: 25/09/2013(UTC) Posts: 325 Location: IL Was thanked: 19 time(s) in 17 post(s)
|
|
|
|
|
|
|
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.
