Destruction priorities - another example of an unexpected sequence of events

Project:NAADSM
Version:4.0.6
Component:Code
Category:bug report
Priority:urgent
Assigned:Aaron Reeves
Status:fixed

9 Units, 3 production types.

 

Set number of days in destruction queue to highest priority, followed by production type (A>B>C) and then reason (cleaning > destruction).  Destruction campaign to be initiated after a 5 day delay.

 

Detection sequence:

 

Day

Event #

ID

Type

 

2

10

1

Type C

Clinical Detection

2

11

11

Type B

Clinical Detection

3

8

12

Type B

Clinical Detection

3

9

2

Type C

Clinical Detection

3

10

22

Type A

Clinical Detection

3

11

21

Type A

Clinical Detection

4

5

13

Type B

Clinical Detection

8

4

21

Type A

DfD Detection (Self-reporting)

9

4

1

Type C

DfD Detection (Destruction crew)

10

3

3

Type C

DfD Detection (Self-reporting)

10

4

22

Type A

DfD Detection (Destruction crew)

10

6

23

Type A

DfD Detection (Self-reporting)

12

2

2

Type C

DfD Detection (Destruction crew)

 

 

Destruction sequence (correctly starts on day 8):

 

Day

Event #

ID

Type

Event

Description

8

5

11

Type B

Destruction

Destruction

9

5

1

Type C

Destruction

Cleaning

10

5

22

Type A

Destruction

Cleaning

11

2

12

Type B

Destruction

Destruction

12

3

2

Type C

Destruction

Cleaning

13

2

13

Type B

Destruction

Destruction

14

2

21

Type A

Destruction

Cleaning

15

2

3

Type C

Destruction

Cleaning

16

2

23

Type A

Destruction

Cleaning

 

The output statistics shows the same results.

 

It seems that A21 should have been in line just after A22 and before B12, C2 (days holding are the same, but A is a higher priority production type than B or C). By that time A21 was already detected dead from disease (day 8), but since cleaning is set at a higher priority than detection, it shouldn’t have moved down the queue in my opinion.   

Also, C3 and A23 were detected on the same day, shouldn’t A23 being of a higher priority production type, have been destroyed before C3? 

Description
AttachmentSize
DfD_7.mdb1.14 MB

Comments

#1

I know Tim already posted a similar issue, but I thought another example might help to solve the problem.

#2

Priority:not yet set» urgent

I added some code that outputs the destruction priorities to the XML parameter export file. Below is that listing and the priorities for the basic destruction and dcd models. The NA just means that Marna was not using tracing or ring destruction in her scenario. I believe that the priority order output in the XML are correct.
XML file attached.

Note: Opening "<" replaced by "/" below.

Contents of Global Controls Destruction Priority list:

/!-- Destruction Priorities (not sorted) -->
/!-- Type A+basic priority: 2 -->
/!-- Type A+dead-from-disease priority: 1 -->
NA /!-- Type A+direct-back priority: 6 -->
NA /!-- Type A+direct-forward priority: 3 -->
NA /!-- Type A+indirect-back priority: 7 -->
NA /!-- Type A+indirect-forward priority: 4 -->
NA /!-- Type A+ring priority: 5 -->
/!-- Type B+basic priority: 9 -->
/!-- Type B+dead-from-disease priority: 8 -->
NA /!-- Type B+direct-back priority: 13 -->
NA /!-- Type B+direct-forward priority: 10 -->
NA /!-- Type B+indirect-back priority: 14 -->
NA /!-- Type B+indirect-forward priority: 11 -->
NA /!-- Type B+ring priority: 12 -->
/!-- Type C+basic priority: 16 -->
/!-- Type C+dead-from-disease priority: 15 -->
NA /!-- Type C+direct-back priority: 20 -->
NA /!-- Type C+direct-forward priority: 17 -->
NA /!-- Type C+indirect-back priority: 21 -->
NA /!-- Type C+indirect-forward priority: 18 -->
NA /!-- Type C+ring priority: 19 -->

Models:

/destruction-priority-order>
time waiting,production type,reason
//destruction-priority-order>

/basic-dcd-model production-type="Type A">
/priority>1 //basic-dcd-model>

/basic-dcd-model production-type="Type B">
/priority>8 //basic-dcd-model>

/basic-dcd-model production-type="Type C">
/priority>15 //basic-dcd-model>

