Agent module related to pregnancy and maternity leave (only maternitystatus and monthssincebirth for now).

I propose the following label. Please use this label only when urgently needed. Otherwise, no need for stating when something is going to be processed.

The book "Hands-on design patterns and best practices with Julia" recommends to employ import when a functionality is being extended, otherwise to employ using by default. This is so far the way I have followed.

At the moment it is initialized as an empty array.
Should that be rather defined as a linked list?

While I very much prefer tabs over spaces, I can live with the latter. They should be used consistently, though. Currently some source files use 2 and some 4 spaces. Can we agree on 4?

These are model (not software) concepts and should live in their own modules or files.

All population-wide transitions essentially do the same, so it makes sense to unify their interface. I have implemented that here (in Main.jl, Utilities.jl and socialTransition.jl): A function applyTransitions (for now in Utilities.jl, should maybe be in some sort of Population module) applies a transition function (which operates on Person) and the usual parameters (model, verbose, parameters, etc.) to all elements of an iterable. The specific simulation module (in this case for example socialTransition) also provides a predicate (here selectSocialTransition) to select the agents the transition needs to be applied to.

I think the use of ?: as an if-replacement is getting out of hand. It's really easy to skip over these lines and if you are - like me - used to the C/C++ use of ?: it automatically registers as non-modifying. There are some cases where it's nicer to use (modifying) ?: than if, but especially if one of the branches is empty I would really prefer it if we could stick with the boring option.

Agent module related to work, basically everything in sim.py:8363-8371.

Mixers.jl makes it possible to directly "assemble" a struct from parts:

@mix struct Bla1
    x :: Int
end

@mix struct Bla2
    y :: Float64
end

@Bla1 @Bla2 struct Meep
    z :: String
end

Meep will then have three fields, x, y and z (with the corresponding types). This would make the implementation of modular agent types a lot more lightweight as the combined type can be treated like a plain struct with all variables as direct members.

On the other hand we would lose the clear separation between modules, so it would be easier to for example accidentally access a BasicInfo property in Family.

Anyway, I don't have a clear opinion on this yet, but I thought it might be worth thinking about.

Some pieces of code is subject to simplification.

For instance:

            setDead!(person) 
            resetHouse!(person)
            isSingle(person) ?
                nothing :  
                resolvePartnership!(partner(person),person)

the last two statements can be moved to the function setDead!()

Also, the Person constructor can be improved so that the client does not take care setting up kinship relationship. My current, Person inner cor looks as

function Person(pos, info, kinship)
        person = new(getIDCOUNTER(),pos,info,kinship)
        if !undefined(pos)
            addOccupant!(pos, person)
        end

        kinship.father != nothing ? addChild!(kinship.father,person) : nothing
        kinship.mother != nothing ? addChild!(kinship.mother,person) : nothing  
        if kinship.partner != nothing
            resetPartner!(kinship.partner)
            partner.partner = person 
        end 
        if length(kinship.children) > 0
            for child in kinship.children
                setAsParentChild!(person,child)
            end
        end 

        person  
    end 

instead of

function Person(pos, info, kinship)
        person = new(getIDCOUNTER(),pos,info,kinship)
        if !undefined(pos)
            addOccupant!(pos, person)
        end
        person  
    end 

This also simplifies the implementation of DoBirths

p.s. : will also modify the ? to if

In the context of issue #79 , I thought to experiment with Julia new features, particularly declaring some fields to mutable struct to be const. It did not improve the performance in this case, but it is a nice feature. Another feature is the ability to declare global types.

Let me know if nothing against to use this feature

p.s. May be you know the UpdateJulia package

As far as I can tell this this the last non-trivial dependency on MultiABM in LPM. Unfortunately I can't see a simple way to get rid of this (at least if we want to maintain compatibility of LPM with Agents.jl).

I can see two ways to do this:

1. Use a macro to make the superclass of all agent types generic (sadly this is not possible in plain Julia code, struct T{S} <: S does not work).
2. A multi-part process along these lines:
   • make Create/Initialize/etc. agent-type agnostic (maybe not a bad idea anyway), by using type parameters where necessary (function arguments declared as ::Type{T} bind type T and can be called using the plain type, e.g. Int).
   • remove dependency on XAgents from Demography
   • move existing XAgents.jl to MALPMXAgents.jl and create generic XAgents.jl that declares dummy AbstractAgent and AbstractXAgent types
   • in modules LPM/MALPM include the respective XAgents module

