MBSimControl::Sensor may provide old values

[GoogleCodeExporter]

MBSim has a "update on request" strategy:
e.g. explicitly call updateg(), updatezd(), ...

MBSimControl has as "update on demand" strategy:
if Signal::getSignal() is called the getSignal() function of all dependent 
signals are automatically called which updates all dependent signals 
automatically.

However all MBSimControl::Sensor's get their signal from MBSim elements:
e.g. MBSimControl::LinkDistanceSensor::getSingal() reads the distance from 
link->getg(). If the getSignal function is now triggered by another MBSim::Link 
it is not ensured that link->getg() is already updated by the corresponding 
MBSim::updateg() function because the evaluation order of Links is not define. 
Hence it may be possible that one gets the value for the last time step 
(without any notice). And using values form last time steps may cause 
instabillities.

What should/could we do here?!

Original issue reported on code.google.com by friedrich.at.gc@googlemail.com on 15 Nov 2014 at 8:05

[GoogleCodeExporter]

This is very bad and should be fixed.

Changing MBSim to an "update on demand" strategy may have a bad effect on the 
performance so we should think about a consistent "update on request" strategy. 
This requires a check of all dependencies during the init-process and a 
reorganization of the links to get the right evaluation order. This is what we 
already do for the objects to model tree structures.

Original comment by martin.o...@googlemail.com on 16 Nov 2014 at 11:27

• Changed state: Accepted

[GoogleCodeExporter]

I think an "update on demand" strategy in kernel MAY have a good effect on 
performance. But to implement this in a performant way is sure very very 
complicated. Maybe such complicated that it will get imperformant. So, i also 
think that changing MBSimControl to "update on request" is the right way.
Since all Links are, after reorganize hierarchy takes place, grouped in a 
single list in DynamicSystemSolver this may be not so tricky. We just need to 
get the dependencies from all Links and sort these propably. However, if we 
consider parallelization (the not checked in code of Jan) this will get more 
complicated.

Original comment by friedrich.at.gc@googlemail.com on 16 Nov 2014 at 4:30

[friedrichatgc]

Work in progress. See branch newUpdateConcept.

[friedrichatgc]

Fixed. newUpdateConcept already merged to master