Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Example #2: Group-dependent time-varying force of infection #41

Open
wants to merge 14 commits into
base: main
Choose a base branch
from

Conversation

ChiragKumar9
Copy link
Contributor

@ChiragKumar9 ChiragKumar9 commented Aug 28, 2024

README.md specifying model and groups.md specifying my conception of the ixa groups component for a food-borne illness that has a time-varying force of infection (i.e., seasonality) that varies by region/group. Rust pseudocode for the model. Any and all feedback appreciated -- the goal here is to not just think about ixa functionality but also how ixa structure can drive modularity -- and others are also welcome to review.

@ChiragKumar9 ChiragKumar9 marked this pull request as ready for review September 2, 2024 18:55
@ChiragKumar9 ChiragKumar9 changed the title Example of groups that change infection Example #2: Group-dependent time-varying force of infection Sep 2, 2024
@k88hudson-cfa k88hudson-cfa self-assigned this Sep 5, 2024
Copy link
Collaborator

@k88hudson-cfa k88hudson-cfa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the main thing to figure out is how this interacts with person properties if at all. The answer kind of depends on if you want similar interfaces for like mutation listeners/indexes and stuff, which you probably do.

I like the idea of internally enforcing the rules around one to one, one to many etc. depending on what relationship you define.

Might be worth providing some nice helper utilities for randomly assigning people into groups, but maybe that's overkill since it's not that hard

enum GroupTypes {Counties}

#[derive(Debug, EnumIter)]
enum Counties {A, B}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of defining k as a parameter, wouldn't it make more sense to have this derived from the total group types?

fn assign_and_plan_movement(context: &mut Context,
person_creation_event: PersonCreationEvent) {
// evenly distribute ppl among the counties
let county_index = parameters.get_parameter(population_size) % parameters.get_parameter(k);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason you want to do this differently from moving them (i.e. iterate through instead of randomly distributing them on the initial assignment?)

I would imagine this would end up as either an assign_random_group function on PersonBuilder (if this is how we end up interacting with person properties) or this is a assign_random_group is a trait extension on context that takes a person id, and you set up the listener here.

// that gives that value of the CDF.
// The math behind this is the same as drawing s ~ Exp(1), setting that equal to \int_0^t foi(u)du,
// and solving for the time t at which the infection happens, which is fewer steps/easier.
fn inverse_sampling_infection(context: &mut Context, person_id: PersonID) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is nice as a contrast to the other basic infection model. I wonder if this actually ends up being its own mini example?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants