Vaccination Rings of different sizes depending on Production Type

[josiahseaman]

https://github.com/NAVADMC/ADSM/wiki/RFC-20130107:-New-Vaccination-Ring-Creation-Options

The modeler can say: “Within a vaccination ring, vaccinate the following production types: dairy, beef, etc.” But notice what the modeler cannot say: “When a cattle unit is detected as diseased, vaccinate dairy cattle within 10 km and sow operations within 25 km.”

• [x] Ring has inner radius, outer radius
• [x] Ring has list of target Production Types

Vaccination questions:

• "Why do I start vaccination?" - Defined in Global Triggers
• "Who do I include?" - retrospective, rings
• "How many can I do?" - Global capacity
• "In what order?" - vx priorities = prodtype, order, age
• "When do I stop" - only one stop trigger

  Tasks

• [x] Agreement on data model modifications
• [x] Migration
• [x] xml2sqlite
• [x] User interface
• [ ] C code
• [x] C code automated tests
• [x] Validation: vaccination fields in ControlProtocol are not null when PT is targeted by Rings

[josiahseaman]

@missyschoenbaum There wasn't previously an issue for this but I noticed the RFC and it looked like it belonged in V3.3. If this is a feature that can be delayed, please move it to a later milestone.

[missyschoenbaum]

@ndh2 has this as priority 5 in his list, and groups it with vaccination priorities. It was functionality that C code was completed for in the 2013 DSCXN, so it has work done on it and was tested.

[missyschoenbaum]

I have screen shots of how this looked if those would be helpful to the documentation.

[josiahseaman]

That would definitely be helpful. The RFC doesn't have screenshots.

[ndh2]

Here's that screenshot. The dialog allowed you to define any number of ring-creation rules, and it was formatted to spell out the rule you were creating in a plain-English sentence.

[ndh2]

The RFC has a discussion of this feature, but it needs to say exactly what text is added, changed, and/or deleted from the model spec. I'll fill that in.

[josiahseaman]

@tjmahlin I want to call your attention to this issue. Most likely, this is going to go in the Control Protocol section, not the Zones section (where there is lots of room). I think we may want to consider splitting the Control Protocol tabs into their own models and breaking that whole section down one more layer so Control Protocol "has a" Vaccination Strategy. Which is it's own discrete unit. This opens up the option of creating new Protocols as a mashup of components. The downside is that the 3 Panel thing doesn't work in our favor, since this would be 4 levels deep.

Something to ponder.

[tjmahlin]

I actually started working on an interaction design for control protocols using the 3-column layout quite some time ago (mid January), but a long series of other topics took priority, and the spec was not completed. I think we can accommodate the creation of rings with this model and using the population panel without going beyond a need for 3 columns

@josiahseaman does this look like it could address all of the required functionality?

[ndh2]

The old data model:

Right now we put everything about vaccination into a controlprotocol attached to a productiontype. The trigger_vaccination_ring and vaccination_ring_radius specify what happens when a specific unit is detected: does it trigger a ring, and if so, how large? The other 4 fields use_vaccination, vaccination_priority, vaccinate_detected_units, and minimum_time_between_vaccinations specify what happens to the units that are inside the ring that has been triggered.\

The new data model:

We could make a new table where each row corresponds to one of the rules as illustrated above: it would have a productiongroup that triggers, a productiongroup that gets vaccinated, an inner radius (float type, allowed to be null), and an outer radius (float type, not null).

@josiahseaman thoughts on your preferred data layout?

[josiahseaman]

This sounds more in line with the way we did Vaccination Triggers than Control Protocol. I wouldn't suggest using the "ProductionGroup" object. I already have a data type for "list of Production Types" which is a many to many field. The difference is that you are required to name a group, but you can assign ProductionTypes to an anonymous ProductionList. I was planning on adding a convenience that added all production types when you click on a group.

We could just add a new area where you can create rules like "If there's a Detection in list A then find all list B within radius O-I and vaccinate them". People could create as many of these rules as they wanted. This is faster than listing off each rule as a source-destination pair, but I still wonder about how easy it is to see what you've done.