/basic-destruction-model production-type="Type A" production-type-id="5">
/priority>2
//basic-destruction-model>

/basic-destruction-model production-type="Type B" production-type-id="6">
/priority>9
//basic-destruction-model>

/basic-destruction-model production-type="Type C" production-type-id="9">
/priority>16
//basic-destruction-model>

AttachmentSize
XMLParamsExport_Issue2474ParamsExport_Take2.xml 32.46 KB

#3

Checking whether the fix for issue #2463 takes care of this test case, too.

#4

Status:active» needs review

#5

It's great that Marna chose time waiting as the main priority in this test, because it has brought up a situation I had not thought about.

What if:
Herd A gets detected as diseased on day 3.
Herd A gets detected as dead on day 8.

Does herd A keep its old place in the queue (day 3 = older request = higher priority) because it has actually been waiting for a destruction team since day 3?

Or does herd A get a new spot in the queue (day 8 = newer request = lower priority) for the cleanup-only task?

In the past, a new request could not cancel an existing request of higher priority. For example:

  • I am already in queue for a high-priority reason (I was detected as diseased). I get slated for destruction for a lower-priority reason (I am in a ring). I keep my old, higher-priority place in queue.
  • I am already in queue for a low-priority reason (I was in a ring). I get slated for destruction for a higher-priority reason (I am detected as diseased). My old place in queue is discarded and I get a new, higher-priority place in queue.

Without really meaning to, I created an exception to that rule for death from disease, because I was cancelling the old request for destruction upon detection of death by disease. I never thought to keep the old request.

So what do you think...

Herd A gets detected as diseased on day 3.
Herd A gets detected as dead on day 8.
Does herd A keep its old place in the queue (day 3 = older request = higher priority) because it has actually been waiting for a destruction team since day 3?
Or does herd A get a new spot in the queue (day 8 = newer request = lower priority) for the cleanup-only task?

#6

I just ran this simulation in 4.0.7. The csv file output is attached.

