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

Standard surveillance output #165

Open
seabbs opened this issue Mar 21, 2024 · 6 comments
Open

Standard surveillance output #165

seabbs opened this issue Mar 21, 2024 · 6 comments
Assignees
Labels
enhancement New feature or request EpiAware

Comments

@seabbs
Copy link
Collaborator

seabbs commented Mar 21, 2024

I think we want to define some standard surveillance output for _make_epi_aware as this will help with postprocessing and be of general utility (given the aim of the tooling).

I think the way to we want to do this is to create a new abstract function in EpiAwareBase that is called in the return of _make_epi_aware and dispatches on the EpiInfModel type used. This is so that we can have a generic method that just uses the expected infections for its metrics and more specific methods that use the already computed reproduction number estimates and growth rate calculations.

Alternatively, we could consider this as a post-processing step for the model output (i.e it works with a for object) but I think its nice to make use of the struct information we have to provide custom solutions which I think favours doing this in model (albeit only as part of the generated quantities).

This would look like

struct SurveillanceMetrics
	growth_rate
    reproduction_number
    infections
end

surveillance_metrics(AbstractEpiInfModel, I_t, gen_y_t, inf_process_aux)
	growth_rate  = ...
    reproduction_number = ...
    ?

    return SurveillanceMetrics(growth_rate, reproduction_number, ?)
end

surveillanec_metrics(Renewal, ...)
	growth_rate .... 
    reproduction_number = inf_process_aux.Rt
    ?
   return SurveillanceMetrics(growth_rate, reproduction_number, ?)
end

I'm thinking about the return as a struct as then we can build postprocessing that interfaces with this w/ some guarantee of correctness. Not sure this really makes sense or is the right way to think about it so would appreciate thoughts @SamuelBrand1?

@seabbs seabbs added enhancement New feature or request EpiAware labels Mar 21, 2024
@seabbs seabbs added this to the EpiAware 0.1.0 milestone Mar 21, 2024
@seabbs seabbs self-assigned this Mar 21, 2024
@SamuelBrand1
Copy link
Collaborator

I think this is a really good idea. Should be reasonable to achieve, we want or already have the functions to fill this in.

We can also add a pretty print to the struct so you get a lot of information (Unicode plots even?)

@seabbs
Copy link
Collaborator Author

seabbs commented Mar 21, 2024

We can also add a pretty print to the struct so you get a lot of information

I think we want more pretty printing of structs in general and wondered if there was a package out there. Can't find anything right now though

@seabbs
Copy link
Collaborator Author

seabbs commented Mar 21, 2024

Aside from structs are there any other data structures (and links please) we could be thinking about here to use to control dispatch?

@SamuelBrand1
Copy link
Collaborator

We can also add a pretty print to the struct so you get a lot of information

I think we want more pretty printing of structs in general and wondered if there was a package out there. Can't find anything right now though

I think the canonical way of doing this is overloading Base.show with a custom method

@seabbs
Copy link
Collaborator Author

seabbs commented Mar 21, 2024

Yeah I saw this and I was wondering if anyone had already done work on that for this kind of use case

@seabbs
Copy link
Collaborator Author

seabbs commented Mar 21, 2024

This kind of thing: https://github.com/MechanicalRabbit/PrettyPrinting.jl

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request EpiAware
Projects
None yet
Development

No branches or pull requests

2 participants