Feeders for Strings in Consolidated Levels

[rozef]

Or to not use SKIPCHECK instruction. FEEDSTRINGS dont seems to works correctly in some cases.

You still have to write feeders when you use that function

It must depends of how you use it. Personnally I didn't have to.

[mce]

What the OP needs to do is use the FEEDSTRINGS statement in the rule and then be sure to feed the cell that holds the string, even though it is a consolidated node in the hierarchy. As long as you write the feeder to be limited to only the element in measure dimenion that is specificed as "S" type, it should work.

Hi Tomok, as I mentioned above it works when I feed the target consolidated level string value. The problem is it feeds all the children in all dimensions. Hence causing too many feeders.

Just to clarify my original requirement:
- I have some numeric measures in a multidimensional cube having more than 10 sparce dimensions.
- and I have some string measures in a 3 dimensional smaller cube. These 3 dimensions are used also in the big numeric cube. These sting measures correspond to top level consolidations for the remaining more than 7 dimension of the big numeric cube.
- what I tried to do is that
-- add all string measures into the measure dimension of the big cube
-- and add rules to big cube and feeders to source cube to display those string measures in big cube, in slices where the string values correspond to
-- this means displaying them in consolidated levels in more than 7 dimensions of the big cube.
- what I tried above theoretically works but not practically due to the excessive amount of feeders
- what I had to do to is to get rid of the small 3 dimensional cube and load all string data directly into the big cube.
- the reason for originally trying to store string and numeric data in seperate cubes is that
-- string data will be incrementally updated very frequently, while numeric data will be incrementally updated less frequently
-- hence it would have been more efficient to keep them in seperate cubes for TI load performance and for save data all performance
-- and we would have benefitted more on TM1's cached calculated values for the numeric cube

Regards

[Gregor Koch]

Agree with lotsa and tomok on the consolidatechildren.

mce, do you actually need to use conslidated elements in Dim4 and the other dims which are not in the source cube?
If their only purpose is to show a string why use a consolidated element in the first place?
The way your example is they won't consolidate anything anyways.

[rozef]

If you dont need other levels, maybe a rule like
[]=S:IF( !dim4 @<> 'conselementindim4' , STET, CONTINUE);
or
[]=S:IF( !dim4 @<> 'conselementindim4' , '', CONTINUE);
will cut the overfeed.

[tomok]

-- hence it would have been more efficient to keep them in seperate cubes for TI load performance and for save data all performance

Only if you are clearing and reloading the cube from scratch every time you load.

-- and we would have benefitted more on TM1's cached calculated values for the numeric cube

???????? Having string values in a cube is not going to affect whether or not TM1 is going to cache the results of numeric calculations unless you have not set aside enough RAM to hold the cache.

[John Hammond]

mce Thanks for posting. Nice simple example which I built and found my knowledge wanting!

You don't need to feed consolidations when they are calculated whether they are Numeric or String consolidations.

Strings for the calculation purpose, no, but e.g. for the "appear in a zero suppressed view" purpose you need to feed strings and I thought this is the case.

You are right - I corrected my post to ensure it did not confuse anyone in future.

The obvious suggestion is to feed just one child of that consolidation instead of them all.

Already tried this but does not make the rule work consolidated element when zero suppressed.

This is unexpected. It should be enough for one child of a consolidation to be fed in order to see the consolidation in a zero-supressed view. There should be no need to feed all the children. I think I've had someone report to me a similar problem with version 9.5.1 (no fixpacks) and I would actually start considering this to be a bug.

**************** wrong see later ******

I built the example and you are correct that only one child needs to be fed, but that child also needs to be calculated in the Target cube. This applies to both string and numeric consolidations.

**************** wrong see later ******
Corrected:

I built the example and you are correct that only one child needs to be fed, but that child also needs to be calculated in the Target cube. This applies ONLY to numeric consolidations.

[mce]