This is not a good idea:

mutable struct Kinship # <: DynamicStruct 
  father::Union{AbstractPerson,Nothing}
  mother::Union{AbstractPerson,Nothing} 
  partner::Union{AbstractPerson,Nothing}
  children::Vector{AbstractPerson}
end 

I would rather not have if pars.useClass peppered throughout the code...

Come up with a way to add assumptions to the code so that:

• they will automatically be tested
• they can include additional information
• all assumptions can easily be extracted from the code

Currently parameters are of type Dict{Symbol, Any}, which is extremely inefficient, as a) Dicts are slow and b) the value type is Any and therefore potentially all code that uses parameters becomes type unstable.
The syntax of parameter access can be changed to pars.value without any loss in generality (if desired property access can be overloaded so that a Dict could still be used as a backend). This way the simulation functions themselves can remain agnostic as to which type parameters have and the frontend can decide which implementation to use.
Generally, I think, however, that there are few situations where a Dict is the best choice.

All simulation code should be agnostic with respect to agents.jl/MultiABM/whatever. population.jl and the code living in lpm/ largely still imports and depends on MultiABM, however.

This pops up everywhere (and is wrong everywhere...). I've added:

    p_yearly2monthly(p) = 1 - (1-p)^(1/12)

to Utilities.jl, but haven't bothered to push the change yet.

At the moment most functions seem to have explicitly typed parameters. Unless it is specifically known that a function only works for one type it is usually better to omit types.

Currently camelCase and snake_case are both used. Personally I prefer CamelCase for types and snake_case for functions and variables, but whatever we choose it should be consistent.

The simulation speed of MA-based main including doDeaths & doBirths is slow ca. 10 secs (40 secs when assumptions are being checked) & memory allocation is more than 1.5 GB (5 GB). So I will attempt (some of) the following

• #74 & #65
• cheap manipulation of the data structure within MA or
• Optimised versions of the algorithms
• Linking with Agents.jl

This is obviously bikeshedding, but declaration has a very specific meaning in the context of statically typed languages, so maybe we could use create or something like that.

Having Push!(LOAD_PATH,..) in the code is not good.

When executing the main script couple of times (which is usually my case using REPL and Revise), LOAD_PATH is always incremented with redundant directories. Also the file path is restrictive and the user is enforced to follow a specific directory structure for other Julia packages (e.g. MultiAgents.jl).

The same arguments apply to the code in Person.jl
push!(LOAD_PATH, @__DIR__)

Not important now, but in the medium term it would be good to split model functions into the iteration part, that picks the agents to be modified and the actual modification that operates on single agents. E.g. (simplified example):

function doAgeTransitions!(people, model, pars)
    for p in people
        ageTransition!(p, pars)
    end
end

function ageTransition!(person, pars)
     # all the important bits go here
end

That makes the model easier to read and modify (IMO) and would be needed anyway if we ever want to do an event-based version.

e.g. KinshipM and BasicInfoM
Module?

If this is the case, to my understanding you'd like to re-structure the code into more modules, e.g. Module Person. In this case, the naming convention would be enough to deduce if a file corresponds to a module or not.

Edit: Yes in this case, the module name should be different than the type name

Assuming deathProbability returns the mortality per year the way it is used in doDeath is wrong. The probability per month can be calculated as p_m = 1- (1-p_y)^(1/12).

The helper functions should be in a separate file so that different person types can reuse them.

When selecting a subset of agents for subsequent iteration it is much more efficient to use lazy iterators (see Main.jl:run!) than to create a new vector containing the selected agents.

more bikeshedding ;-) : I think module files should have uppercase and non-modules (i.e. files that are just included) lower-case names.

Module LPM/Simulate.jl is becoming larger and larger. The following is proposed:

module Simulate 
       ...
       include(simulate/helpfunc.jl")
       include("simulate/deaths.jl")
       include("simulate/births.jl") 
       include("simulate/marraiges.jl")     
       ...
end # Simulate 

This has been discussed in issue #73 before, but I wanted to give it its own issue. As I see it, using explicit imports (i.e. Using SomeModule: someFunction) has several advantages and disadvantages:
Advantages

• Makes it clear which parts of an API are actually used.
• Avoids cluttering the namespace with all exports of a module.

Disadvantages

• Maintaining the list of imports can be quite tedious.
• Maintaining the list of imports can be error-prone (it's easy to forget to remove an import when a function is no longer being called).
• It circumvents export control. Every symbol in a module can be imported if mentioned explicitly in a Using statement, no matter whether it was exported or not. At the very least this makes exports in project-internal modules completely pointless.

My conclusion would be that we should drop explicit imports at least for internal modules.

Currently some general functionality is still imported from MultiAgents. If LoneParentsModel.jl is supposed to be completely independent of MultiAgents.jl these imports should be removed. It would be nice to find a solution that doesn't duplicate effort, though.

At the moment, with getters/setters, imports, exports and delegation, adding one property to one of the agent blocks requires 10 largely mechanical, repeated additions (the property itself, getter/setter, export in Block, import in Person, export in Person, 2xdelegate in Person, 3 constructors), which seems a little excessive.
I'm not sure what the best solution is, but the current state is not ideal, I think.

I thought since @assertion is under consideration, I believe @todo macro could be also similar and useful. Basically, @todo export reminder information about functionalities that need to be implemented. This is particularly useful for functions that cannot be implemented right away.

A use-case (just as an example) , in the implementation of doDeath!(*) one makes use of many attributes of attributes of structs, e.g. person.info.alive. However, to make this function more generic, it would be better to have a function isAlive(person). I don't want to implement it myself right away myself, since I know you are working on that part of the code.

Currently, I am expressing the need of that function using the following piece of code

...
false ? isAlive(person) : nothing 
# or 
age = false ? age(person) : person.info.age   
... 

Apparently since there are nice ways to collect stats during a simulation, and also if working with lazy iterators, counting would be needed, then it seems better to not overload basic simulation functions such a responsibility.

Maybe it is actually required, but in first approximation I would say that if a population has agents that are not alive mixed in something is wrong.

I feel the task of enhancing a package X with code like

[function] does_something() ... 

with an additional package Y that reads X and generates

module Y

   using X 

   doesSomething(*) = does_something(*)

end 

Is somehow manageable? what do you think?

related to issue #16

add effects on work schedule etc. for mothers (direct translation from python for now)

If we split agents into modules, such as kinship, demography, health, etc. functions that operate on these modules won't automatically work on composite agents. For example add_child!(person) would be defined with person::Kinship in mind. An agent that contains the kinship module would then have to forward the function call: add_child!(person) = add_child!(person.kinship). This is very annoying at best and a source for errors at worst. Sadly Julia has neither mixins nor multiple inheritance so we have to find a solution ourselves.

I have a couple of ideas how to solve this (from simple naming conventions to meta-programming trickery) but in any case it would be nice to have a general solution.

Having a universal type ABM sounds attractive, but I think in practice there is little it can buy. On the other hand the same efficiency argument applies as with parameters.
As with parameters using dot syntax to access global simulation properties within the simulation code doesn't hurt but has the potential to allow for a much more efficient implementation.

With modular agents in place it might be better to avoid assuming any internal layout in agents altogether. So, for example instead of agent.info.age use age(agent) and instead of agent.info.age = 1 use setAge!(agent, 1).

Allows for inline declaration of default values and provides constructors with named arguments.

SomeUtil.jl was introduced because few routines could be used from both LPM.jl and MA.jl
Due to the simplicity of the included routine, I would simply move whatever needed to be under LPM/Utilites.jl & MA/Util.jl

Not terribly important, but just for the sake of completeness. My macros generate property(obj) and property!(obj). If you'd rather use something more explicit (e.g. getProperty, setProperty!) now would be the time to say so (personally, I prefer the more concise version, but it's not something I can't live without).

This is complete list of symbols that are still imported from MultiAgents. They should be moved to MainLPMMultiAgents.jl (or similar):

• ABM
• MultiABM
• MABMSimulation
• run!
• verify
• read2DArray
• date2yearsmonth
• removefirst!
• subtract!
• add_agent!
• dummystep
• defaultprestep!
• defaultpoststep!
• startTime
• dt
• attach_agent_step!
• attach_pre_model_step!
• attach_post_model_step!
• setup!
• allagents
• nagents
• initial_connect!
• attach2DData!
• AbstractExample
• AbstractAgent
• AbstractXAgent
• getIDCOUNTER
• kill_agent!

It includes the following statement

setParent!(child, father) # father is not defined

RunTests.jl needs to be modified to detect such bugs.

Simulation runs should always be reproducible by default. If repeat randomisation is desired that should be made explicit.