I traced through what happens day-by-day. In our email discussion, we concluded that a herd that is detected as dead loses its old spot in the queue, and gets a new spot in the queue for the cleanup-only task (see comment #5 above). Keeping this in mind, the sequence below looks correct to me...

By the end of day 4, waiting:
1st = 11, 1, 21-22, 12, 2, 13
(m-n indicates tie)

On day 8, destruction team goes to unit 11 (correct).
21 is detected as dead.
21 loses its old place in line, enters queue at end (time priority)
By the end of day 8, waiting:
1st = 1, 22, 12, 2, 13, 21

On day 9, destruction team goes to unit 1 (correct).
Team discovers unit 1 has died, does cleanup.
By the end of day 9, waiting:
1st = 22, 12, 2, 13, 21

On day 10, destruction team goes to unit 22 (correct).
Meanwhile, farmer discovers unit 22 has died.
Team discovers unit 22 has died, does cleanup.
2 and 23 are detected as dead.
2 loses its old place in line, enters queue at end (time priority)
23 enters queue, but is just ahead of 2 (prodtype A > C)
By the end of day 10, waiting:
1st = 12, 13, 21, 23, 2

On day 11, destruction team goes to unit 12 (correct).
3 is detected as dead (farmer self-reporting), enters queue at end.
By the end of day 11, waiting:
1st = 13, 21, 23, 2, 3

On day 12, destruction team goes to unit 13 (correct).
By the end of day 12, waiting:
1st = 21, 23, 2, 3

On day 13, destruction team goes to unit 21 (correct).
By the end of day 13, waiting:
1st = 23, 2, 3

On day 14, destruction team goes to unit 23 (correct).
By the end of day 14, waiting:
1st = 2, 3

On day 15, destruction team goes to unit 2 (correct).
By the end of day 15, waiting:
1st = 3

On day 16, destruction team goes to unit 3 (correct).
By the end of day 16, waiting: [none]

Looks right!

AttachmentSize
issue_2474_run_407_20110922.csv 1.13 KB

#7

Status:needs review» active

Neil,
Thanks for the elaborate explanation! I know it used a lot of your valuable time, but now it is crystal clear to me what is meant with a unit losing its place in the queue and re-entering. I guess I initially was of the opinion that a unit should stay in the queue after being detected dead, but thinking about it again, a living unit, breathing virus into the air, should have a higher priority than a dead one, which is (as far as I understand) still under quarantine and thus low risk.
I agree that the destruction priorities work like it should.

#8

Status:active» fixed

#9

Assigned to:guest» Neil Harvey
Status:fixed» active

Per conference call discussion on September 22, when "time waiting" is the highest priority, time waiting should always be calculated from the day of the original queuing event. If a unit is removed from a queue and added again for a different reason, the the day of the first event should be used to determine priority.

Currently, the model operates as Neil described above. Since a change in model behavior is still needed, this issue is still active.

#10

Assigned to:Neil Harvey» Aaron Reeves

A tentative fix is in place for NAADSM 4.0.9 (see function EVT_new_request_for_destruction_event in event.c). Review is needed.

The test suite will also need to be run to ensure that nothing was inadvertently broken. This can be done as soon as issue 2539 is taken care of.

#11

Status:active» needs review

#12

I don't think the destruction priorities are working yet in 4.0.9, but the output statistics regarding dead from disease and destruction produced the correct results.

To me, it looks like Unit 22 should have been destroyed on day 11 and it was not (see event sequence below). I used Marna's DFD_7 scenario and version 4.0.9. The attached file is the Events table from which I made the observations listed below.

Priority:
1. number of days in destruction queue
2. production type (A>B>C)
3. reason (cleaning > destruction).

List symbology:
Ties: m-n.
X: detected dead / dead from disease.
D: Destroyed.
(n): days in queue.
*: Priority issue described.

Day: UnitID (days in queue)
2: 11 , 1
3: 11 (1) ,1 (1), 21-22, 12, 2
4: 11 (2) ,1 (2), 21-22 (1), 12 (1), 2 (1), 13
8: 11D (6) ,1 (6), 21X-22 (5), 12 (5), 2 (5), 13 (4)
8: 1 (6), 21X-22 (5), 12 (5), 2 (5), 13 (4)
9: 1DX (7), 21X-22 (6), 12 (6), 2 (6), 13 (5)
9: 21X-22 (6), 12 (6), 2 (6), 13 (5)
10: 21XD-22X (7), 12 (7), 2X (7), 13 (6), 23X
10: 22X (7), 12 (7), 2X (7), 13 (6), 23X

11: 22X (8), 12D (8), 2X (8), 13 (7), 23X (1), 3X
* #22 should have been destroyed not #12
* because tie days holding and #22 is Prod Type A
* whereas #12 is Prod Type B.
11: 22X (8), 2X (8), 13 (7), 23X (1), 3X

12: 22X (9), 2XD (9), 13 (8), 23X (2), 3X (1)
* #22 should have been destroyed rather than
* #2 because tie days holding and #22 is Prod Type A
* whereas #2 is Prod Type C.
12: 22X (9), 13 (8), 23X (2), 3X (1)

13: 22X (10), 13D (9), 23X (3), 3X (2)
* #22 passed by again, but has longest time in queue
* and is prod type A, whereas #13 is prod type B.
13: 22X (10), 23X (3), 3X (2)

14: 22X (11), 23XD (4), 3X (3)
* #22 passed by again, but has longest time in queue.
14: 22X (11), 3X (3)

15: 22XD (12), 3X (4)
15: 3XD (5)

Output Statistics Check:
detcUClin = 7, true
detcUDead = 5, true
detcUDeadD = 1, true
detcUDeadV = 0, true
detcUAll = 9, true (see below)
Clin Signs: 1,2,11,12,13,21,22
DFD Self Rpt: 2, 21,22, 3,23
DFD DestCrew: 1
detcUDeadAll = 2, true using new definition (#3,23)
descUDet = 3, true (#11,12,13)
descUDcd = 6, true (#1,2,3,21,22,23)
descUDcdInDestrQueue = 4, true (#21,1,22,2) not #23
DescUAll = 9, true
deswUMax = 7, true
deswUMaxDay = 4, true
deswUTimeMax = 12, true (#22)

AttachmentSize
OutputEventsTableValues.csv 2.79 KB

#13

Status:needs review» active

#14

Status:active» fixed

Ric's comment (see #12 above) was correct. When destruction events were being moved from the "destroy due to detection of clinical signs" queue to the "destroy due to detection of death from disease" queue, the time waiting was not being properly preserved. A fix has been committed, which will be released in NAADSM 4.0.12.