We have the same problem in Disease Spread pairs, and I'd like to have a square matrix that shows what effects what. I think I'll at least setup the database fields with reverse relations so that we can easily display information about a particular ProductionType's interactions... Every ProductionType has a rather empty page at the moment. I think a list of interactions that PT is part of would be useful, but that'll be it's own feature.

[ndh2]

Yes, the data here is a lot like the triggers, isn't it? Do you have all you need to make a migration then?

[ndh2]

Here's my list of what would disappear from controlprotocol:

• trigger_vaccination_ring, vaccination_ring_radius, and use_vaccination would be deleted, but get turned into equivalent settings in the new table(s)
• vaccination_priority, vaccinate_detected_units, and minimum_time_between_vaccinations would stay.

[josiahseaman]

If it's alright with you I can start on this right away.

[ndh2]

Definitely alright with me!

[josiahseaman]

There's maybe a bit more to discuss. Here's the current Protocol Vaccination section:

    use_vaccination = models.BooleanField(default=False,
        help_text='Indicates if units of this ' + wiki("production type") + ' will be subject to vaccination.', )
    vaccinate_detected_units = models.BooleanField(default=False,
        help_text='Indicates if detection in units of this ' + wiki("production type") + ' will trigger vaccination.', )
    days_to_immunity = models.PositiveIntegerField(blank=True, null=True,
        help_text='The number of days required for the onset of ' + wiki("vaccine immunity", "vaccine-immune") + ' in a newly vaccinated unit of this type.', )
    minimum_time_between_vaccinations = models.PositiveIntegerField(blank=True, null=True,
        help_text='The minimum time in days between vaccination for units of this ' + wiki("production type") + '.', )
    vaccine_immune_period = models.ForeignKey(ProbabilityFunction, related_name='+', blank=True, null=True,
        help_text='Defines the '+ wiki("vaccine immune") + ' period for units of this ' + wiki("production type") + '.', )
    trigger_vaccination_ring = models.BooleanField(default=False,
        help_text='Indicates if detection of a unit of this type will trigger a vaccination ring.', )
    vaccination_ring_radius = FloatField(validators=[MinValueValidator(0.0)], blank=True, null=True,
        help_text='Radius in kilometers of the vaccination ring.', )
    vaccination_priority = models.PositiveIntegerField(default=5, blank=True, null=True,
        help_text='The vaccination priority of this production type relative to other production types.  A lower number indicates a higher priority.', )
    vaccination_demand_threshold = models.PositiveIntegerField(blank=True, null=True,
        help_text='The number of animals of this type that can be vaccinated before the cost of vaccination increases.', )
    cost_of_vaccination_additional_per_animal = MoneyField(default=0.0,
        help_text='The additional cost of vaccination for each vaccinated animal of this type after the threshold is exceeded.', )

It may be that vaccinate_detected_units should be deleted since this will be determined by whether or not the PT is targetted by a vaccination rule. If this does not act as a trigger then I think the help text should be changed to something like "Should this Unit be Vaccinated if an infection is detected in that Unit?"

Second, if we remove use_vaccination there's a bit of a validation problem. The remaining fields are not required if use_vaccination is not checked. New Vaccination Rings will instruct the simulation to try vaccinating a particular ProductionType. However, it's not garunteed that ProductionType even has a ControlProtocol at all. And even if it does, days_to_immunity, vaccine_immune_period and vaccination_priority may not be defined. Is this a problem for you? If we leave use_vaccination in it would need to be treated as an override for Vaccination Ring targetting if vaccination is turned off, since the required fields may not be there.

[ndh2]

The meaning of vaccinate_detected_units is, "If this unit is already known to be diseased, do we still vaccinate it?" That switch is there because vaccination can have a suppressive effect (make an infected individual produce less virus) as well as a protective effect.

When we defined these features before, everybody seemed OK with that remaining as a per-production-type switch, so I'd say we should leave it there.

[ndh2]

As for leaving in use_vaccination as an override, I personally would not want that there because it means people have to remember to change settings in 2 places. Perhaps checking whether days_to_immunity etc. are defined for types that are vaccinated can be done in the scenario-level validation checks.

[josiahseaman]

Thanks. I've added another checkbox for that Validation. I'm going to estimate this my part of this as a 13. Could you estimate and add the sum to this issue?

