TM1 Forum

Hi All,

I need some help please...

In our model we have 3 cubes; Cube B feeds into Cube C and the rule in Cube C is based on matching the Month and Year from Cube A.

This is the rule in Cube C (which has 15 dimensions);

[{ 'Scenario 1', 'Scenario 2', 'Working Weekly', 'Weekly Adjustment'}, '40710'] = N:
IF(!Year @= DB('Cube A',!Version,!Service,!Direction,!Schedule,'Year') & !Month @= DB('Cube A',!Version,!Service,!Direction,!Schedule,'Month') & !Year Reporting @= DB('Cube A',!Version,!Service,!Direction,!Schedule,'Year') & !Month Reporting @= DB('Cube A',!Version,!Service,!Direction,!Schedule,'Month'),
DB('Cube B',!Version,!Service,!Direction,'All Customers',!Schedule,!Commodity Short,!Origin,!POL,!POD,!Destination,!Cargo Type, 'Breakbulk Freight') ,
0);

The Feeder in Cube B (which has 12 dimensions) is;

[{ 'Scenario 1', 'Scenario 2', 'Working Weekly', 'Weekly Adjustment'},'All Customers','Breakbulk Freight']
=>DB('Cube C',!Version, DB('Cube A',!Version,!Service,!Direction,!Schedule,'Month'), DB('Cube A',!Version,!Service,!Direction,!Schedule,'Year'),
!Service,!Direction, DB('Cube A',!Version,!Service,!Direction,!Schedule,'Month'), DB('Cube A',!Version,!Service,!Direction,!Schedule,'Year'),
ATTRS('Cargo Type by Ownership',!Cargo Type by Ownership,'Cargo Type'),ELPAR('Commodity',!Commodity,1),!Origin,!POL,!POD,!Destination,!Schedule,'40710');

So the rule is fed and it works.

BUT, if the value for Month or Year is changed in Cube A, the appropriate cell in Cube C calculates correctly but is Unfed.

I've tried putting feeders in Cube A but it only has 5 dimensions (4 in common with cube C) and trying to feed all the other dimensions results in excessive memory usage and a Server crash.

Any insight would be greatly appreciated.

Thankyou,

Gregory

Hi Gregory,

Under the Assumption that Cube C is called 'Month P&L'...and Cube A is not called 'Voyage Profile'.

One thing I can see right away is that your Feeder does not use the same month and year 'condition' as your rule.
By that I mean that your Feeder might still be feeding the month stored in DB('Voyage Profile',!Version,!Service,!Direction,!Schedule,'Month') and not the month which is stored in Cube A.

But even if they are the same (and Cube A is 'Voyage Profile') your Feeder won't refire unless 'Breakbulk Freight' changes from a Zero to a value.

Does it feed properly when you resave the rule for Cube B?

Cheers

Hi Gregory,
One crucial thing to understand about feeders is that they are not dynamic in the same way that rules are. They only refire under certain conditions. Rules will correctly take into account changes in the voyage parameters but the feeders won't recognise this until they are fired again.
Generally feeders are only fired under the following conditions.

When the rules are compiled, this can be triggers by saving the rule sheet, or calling a TI that re-compiles the feeders.
When a value is entered into a cube, this can be achieved by unloading and reloading a cube, restarting the server, or entering a value.

To get your feeder to work as written you might find this cfg parameter helps.

Reevaluate Conditional
Feeders Optional In some instances, when a cell is fed based on a condition being either true or false, a change in the condition value does not trigger the feeder. For example, suppose your rule has the following feeder structure:
• Cell A feeds cell B.
• “Cell B feeds cell C when condition D is true (this is a conditional feeder).
Assuming condition D is false, a change in the value of cell A triggers the feeding of cell B, but the feeding of cell B does not trigger the feeding of cell C. At this point, condition D is false, and cell C is fed only when the condition is true.
If condition D subsequently becomes true but the value of cell A does not change, cell C remains unfed. This can lead to inconsistencies in data.
If you add the line ReevaluateConditionalFeeders=T to Tm1s.cfg, any changes to cell values referenced by conditional feeders will force the feeder to be re-evaluated.
In the above example, any change to a cell value that causes condition D to become true would force a re-evaluation of the conditional feeder, resulting in cell B feeding cell C. Other changes to the cube, such as changes to attributes, do not force the feeder to be re-evaluated. Only cell value changes trigger the re-evaluation.

Make sure you test well though since it will (I think) force a recompile of your rule sheet with every change to the parameters cube which would hit performance.

Another option is to set up a TI that users can call that re-compiles the rule sheet. If you have good business processes you can ensure that this is called after changes to the parameter cube are complete.

HTH
Cheers

