MRC-CSO-SPHSU / LoneParentsModel.jl

An initial implementation of an ABM for social and child care
0 stars 5 forks source link

New Model API module #157

Closed AtiyahElsheikh closed 1 year ago

AtiyahElsheikh commented 2 years ago

This is needed to unify the simulation interfaces extensively discussed in many contexts

AtiyahElsheikh commented 2 years ago

Related discussion: The module would be defined as follows. Here explicit using statements is not really necessary.

using LPM.ModelAPI

When I read the code, I know that anything(model) is from there.

AtiyahElsheikh commented 2 years ago

Related discussion: It is quite natural to have parameters within model definitions, equations etc.

It is desired to have both the interfaces doDeaths!(model,time) & doDeaths!(model,time,parameters). However, I believe the whole thing will converge to the first API in future. Temporarily, this will look as follows:

# Generic API for doDeaths!
doDeaths!(model,time,parameters) = 
    doDeaths_!(alivePeople(model),time,model,parameters)

doDeaths!(model,time) = 
    doDeaths!(model,time,populationParameters(model))

Now there is a situation to spawn a further module from LPM.ModelAPI. Why?

There is no need to import everything within demographypars.jl, but rather something like that

LPM.ModelAPI.ParsAPI

The necessary modification is simple and now I know that any parametersX(model) comes from there.

AtiyahElsheikh commented 2 years ago

instead of

import LPM.ModelAPI

mhinsch commented 2 years ago

I see where you are going with this, but I still think that wrapping things in modules should only be done where either a) the code is generic and can be used elsewhere, b) functionality needs to be isolated from the rest of the program, or c) a chunk of code is separate and self-contained.