DHIS2 Predictor

Support - Assistance technique
1

Hello out there :slight_smile:

While working on a LMIS project, I’m trying to use the predictor to generate an average monthly consumption value.

My generator is as follow:
sum(#{Monthly_consumption})*30.5/(sum([days])-#{Days_of_stock_out})

With Sample skip Test being:
isNull( #{Monthly_consumption} )

Period type is monthly and my Sequential sample count is set to 3

I noticed two strange things but I’m not sure I’m facing a bug…

1/ The documentation says that (sum([days]) “is the number of days in all sample periods”

What I observe is that (sum([days]) is actually the number of days in the reporting period multiplied by the sequential sample count…
For example, a value predicted for April 2024 should have from my understanding
sum(#{Monthly_consumption})*30.5/(31+29+31)-#{Days_of_stock_out})

(With (31+29+31) being #of days in January + #of days in February + #of days in March.)

Instead what I observe is that it is computed like follow:
sum(#{Monthly_consumption})*30.5/(3 *30)-#{Days_of_stock_out})

(With (3*30) being 3 times #of days in April.)

I can still “escape” that by changing my generator to sum(#{Monthly_consumption})*[days]/(sum([days])-#{Days_of_stock_out}) so it’s not so problematic.

2/ Although, if I don’t have three preceding periods with data, let’s say I only have data for January and February 2024, and a stable consumption of 10 and 0 days of stock out, then Average monthly consumption predicted for March 2024 will be 6.667.
I’d expect in this situation my AMC to be 10 as well with computation being:
(10+10)*31/(2 *31)-0

At this stage I don’t know if the computation is:

(0+10+10)*31/(3 *31)-0 == 6.667 OR (10+10)*31/(3 *31)-0 == 6.667

Where in the first iteration the engine picks up a “0” because it needs three periods whatsoever; while in the second it only considers the two valid periods but, (sum([days]) being “the number of days in the reporting period multiplied by the sequential sample count” instead of being “the number of days in all sample periods”, it turns out that my numerator doesn’t take into account that the number of periods to consider is only 2 rather than 3 (so 60ish days rather than 90ish days).

If that’s a bug, I’m happy to report on JIRA, if it’s a clarification needed in the documentation as well. But maybe all this is the expected behavior and/or I’m mislead by my non-native English biases :upside_down_face:

Let me know what’s your interpretation of all this and/or if you need extra information/clarifications,

Thanks a lot,

Thomas

2 Likes
2

Hi @Thomas_Warichet

It’s good that you have found some workarounds and ideas.

If you are using sum(days) isn’t going to be (2*31) rather than (3*31)?

3

Hi @Gassim,

If you are using sum(days) isn’t going to be (2*31) rather than (3*31)?

It isn’t, it’s actually dividing by (3* 31) and that’s my main issue. I wish it used (2 *31) and it is the behavior I’d expect but I think that there’s either a bug or that the documentation is misleading.

4

@Thomas_Warichet Thank you for the post.

Reading the backend code, [days] in the generator expression appears to return the number of days in the output period. As you say, what it should return is the number of days in all sample periods, excluding any skipped periods. I agree that this is what the documentation says.

Please make a Jira bug ticket for this. It can be fixed so that it agrees with the documentation.

(If [days] is used in evaluating the sample skip test, it refers to the number of days in the period being tested for skipping, as I believe it should.)

1 Like
5

Hello here :slight_smile:
I’m back from holidays and here’s the JIRA ticket

1 Like
6

Hi @Thomas_Warichet, I’m between holidays but I see the ticket. Thanks!