Watch out for that ReevaluateConditionalFeeders=T parameter. I've seen it cause major problems when restarting your server (version 9.4). On that note, I've also spoken with the guys in TM1Engineering, and they believe that the parameter is incorrectly defined in the documentation. I've been told that it is actually only used by TM1 on server startup, and causes the server to loop through all of your feeders a second time to "reevaluate" any conditions that may have changed after all of your cubes are loaded. This would come pretty close to doubling your startup time. Each time a feeder is *fired*, it should correctly reevaluate the condition, regardless of this configuration file setting.

The real key to your problem is that feeders sourced from a numeric cell are only fired when changing a value from 0 to a non zero number. So if you've entered a value of 1 to represent the month ofJanuary and a value of 2010 to represent the year, the feeders will execute the first time you input this data, and all will be well. Changing the 1 to a 2 or 2010 to 2011 will NOT cause the *new* feeder to fire, and as you're seeing, the rule will work correctly, but the feeder will not.

HOWEVER, if you changed the month and year elements to which you're inputting values to STRING cells, your feeder will move appropriately. Unlike feeders sourced by numeric cells, a when a feeder is sourced by a STRING, it fires everytime the string changes.

Hopefully changing those cells to strings won't be to earth shattering for your application!

Watch out for that ReevaluateConditionalFeeders=T parameter. I've seen it cause major problems when restarting your server (version 9.4). On that note, I've also spoken with the guys in TM1Engineering, and they believe that the parameter is incorrectly defined in the documentation. I've been told that it is actually only used by TM1 on server startup, and causes the server to loop through all of your feeders a second time to "reevaluate" any conditions that may have changed after all of your cubes are loaded.

Interesting that belief has to come into it for the TM1 Engineering team! I'm 99% sure that in prior releases the parameter worked as documented, so it seems likely that it was broken in the current release and now they are saying the documentation is wrong!

[{ 'Scenario 1', 'Scenario 2', 'Working Weekly', 'Weekly Adjustment'},'All Customers','Breakbulk Freight']
=>DB('Cube C',!Version, DB('Cube A',!Version,!Service,!Direction,!Schedule,'Month'), DB('Cube A',!Version,!Service,!Direction,!Schedule,'Year'),
!Service,!Direction, DB('Cube A',!Version,!Service,!Direction,!Schedule,'Month'), DB('Cube A',!Version,!Service,!Direction,!Schedule,'Year'),
ATTRS('Cargo Type by Ownership',!Cargo Type by Ownership,'Cargo Type'),ELPAR('Commodity',!Commodity,1),!Origin,!POL,!POD,!Destination,!Schedule,'40710');

Re your comments about string cells and getting the feeders to fire.
I believe that the only time a feeder will get triggered is if an action happens on the area in the left hand side of the feeder. Changing the value at (for example), DB('Cube A',!Version,!Service,!Direction,!Schedule,'Year') will not result in the trigger refiring irrespective of if the value is a string or a number. My understanding is that when the rule sheet is compiled any internal DB references in the RHS are evaluated and hard coded in the feeder.

I could be wrong but I don't believe so...
Cheers

I believe that the only time a feeder will get triggered is if an action happens on the area in the left hand side of the feeder.

Absolutely correct! When I used the term "sourced" I was referring to the left side of the feeder statement.

As I said before,

feeders sourced from a numeric cell are only fired when changing a value from 0 to a non zero number

and

when a feeder is sourced by a STRING, it fires every time the string changes

BUT, I did not take into consideration the DB on the right hand side. I also think you're correct in saying the DB on the right side of the feeder statement does NOT get reevaluated (until feeders are reprocessed), resulting in the unfed cells. It would save me (and probably many others) from a great deal of agony if they did!

Thankyou Gregor, Steve & Kielmc for your considered advice. I've responded to each of you below;

Gregor Koch wrote: Under the Assumption that Cube C is called 'Month P&L'...and Cube A is not called 'Voyage Profile'.

Sorry Gregor et al, I omitted to change the Cube Names in the Feeder - have now done this. Cube A is Voyage Profile.

Gregor Koch wrote: But even if they are the same (and Cube A is 'Voyage Profile') your Feeder won't refire unless 'Breakbulk Freight' changes from a Zero to a value.

The problem is not with changes to Cube B - changes in 'Breakbulk Freight' correctly update Cube C. I'm not sure what you mean by re-fire - when I change the (non-zero) value in Cube B (it is actually rule derived), Cube C updates correctly & is fed.

Gregor Koch wrote: Does it feed properly when you resave the rule for Cube B?

Yes it does, but only for the values in Cube A at the time the rule is saved. Changing Month & Year in Cube A to different values result in Cube C not being fed.

Steve,

ReevaluateConditionalFeeders looks both promising and risky. I'll test it out on our Test model today.
Your suggestion to use aTI is a good one - I may well use it if I can't get feeders to work.

Kielmc,

Thanks for the warning, I will try it out as above.

