---
# System prepended metadata

title: 'Parametrisation in the Zosterops Experiment for our temporal shortcuts :bird: :timer_clock:'

---

# Parametrisation in the Zosterops Experiment for our temporal shortcuts :bird: :timer_clock: 
## Problem: 
At the moment we are trying to simulate 2\*10⁶ years of bird evolution in an Area 1/3 the size of Kenya. If we were to simulate each timestep = 1 year, the simulation itself would take several years to complete. To circumvent this we are planning on taking shortcuts by temporal powers of magnitude so we are able to complete the simulation in a reasonable time. 
Following are first thoughts about our parameters and calibration experiments. 
## Model parameters
### time
This is the focus of this document. So far each timestep corresponds to one year/reproductive period. The goal will be to simulate 10 or 100 years in each simulation step. 
### map settings
no changes to the map should be needed as the specific map values stay constant or are yearly rates. Since the map will be changed the frequency of change will have to be adjusted but no major testing will be needed here. 
### general settings
#### cell size - *average number of birds per ha*
unsure if this needs to be adjusted. I assume not. 
#### fertility - *avg nuber of birds per clutch*
fertility has to be increased to accomodate the faster passage of time
#### dispmean - *mean dispersal distance of juveniles* 
dispersal distance will have to be increased to accomodate for repeated dispersal 
#### dispshape - *shape of the disperal distribution*
since more generations are going to disperse as one shape will be affected
#### growthrate - *global base growth/biomass production*
will have to be adjusted for the increase in timesteps *-> is this used in the zosterops model though?*
#### mortality - *global base mortality*
again will have to be adjusted to accomodate increase in timesteps
#### mutationrate - *one mutation per generation/individual, corrected for metabolic function*
we will have to increase this to simulate several enerations at once
### functions - *all the functions from zosteropsexperiment()*
Do any functions themselves have to be adjusted or is a change in parameters sufficient? -> any functions where a simulation step is basically the only parameter :thinking_face: 
#### survive!() 
mortality will be adjusted
#### reproduce!() 
fertility will have to be adjusted
*-> problem: how can the increased recombination be displayed in the sped up model. Several reproduction steps will have to be performed at the same time? kind of lost here, how have others solved this?*
#### mutate!()
mutation rate will be adjusted
#### zdisperse!() 
takes dispmean and dispshape as input parameters
#### checkviability!()
no adjustment necessary
## Parameterisation Experiments
With the help of the experiments we will try to estimate parameters for 10 or 100 timesteps at the same time

- [ ] **fertility** Calculate based on baserate. additionally count number of reproductions from a single central patch. 
- [ ] **dispmean & dispshape** initialise Zosterops at a single patch in the middle, Check dispersal distance after time. 
*Always look at the same lineage? Or is it better to initialize with a single couple. do we have negative effects for low genetic diversity in the model?*
- [ ] **mortality** initialize several patches with Zosterops, turn off reproduction and see how many survive? Alternatively calculate new mortality from the Formulas *-> both to check?*
- [ ] **mutationrate** increase mutation rate based on increase in speed. *(how is the function implemented will it simply work like that?)*
- [ ] **recombination** this is the big one. I am kind of at a loss here. Simply increasing clutch size will in a way simulate the accelerated passage of time but since there will be less mating events there is less of a chance for recombination. This is kind of important for our model though. 

## Model performance

*(Daniel)*

At the moment, the three most time-intensive components of the model are (in descending order):

1. Disk I/O (i.e. data output)
2. Reproduction
3. Dispersal

All of these scale linearly with the number of individuals ([ϴ(n)](https://medium.com/@joseiciano/an-introduction-to-big-o-big-omega-and-big-theta-d10b5c7db002)). Therefore, the most direct way to reduce the total runtime is to reduce the cumulative number of individuals in a simulation run. Reproduction runtime also depends on the number of offspring (so increasing `fertility` will increase runtime), while dispersal also depends on the dispersal distance (so increasing `dispmean` will increase runtime). Disk I/O depends strongly on `outfreq`, and to a lesser extent on which output formats are chosen.

Map initialisation is very expensive for large maps, but is amortised over long simulation run times (as in, it's a one-time cost).