[ndh2]

Just thinking about this wording: "Should this Unit be Vaccinated if an infection is detected in that Unit?" I think that makes it sound too much like cause-and-effect: infection was detected, therefore we vaccinate.

What vaccinate_detected_units is getting at is more like, "If a unit of this type is slated to be vaccinated, but the unit is known to be infected, should the unit still be vaccinated for the suppressive effect?" Awkward sentence, I know, maybe someone else can take another crack at rewording it.

[josiahseaman]

Your sentence is already a big improvement. The current sentence doesn't make it clear this is a negative filter, rather than a trigger.

[josiahseaman]

Do you want the model to be called VaccinationRing or VaccinationRingRule? Or VaccinationTriggerRule?

[ndh2]

VaccinationRingRule sounds good. Definitely nothing with the word "trigger" since that word is already used for the conditions that cause a vaccination program to be initiated.

[josiahseaman]

[josiahseaman]

@ndh2 Can you take a shot at some help_text for outer_radius and inner_radius? trigger_group and target_group` as well if you like.

[josiahseaman]

@ndh2 Would you double check my validator list?

Defaults:

• Vaccinate detected units defaults to false and so doesn't strictly require user interaction. Though the user must have seen this screen if the other fields are set.
• Vaccination priority defaults to 5, so it's never blank

if pt.targeted_by_vaccination_ring.count(): # subject to vaccination
    if pt.protocolassignment is None or pt.protocolassignment.control_protocol is None:
        warnings.append("FATAL: You must assign a Control Protocol to "+pt.name+" so that you can describe its response to vaccination.")
    else:
        protocol = pt.protocolassignment.control_protocol
        required = ['vaccinate_detected_units',
                    'days_to_immunity',
                    'minimum_time_between_vaccinations',
                    'vaccine_immune_period',
                    'vaccination_priority',
                    #'vaccination_demand_threshold',
                    #'cost_of_vaccination_additional_per_animal',
                    ]
        for field in required:
            if getattr(protocol, field) is None:
                warnings.append("FATAL: The Control Protocol field '"+field+"' is required because "+pt.name+" is a target of vaccination.")

[ndh2]

Re: the help text, can we recycle the text shown in the old Delphi screenshot? In other words make the interface look like:

Once a vaccination program has been initiated by any start/restart trigger, then detection of disease in these production type(s)                                  will result in vaccination of units of these production type(s)                                  within a ring with an inner radius of                  and outer radius                 

and also put "km" after those radius type-in boxes?

[josiahseaman]

There you go:

[josiahseaman]

@ndh2 I think I missed the "ring type: suppressive vs protective" field. Was the idea to add that in #272? I can add it right now if you like. Or should it be in the same migration with the prioritization field(s)?

[ndh2]

Suppressive is the case where there is no inner radius (or inner radius=0, depending on how you look at it). Protective is the case where there is an inner an outer radius. So you can break that out as a separate checkbox (which would activate/deactivate the inner radius field), or just infer it from whether an inner radius has been entered.

[josiahseaman]

Important! Migration 0014 needs to be rolled back before merging master into this branch. A new Migration 0014 was created in master and it's important that the migrations happen in the correct order. A new migration 0015+ will need to be created for Vaccination Rings.

[josiahseaman]

@ndh2 The i386 branch has been updated with all the master work. Take a look at it and let's talk about the merge schedule.

[josiahseaman]

On the UI side, I think these titles need to take up multiple lines:

[tjmahlin]

I really think we should allow the user to create unique names for vaccination triggers.

[tjmahlin]

Actually, I defined an alternate method for naming vaccinations over in #581 with the spec, Vaccination Trigger List Generation. The same model should be followed here, or (as stated above) the user should be allowed to create a title for each trigger.

[BryanHurst]

Vaccination Rings Beta Program

We have setup the i386_Vaccination_Rings branch as a separate program (different from ADSM and ADSM_Beta) named ADSM_Vaccination_Rings.

Installation

To run the compiled Vaccination Rings branch, you will need to setup a new program directory and new workspace directory.

1. Create a new folder for ADSM_Vaccination_Rings.
2. Copy the npu.exe file from an existing installation of ADSM or ADSM_Beta into the folder.
3. Launch a Command Window in the new folder by Shift-RightClicking in the white space.
4. In the Command Window, execute npu.exe --program ADSM_Vaccination_Rings and answer y to the prompt.
5. Downloading of all the files could take a while.
6. In the new ADSM_Vaccination_Rings folder that now contains the newly downloaded files, create a new file called settings.ini.
7. In the settings file, define WORKSPACE_PATH to be a proper file path to a unique location for the Vaccination Rings Workspace. Note: Be sure to use double back slashes for folder separators.

[missyschoenbaum]

Success - I was unable to open the cmd window in the manner shown in step 3, but I just opened a cmd window the regular way and navigated to my folder the old fashioned way.

[missyschoenbaum]

@ndh2 I am having troubles testing. I am attempting to use one of the 8 Slices scenarios. It doesn't import smoothly, as my XML is coming from one of the DSCXN builds. It will give me some import, enough to use as a baseline. When I go to look at control protocols, I don't see one. When I attempt to add one, it won't save using the apply button (i click back to the nav bar and return). But, if I look at the assign protocol I can see that a protocol was built to match each production type.

Also, in the CMD window I get this message

I realize I may be out of sync and tried to run the updater, but I am still out of sync.

[ndh2]

The Windows executable hasn't caught up to the interface yet. When I went to build a Windows version for this branch, I discovered that the maintainers of GLib (one of the main open-source components we depend on) have moved over to a new build system called MSYS2.

I'm still working on building the C part of ADSM using MSYS2. I'll follow up here when that's done. But until I have that piece in place, submitting the simulation to the C engine will fail.

[josiahseaman]

In addition to what Neil said, that looks like the database migration hasn't been run on the scenario you have open. Close ADSM and open it up again and it'll run the migration on the loading screen. Of course it still won't run a simulation until Neil is finished with that part.

[missyschoenbaum]

OK Thanks

[ndh2]

@josiahseaman there's a Windows exe for this branch now. It may need another DLL for the new dependency, JSON-GLib.

[missyschoenbaum]

@ndh2 I got an update for this branch on Friday. I am still getting an error where I attempt to validate. Am I out of sync somewhere?

[missyschoenbaum]

I must be out of sync, because I am not seeing the secondary priority either.

[missyschoenbaum]

@BryanHurst I am in a weird spot. I ran the updater with admin permissions, but it didn't' seems to update. I started from scratch and pulled the whole rings branch again, and still no update. What do I need to do to get a new build?

[BryanHurst]

I don't think anybody has made a new build of the rings branch. Neil is currently working on this branch, so I don't know the current state of it.

@ndh2 if this branch is stable, and you need, I can make a build of it and push things to the update server?

[ndh2]

There was a Windows exe uploaded to the vaccinations ring branch on Jan 11: commit bd4378a. I'll double check that exe.

[ndh2]

@BryanHurst @missyschoenbaum This branch is in need of repair at the moment; I merged in updates to bring this branch up to date with master, but there were merge conflicts and some stuff broke. I'll post on this thread when it's working again.

[missyschoenbaum]

@BryanHurst this looks like a research project. I will keep digging on my side to see if I can get any build up and running at my house, and post an update. All Team on October 2016 - we will have to determine if pushing this build is within our scope.

OK, I tested. I can pull up a Rings version and I still get the error on validation as noted above https://cloud.githubusercontent.com/assets/6644604/12891478/63cafd74-ce45-11e5-9c59-7d82958d1a8d.png When I attempt to update, I get permissions error even when I run as administrator. I will put in a ticket to get someone with admin privs to run, but I suspect that we are still at the point where there isn't a new build.

I did get an administrator to run an update. I am still getting the "no such column:trigger_vaccination_ring" error. I am showing to be running v 3.3.6.2

[missyschoenbaum]

Notes for testers: this build is really hard to test because it is hard to pull in an existing scenario. We may have to address this, as we expect to import existing 3.2.18 scenarios. In the meanwhile, you almost have to start from scratch. Maybe a pdf script would help here.

[BryanHurst]

I'll investigate the state of this branch and see about getting into a running state again. I'll also work on merging changes from master into this branch so it is more up-to-date.