mce, do you actually need to use conslidated elements in Dim4 and the other dims which are not in the source cube?
If their only purpose is to show a string why use a consolidated element in the first place?
The way your example is they won't consolidate anything anyways.

the string data is relevant for the top consolidations in those dimensions. Therefore I want to display them in top levels. They are not meaningfull for the leaf level elements. I could potentially add a leaf element in each of such dimensions that is allocated to store the string data, but I do not want to this as these dimensions are used in other places too and I do not want to disturb the current hierarchies in those dimensions by adding such a leaf element only for this cube.

[mce]

If you dont need other levels, maybe a rule like
[]=S:IF( !dim4 @<> 'conselementindim4' , STET, CONTINUE);
or
[]=S:IF( !dim4 @<> 'conselementindim4' , '', CONTINUE);
will cut the overfeed.

does this really cut the overfeeding? it will really be interesting if it does.

[mce]

-- hence it would have been more efficient to keep them in seperate cubes for TI load performance and for save data all performance

Only if you are clearing and reloading the cube from scratch every time you load.

I will be doing incremental updates to the cube. But the overall size of the cube effects the time it takes to insert data to the cube. small cubes take less time to insert than large cubes. I will do more inserts to the source cube here for string data.

-- and we would have benefitted more on TM1's cached calculated values for the numeric cube

???????? Having string values in a cube is not going to affect whether or not TM1 is going to cache the results of numeric calculations unless you have not set aside enough RAM to hold the cache.

Since inserting a data to a cube wipes out the cube cache for calculated values and for stargate views, I am guessing this is still the case if I am inserting sting data for a cube that also has numeric values. I do not want my frequent sting inserts to wipe out the cache for calculated numeric values and stargate views.

[mce]

(quote="qml" The obvious suggestion is to feed just one child of that consolidation instead of them all. /quote )

Already tried this but does not make the rule work consolidated element when zero suppressed.

This is unexpected. It should be enough for one child of a consolidation to be fed in order to see the consolidation in a zero-supressed view. There should be no need to feed all the children. I think I've had someone report to me a similar problem with version 9.5.1 (no fixpacks) and I would actually start considering this to be a bug.

I built the example and you are correct that only one child needs to be fed, but that child also needs to be calculated in the Target cube. This applies to both string and numeric consolidations.

This is interesting. I will try this approach. I will feed only one child from each dimension and will make sure there is a calulation for those fed leaf level cells. Then will see if this will make sure to get consolidated string cells fed properly.

[jstrygner]

I built the example and you are correct that only one child needs to be fed, but that child also needs to be calculated in the Target cube. This applies to both string and numeric consolidations.

John, is it possible you tested it on 9.0 version (that is shown under your name) only?

I did a retest (as in one of the previous posts in this thread I claimed I checked it on two versions and the result was, feeding just one child is not enough), and my retest still does not make consolidated string visible after zero suppression. See picture, tested on 9.5.1 HF17.

At the bottom of the picture I also decided to check how 'Check feeders...' will work in this case (on my version of course ).

[John Hammond]

Jstrynger

I copied your example in 9.0 and got the behaviour you describe. Previously my feeders had been external feeders but once I tested that again I found my mistake. ( I have corrected my previous post to avoid confusion for future readers)

When you are testing zero suppress you have to be very careful to limit the view to the consolidated elements you are testing only. If one cell gets filled in the grid TM1 will check along the rest of the line in the non zero suppressed way to produce the right answers.

I then tested feeding directly to the consolidated level. This worked. However as mce pointed out this works in the same way as numeric feeders in that feeding a consolidation is short hand notation for feeding all the children. Hence you have the potential to overfeed.

I thought then that the rule must be: "All N level children of a string consolidation must be fed for that string consolidation to be fed" so I fed each N level child explicitly without using the shorthand notation. This did not result in a feed to the string consolidation!

