Generalize covid initializer process to different INIT_DATE parameters.

[arik-shurygin]

Currently certain assumptions in our CovidSeroInitializer, specifically the prevalence of omicron at t=0, are keeping it from being generalizable to different start dates. Here is an example of the somewhat hardcoded assumptions:

DynODE/src/dynode/covid_sero_initializer.py

Lines 267 to 280 in 3690865

	infection_dist = np.sum(pop_sizes_with_relative_immunity, axis=-1)
	infection_dist = np.repeat(
	infection_dist[:, :, :, np.newaxis], repeats=3, axis=-1
	)
	# set all strains that arent omicron to zero, since we repeated them 3 times above
	infection_dist[
	:,
	:,
	:,
	list(
	set(list(range(self.config.NUM_STRAINS)))
	- set([self.config.STRAIN_IDX.omicron])
	),
	] = 0

what this is saying is that all current infections at t=0 must belong to the omicron strain. Which is clearly only the case around 2022 in USA.

This is fine as long as we begin fitting at this period, which has generally been the case because it is a convenient time to do so, but this may not be true for the future or for other groups looking to use Dynode.

One possible solution for the latter code snippet is to take as input to the function what variant proportions user's want to see in their currently circulating strains at t=0.

But this also brings on a broader code architecture question. Considering the many changes needed to generalize initialization code I wonder if at a certain point it is better to say that each initializer is built for a particular disease and time, and those who want different viruses or different start dates will need to write their own... Curious your thoughts on this @edbaskerville @kokbent