re-organizing contents within mainHelpers/*

[AtiyahElsheikh]

I propose to place some of the functions within mainHelpers to the LPM.Demography.{Create,Initialize,*} modules as I am already making use of them.

[AtiyahElsheikh]

as well as the Model data structure.

The functions run! & step! clashes with MA.jl (compiler asks to import run and step from MA.jl).

[mhinsch]

Yes, that makes sense. I think while we are at it we can do some more reorganisation.

• To be honest I don't really see the point in separating Create and Initialize, so I would suggest fusing them to Init and add the setup functions from mainHelpers.jl in there.

LPM and MALPM aren't really symmetric (one is the simulation itself and the other is a wrapper), so:

• move generic to xagents
• move multiagents to malpm/xagents
• move lpm to sim (or remove it altogether)

I'm generally not a great fan of empty modules (i.e. modules that only exist as directories). For something like Java this makes perfect sense, since each class is supposed to be a self-contained unit. But in our case the different components are very much not self-contained. I think it's fine to keep e.g. Demography as we might add other modules in the future, but LPM for example is completely pointless.

[AtiyahElsheikh]

Create would correspond to declaration with elementary ways of initialization. The idea of separating initialize from create, that there are sometimes a need to extra initialize the components. This is for instance the case with Modelica langauge which provides an additional section (called initial) just for extra initialization. May be something similar exists for ModelingToolkit.jl as well and others. This is also the case where LPM houses, towns and population are created (declared). The mutual initialization is not elementary enough (to be declared in an ABM-based specification language).

[mhinsch]

Create would correspond to declaration with elementary ways of initialization. The idea of separating initialize from create, that there are sometimes a need to extra initialize the components. This is for instance the case with Modelica langauge which provides an additional section (called initial) just for extra initialization. May be something similar exists for ModelingToolkit.jl as well and others. This is also the case where LPM houses, towns and population are created (declared). The mutual initialization is not elementary enough (to be declared in an ABM-based specification language).

Hmm, I guess I see the point. But to be honest, I don't think it's a very useful distinction and already at this point not entirely consistent. createPopulation for example does more than create agents as it sets up partner relationships. From the point of view of the model whether a function creates objects or not is a rather superficial distinction. It's much more important which functions are required to produce a valid model state.

[mhinsch]

as well as the Model data structure.

The functions run! & step! clashes with MA.jl (compiler asks to import run and step from MA.jl).

I think you haven't pulled the latest version. I had already renamed run to runModel (same can be done for step of course).

[mhinsch]

as well as the Model data structure.

Wouldn't that clash with MA? I thought it used its own internal bookkeeping to keep track of agents and data.

[AtiyahElsheikh]

Wouldn't that clash with MA?

I am using Model as a constructor argument for a MABM-object, and I have thus removed the initialization part from MALMP.

[AtiyahElsheikh]

I don't think it's a very useful distinction and already at this point not entirely consistent. createPopulation for example does more than create agents as it sets up partner relationships.

I remember that the constructor I am using for ABM has a declare function as an optional keyword argument. But I am into deleting this constructor (if not already done) and indeed this seems to be a non elementary initialization.