Hi Laurence

I made something similar for my FEA classes. It could be done much simpler, but the target was to demonstrate how the global system is assembled and reduced based on constraints.
I found the det function unreliable. Thus I was not able to demonstrate the singularity of the unconstrained system and the regularity of the reduced one. You need to apply scaling which need to be adjusted to a very narrow range where the det function will work at all.

The sheet is in german but the code should be self documenting.

Best regards, Martin Kraska

Hi Martin and Ioan

Very many thanks for your replies, the sheets are very informative and given me some great ideas for solving this - I can see how you have used the 'for' loops to achieve the transformations. (Also the graphics are a very useful addition, that's the next thing for me to implement now!).

From the teaching perspective, I tend to teach the hand calcs with reduced DOF's but wanted to show the students the logistics of programming the method in a general way, i.e keep all DOF's to show the singular global matrix then how to apply boundaries to the system to remove the singularity. Anyway, still not sure why my for loops don't work, but I won't lose too much sleep, I'll use your methods.

Thanks once again!

Laurence

Hi Laurence

evaluation of expressions is one of the biggest mysteries of SMath. I have never seen (or better: understood) a consistent description of what the interaction of numeric and symbolic evaluation is meant to work.

In your case the assignment to the variable disp delays the evaluation to the point where disp is going to be displayed. Immediate evaluation of KG^{-1}*P works but delayed does not (Why?). You can enforce immediate evaluation upon assignment to disp by using the function eval():

disp:eval(KG^{-1}*P)

results in

disp=mat(0.183,-0.527,-0.078,-0.41,1*10^{-16},-3.91*10^{-17},-1*10^{-16},-6.09*10^{-17},8,1)

(mm unit refused to be displayed in the post preview, therefore I removed it from the result)

Equally well you can generate the precision problem by switching to symbolic optimization in the immediate evaluation of KG^{-1}*P. You get something ugly like:

KG^{-1}*P=mat(-154029677706911/1227751447183550,371846259893873/1635302861611220,150994944000000/282161279734733,395987199384982/508161646518145,-1949477283233400/115154739031931000000000000000,71907646210181/9860498487058500000000000000,-1453125/2091995697675820000000,185335047104285/8598781694818370000000000000000,8,1)

Want to know what the decimal representation of this is? Do not hope for just switching back to numeric optimization. Instead copy the result and evaluate that numerically:

mat(-154029677706911/1227751447183550,371846259893873/1635302861611220,150994944000000/282161279734733,395987199384982/508161646518145,-1949477283233400/115154739031931000000000000000,71907646210181/9860498487058500000000000000,-1453125/2091995697675820000000,185335047104285/8598781694818370000000000000000,8,1)=mat(-0.13,0.23,0.54,0.78,-1.69*10^{-14},7.29*10^{-15},-6.95*10^{-16},2.16*10^{-17},8,1)@#

This is the garbage result that you had to face when displaying the variable disp.

Just to emphasize the problem: numeric evaluation of exactly the same expression results in

KG^{-1}*P=mat(0.183,-0.527,-0.078,-0.41,1*10^{-16},-3.91*10^{-17},-1*10^{-16},-6.09*10^{-17},8,1)

Seems like a severe bug in the symbolic engine. This makes me recommend to my students not to use symbolic features at all. However, than you would have to embrace every expression with eval() before assignment. This looks really ugly in otherwise nice smath sheets. Still the general rule seems to apply: The more questionable the results are, the more evals you should spread over your sheet.

Once I made the proposal to introduce different assignment operators for delayed and immediate evaluation, say :<- and := respectively.
Also, symbolic and numeric evaluation (aka "optimization" ) should be visually distinct, say = and -> (as in Mathcad)
You may have noted that many examples and bug reports have expressions with comments like "symbolic" just to indicate what could be visible from a consistent notation. However, this seems to be a matter of taste or not easy to implement.

It seems to me that the default assignment type is symbolic/delayed. How about switching the default to immediate evaluation? Half the traffic in the forum could be saved. Those who want trouble really hard, could perhaps be given a function symb() ;-)

Best regards, Martin Kraska

Edited by user 30 September 2012 03:18:57(UTC)  | Reason: Not specified

Hi Ioan,

thank you for pointing out the straight solution. Indeed this works without using eval. I guess you need eval if such assignments are done within procedure definitions where there is no other way to control optimization on a statement by statement base.

Would be interesting to know Andrey's priority level of this problem. I guess that debugging the symbolic engine is far from being fun. My hope is that there is at least a chance to have the visual markup of symbolic/numeric optimization resolved. Otherwise one cannot trust printed SMath sheets, as Laurence's example again demonstrated. I even would ask for a global preference setting to numeric evaluation.

Best regards, Martin Kraska