kielmc wrote: The real key to your problem is that feeders sourced from a numeric cell are only fired when changing a value from 0 to a non zero number. So if you've entered a value of 1 to represent the month ofJanuary and a value of 2010 to represent the year, the feeders will execute the first time you input this data, and all will be well. Changing the 1 to a 2 or 2010 to 2011 will NOT cause the *new* feeder to fire, and as you're seeing, the rule will work correctly, but the feeder will not.

As noted above in my response to Gregor, the values that are being changed are the values in Cube A not Cube B. My understanding is that a change from one non-zero value to another non-zero also works correctly in terms of being fed.

kielmc wrote: HOWEVER, if you changed the month and year elements to which you're inputting values to STRING cells, your feeder will move appropriately. Unlike feeders sourced by numeric cells, a when a feeder is sourced by a STRING, it fires everytime the string changes.

The elements in Cube A are string elements, but as there are no feeders from Cube A to Cube C, the cells in Cube C are unfed.

cheers,

Gregory

Hi Gregory,

I don't think that ReevaluateConditionalFeeders will help you here. If it does, I would be happy to stand corrected if you tell me how you got it to work. If you do want to give it a try and you are using 9.4 (from you tag) note that you cannot (should not) use Multithreaded start up if you turn it on.
@kielmc: I am really curious who told you that the ReevaluateConditionalFeeders is only used on start up

Never forget the option of feeding from within cube C which I think I tried to explain to you on your last Feeder thread!

Cheers

Hi Gregor,

I don't think it will work either as the Feeders for Cube C are not conditional. The only hope is that somehow the implementation of the function works to resolve dependencies.

Gregor Koch wrote: Never forget the option of feeding from within cube C which I think I tried to explain to you on your last Feeder thread!

and which I use very successfully, thankyou.
The problem is the cells are already fed correctly (as per my original description of the problem) until you change a month and/or year in Cube A, so what else could I feed from?

cheers,

Gregory

I've tried the ReevaluateConditionalFeeders = T & it didn't make any difference.

Any other ideas?

Cheers,

Gregory

Hi GPC,
I can think of two options both involving a TI which would have to be run after you finish updating the parameters.

1. Simple TI with CubeProcessFeeders(CubeName); in it. This should work but is likely to be slow depending what other feeders are in the rule sheet.
2. Not sure about this approach. If it was possible to closely identify the section of the cube affected by the change in feeders you could a)Export the values, b) ViewZeroOut that space c)Reimport the values. This should be faster than 1, but obviously more of a challenge programatically.

EDIT - I did think of another way that may work if you have cfg parameter in (and it works as described). You could make your feeder conditional on a something that is always true.

[{ 'Scenario 1', 'Scenario 2', 'Working Weekly', 'Weekly Adjustment'},'All Customers','Breakbulk Freight']
=>DB(If ( DB ('FireFeeder','Value','String')@='True','Cube C','') !Version, DB('Cube A',!Version,!Service,!Direction,!Schedule,'Month'), DB('Cube A',!Version,!Service,!Direction,!Schedule,'Year'),
!Service,!Direction, DB('Cube A',!Version,!Service,!Direction,!Schedule,'Month'), DB('Cube A',!Version,!Service,!Direction,!Schedule,'Year'),
ATTRS('Cargo Type by Ownership',!Cargo Type by Ownership,'Cargo Type'),ELPAR('Commodity',!Commodity,1),!Origin,!POL,!POD,!Destination,!Schedule,'40710');

Then once you finish updating the parameters, change the value at DB ('FireFeeder','Value','String') from True to false and then back to True again. This should fire the feeder (if the cfg does what it says on the tin)??

HTH

(I'm going to test ReevaluateConditionalFeeders in 9.0 when I get the time since I still think it should work. I'd argue that your feeder is conditional even though it's not of the exact form listed. A conventional conditional feeder of the form []=>DB ( If ( DB()@='String', 'CubeName', ''), !DimRefs); is not that different to one of []=>DB ( CubeName ,!DmRefs, DB (), !DimRefs); In both cases its the DB to the other cube that's the issue....)

Cheers

Any more information on this?

I have the exact same problem. I have a cube that is used to store attribute data so that end users could change the mappings. I then use these mappings to split data into a 3rd cube. When users change a mapping in Cube B the feeders from Cube A to Cube C are not re-fired.

Would feeding anything from Cube B to Cube C force a refire? For instance can I feed once cell in Cube C from B and anytime a user changes something in Cube B the feeder is re fired?

Thanks

Numeric leaf cells which are the source for feeders will trigger the feeder to fire on a change in value from null to any value. However once the feeder has been fired it will not re-fire on subsequent value changes for the duration of the server session. (Unless you explicitly save the rule file or execute a process feeders command with TI, both of which could be time consuming as all cells will be evaluated).

If you use a string cell rather than a numeric cell as the starting point or source of the feeder then the feeder will fire for every value change of the cell. You will also need to use the FEEDSTRINGS command and also remember that the regions of the cube that were fed with the former condition will still remain fed in addition to any new regions fed after the change in source conditions.