Problem on inter-cube feeders

[CHL]

Hi guys,

I have a big problem on feeders.
I have 2 cubes: destination cube and source cube.
The destination cube has 26 dimensions which are Date,Fund,Dimension 3.....Dimension 25 and Value Measure.
The source cube has 3 dimension which are Date, Fund and Date Measure.
As you can see there are 2 common dimensions: Date and Fund. Both measure dimensions have a element named 'Month Business Date Count'.

In case, I want to insert the value of 'Month Business Date Count' from the source cube to the same element as in the destination cube.

The rule in the destination is as follow:
Skipcheck;
['Month Business Date Count']=N:DB('Source Cube',!Date,!Fund,'Month Business Date Count');

The Feeders in the source cube is:
Feeders;
['Month Business Date Count']=>DB('Destination Cube',!Date,!Fund,'All Dimension 3'......'All Dimension 25','Month Business Date Count');

Unfortunately, it doesn't work. No values are retrieved.
Please help.

[lotsaram]

How big are your 23 dimensions that you have to feed to a top consolidation?

There is a limit to how many cells a single numeric cell can feed, in which case the feeders will fail silently (except for errors in the server log at load). This could well be your problem - check the server message log.

In any case this design is going to cause a massive amount of overfeeding which would result in very poor performance in the destination cube. I a rethink of design would be advisable! Either you need (significantly) more shared dimensionality in the source cube or you need to progressively feed to intermediate "feeder cubes" (which might have no purpose other than to feed the final destination cube) and take the hit in the intermediates with overfeeding but then via some lookup of valid intersections (which you can presumably do once you have appropriate dimensionality ...) you avoid overfeeding the final destination cube and recover acceptable calculation performance.

If that doesn't make sense maybe someone else will be able to put it in more understandable terms.

[David Usherwood]

I agree completely with Lotsa. I'll try to do what he suggests.
@CHL:
What's the business reason to push a value from a 26 dimension cube to a 3 dim cube? Are you summarising? If so what and why?
And...
Your rule will never deliver a value, since the dimensions you assign to the source cube in the DB() statement don't match that cube. It will compile fine though.

[tomok]

Is the problem "no values are retrieved" or is it "no CONSOLIDATED values are retrieved"? There's a huge difference. If no values are retrieved in the destination cube then it's not a feeder problem, your rule is not correct. Even if you don't feed correctly a properly written rule should result in values at least at the leaf level. Create a view that has only leafs and specifically leafs that you know will have data then recalc. If it does not show data then the rule is bad. If the data is there do a check feeders and see if the cell has been fed. If it isn't fed then you know you have a feeder problem.

I would echo what the other guys said, moving data from a 23 dimension cube to a 3 dimension cube via a rule is not good design. It's probably going to be quite slow since you have to calculate the top of the house for most of the dims and then do a feeder off them (again, not good design). A TI process would probably be a better design or better yet, just create a view in the source cube that provides the same data as in the 23 dimension cube and do away with the 3 dimension cube entirely. I've never ever seen a 23 dimension cube in practice in TM1. Sounds like it is probably a candidate for more thought as to the design.

[CHL]

Lotsaram:
The size of non-common dimensions of the destination cube is 8X3X4X2X2X16X7X2X7X3X2X2X3X7X6X3X3X5X3X5X2X3X2.
If there is a limit, then how much is it.
The source cube is a lookup cube. There are some calculations before pushing the value into the destination cube and therefore cannot get it from other places.

David:
My words meant I am going to push a value from a 3 dim cube to a 26 dimension cube.
If my words are poor that led you misunderstanding it. Sorry about that.

Tomok:
My problem is no consolidation values are retrieved. I think there is problem on the feeders
statement. Thank you for reminding.

[David Usherwood]

@CHL:
You haven't described the business need underlying what you are trying to do.
But in the reply to Lotsa, you said it's a lookup. Lookups (rates and so forth) don't need feeding.
I also see (apologies for missing this first time round) that your _rule_ is fine - it references all the dimensions in the cube it is accessing.
So, I don't think you need a feeder at all.

[CHL]

David:

I want to get the 'Month Business Date Count' from the lookup cube (source cube) and then use it to calculate the average values of each of the fund on specified date. Therefore both of the cubes have the same dimensions of date, fund and the measure dimension which have the same element named 'Month Business Date Count'.

In addition, the lookup cube is structured like this: Date as row, Measure as column, Fund as title. The value of 'Month Business Date Count' is the sum up of each day of the month which is treated as business date. I have more than 1000 elements (for 3 years) in Date dimension and 200 elements for Fund.

[tomok]

Why are you using the count of the number of business days in the month as a feeder? Surely every single month in the year has at least one business day in it. Why bother to use this consolidated value to feed if this is the case. I would just create a dummy element for each month, stick a value of 1 in it, and feed from that. It will be much faster and more efficient. More importantly, the number of days is just one part of the average value equation. What about the balance in the fund? Isn't the existence of a balance for a specific day the determining factor as to whether any data exists? Shouldn't you be feeding with this?