Recalculation - what's going on?

[David Usherwood]

For quite a few years now I have been quoting the following passage from a note written by Manny Perez in the old Center of Excellence

"Any time an input cell is changed, all stored calculations of the cube where the change is made and all dependent cubes are invalidated.
A cube X is dependent on cube Y, if any of its values are calculated (via rules) using values in Y."

This was dated 1 Dec 05, updated 7 Feb 06. It's about ReadersBypassWriters - but the statement stands on its own. Of course it predates 9.1 and later versions, but my belief is (was) that the changes in those versions related to input locking, not to calculation. I am inclined to take Manny's views on this subject as well founded as he wrote the code .

I have worked with this behaviour in the past to manage the size of the server, resetting the calculation cache periodically by sending a value into a corner of a cube.

I am looking at using this technique at a current client whose server is running up to 50 gig. I have built some test routines, but I was surprised to see, _sometimes_, that sending a value into a cube has not been resetting the calculation cache. A precalculated high level view refreshes instantly, and the stats in }StatsforServer do not go to zero.

I had this once, then in another session, I had the 'expected' behaviour. A 3rd session has given the same result as the first.

Has anybody else found this?

The version I am using here is 90 SP3 U9 - but as I said above, I don't believe the behaviour is different for later versions.

[Martin Ryan]

Early on with TM1 I was under the impression that the cubes intelligently invalidated consolidations, but I had that blown out of the water a couple of years ago when I saw a roadmap that said something they wanted to achieve in the future was intelligently invalidating consolidations, rather than ruining the whole cube. (Hopefully no-one at IPC can remember me saying it worked that way )

If I remember your methodology, you use TI to store the current value in a variable, then send a zero, then reload the current value, is that correct? Is it possible you're overwriting a zero with a zero, then replacing the original zero - i.e. nothing has changed? I don't believe that gets logged, therefore there's probably no knowledge in TM1 that the number has changed, so no need to flush out the old calcs.

Martin

[David Usherwood]

Hmmm....
Interesting thought. I'll adjust it to add 1 before restoring the old value. But it's the variability which bothers me. And I wonder whether logging is impacting this.
And don't assume Richard P doesn't read these posts

[lotsaram]

Interesting thought. I'll adjust it to add 1 before restoring the old value.

Usually if I need to do something like this I increment or replace a cell value with RAND to ensure that there is an actual change. If you are resetting back to the old value then I would advise to do this in a subsequent process or at least change in Prolog, set back in Epilog. I have found in the past that if a value is changed but set back on the same tab then TM1 is "smart enough" to register that no change has taken place (and therefore not write any logs or invalidate any cached views.)

Out of interest how much memory is being used by views? I wouldn't have thought clearing down the cache would make that much difference unless you have set VMM to a really high value for the cube and there has been no data update for a long time (in which case the caching should be doing what it has been designed to do, improve response times, so why would you want to clear it?)

[belair22]

Back 5 years ago the cost of 64 bit servers was horribly expensive, hence tweaking every expanding TM1 models to work within small 32-bit server enviornments was likely to be more common that nowadays.

[David Usherwood]

Thanks for the prolog/epilog and RAND suggestions - I'll give them a go.
The point of all this is to clear calculations (views would help, but not much I agree). The aim is to manage server growth when exporting calculated values to a flat file (or files) to import into another server. The server is running around 50gig at present and we and the client are rather concerned about this! If we can manage the size of the calculation cache then we ought to be able to keep server growth down at the cost of a longer export time and more fiddling around to get the data into the other server.