So my conclusion would be along your lines "A string consolidation must be explicitly fed by reference to that consolidation for that string consolidation to be fed at the risk of overfeeding. String consolidations cannot be fed by feeding their N level children. Even feeding ALL N level children explicitly will not result in the string consolidation being fed, despite it being shown as the equivalent feeder in the rules tracer when you trace feeders."

I would be interested to know if your conclusions are the same.

[jstrygner]

I thought then that the rule must be: "All N level children of a string consolidation must be fed for that string consolidation to be fed" so I fed each N level child explicitly without using the shorthand notation. This did not result in a feed to the string consolidation!

To be honest, I wouldn't even think of checking this, as I see no significant difference between one, some of or all children in this case.

I would be interested to know if your conclusions are the same.

But, as I always try, I checked the all children example, consolidation string was still not there after zero suppression and yes, my conclusions are the same .

[John Hammond]

Thanks JStrygner for taking the time to check.

It has been a useful exercise building actual models to investigate TM1 features. Interesting in that you find out about TM1 and also yourself. There is a tendency to want TM1 to work the way I think it should rather than the way it actually does. Clearly I have jumped to conclusions which have subsequently found to be false.

This is only natural given you have a job to do and time pressure. It goes to show how important peer review is so thank you everyone and mce for bringing the example to everyone's attention.

[mce]

Thanks John and everyone else who contributed to this post. It was really helpful. I did not have enough time this week to test all different suggestions, therefore it was very helpful for peers testing and sharing their findings.

I hope some people from Iboglix are watching these discussions, if not so far maybe later, so that they can make proper enhancements in TM1. Certainly it should not be necessary to feed all children to get consolidation fed properly for string measures.

[tomok]

I hope some people from Iboglix are watching these discussions, if not so far maybe later, so that they can make proper enhancements in TM1. Certainly it should not be necessary to feed all children to get consolidation fed properly for string measures.

The behavior makes perfect sense if you consider the fact that for string purposes, there is no such thing as a consolidation. As I stated in my previous post, when an element is configured to hold strings, any cell that includes that element is automatically considered a leaf. Therefore you have to feed that specific cell that holds the string because there are no "consolidations" for string cells. Everyone is missing the forest while focusing in on the trees.

[mce]

The behavior makes perfect sense if you consider the fact that for string purposes, there is no such thing as a consolidation. As I stated in my previous post, when an element is configured to hold strings, any cell that includes that element is automatically considered a leaf. Therefore you have to feed that specific cell that holds the string because there are no "consolidations" for string cells. Everyone is missing the forest while focusing in on the trees.

the problem with the current behaivour is not being in a position to feed the consolidation elements for string measures in this case, the problem is that feeding a consolidation element for a string measure automatically feeds also all the children of that consolidation element and hence causing completely unnecessary overfeeding, and in my example it makes it impossible as the memory for such feeders will be massive. the current behaivour makes it impossible for me to use feeders and rules for my purpose, I had to use TI processes to populate string data for such conolidated levels.

[tomok]

the problem is that feeding a consolidation element for a string measure automatically feeds also all the children of that consolidation element and hence causing completely unnecessary overfeeding

I don't believe that is necessarily correct. If you refine the feeder so that it targets only the element in the measure dimension that holds string values then it should only feed the specific cells covered in the feeder, not cascade down to children. If I get a chance in the next day or two I will test this to verify.

[mce]

the problem is that feeding a consolidation element for a string measure automatically feeds also all the children of that consolidation element and hence causing completely unnecessary overfeeding

I don't believe that is necessarily correct. If you refine the feeder so that it targets only the element in the measure dimension that holds string values then it should only feed the specific cells covered in the feeder, not cascade down to children. If I get a chance in the next day or two I will test this to verify.

we have already tested this. we certainly set the feeders to only feed the string measure and it feeds not only the consolidation level string cells but also all leaf level cells. feel free to test yourself off course.