thoughts on using findEmtyHouses

[AtiyahElsheikh]

Currently, there are different patterns regarding house association within basic simulation routines:

• the doDivorces! routine is responsible for allocating a divorced person (and potentially some of his associated children) to a new house.
• On the other side, the doDeath! routine (currently) does not allocate parent-less child(ren) to a new house / adoption family and this planned be done in another separate routine.
• A new baby is associated to the house of his parent
• On the other side, doDeath! resets a house to exclude a dead occupant (which is fine since the associated house is directly accessible).
• I guess there are also similar dilemmas regarding doMarraiges (did not read it yet)

The idea is, should such routines overloaded the responsibility of such (re)-allocation?

A no answer further simplifies the logic and favours a purely demographic simulation without houses or location information, e.g. primitive person types. But this adds extra implementation overhead for (an) additional routine(s) that do the house association job.

[AtiyahElsheikh]

Solution could be to transform the pattern

# function do doDivorces() calls compisiteTasks

function compositeTasks(*) 
    .... 
    conductTask1() # e.g. divorce
    condcutTask2() # e.g. housing 
    ...
end 

to

# couple of versions of doDivorces*() make use any or both of the following   
function simplieTask1( ... ) 
    ...
    # divorce stuffs
    ...
end 
...
function simpleTask2( ) 
   ..
   # House allocations
   ... 
end 

[AtiyahElsheikh]

And the different doDivorces* need not to have different names when annotated with static person types (if it is so far and we have already different person types).

[mhinsch]

Sorry for the long-winded rambling - I was thinking while I was writing... TL;DR: I think my preferred option would be to have clear functions that do this stuff, but maybe call them immediately for now.

Without having looked at the code in detail I think the problem might be best solved by having functions that are solely responsible for moving agents that need to be moved. So, for example moveDivorcedCouple, moveMarriedCouple (which already exists as joinCouple, etc. Whether these functions are then called directly from e.g. doDeaths or in a population sweep that collects for example all divorcees afterwards would then be mostly a matter of convenience and/or efficiency.

That said, I think the advantage of handling these moves immediately is that it leaves the population in a valid state at all times. The caveat with that is that we have to take care that agents aren't being "double processed" for some reason.

Either way I would like in the long term to transition towards a more "event-oriented" approach in the sense that we really only implement events that happen to single agents and keep the scheduling separate from that (I think this is also in line with Agents.jl's approach, isn't it?).

One important thing to keep in mind (in this but also other contexts), I think, is the difference between implementation and model. For example in model terms it is clear that dead individuals stop doing anything. In implementation terms, however, this can be accomplished e.g. by skipping dead individuals in all activities or by removing them from the simulation entirely. Which one is better is a purely technical decision that has no effect on the model.

Coming back to the original question - in modelling terms all of these processes (adoption, divorcees moving out, etc.) happen immediately at the moment, so whether they are processed ad hoc or in a sweep afterwards is a technical decision. However, at least for some of these processes we know that they can have a substantial delay in real life (couples moving together is a good example) and we might in the future want to model this delay explicitly. So, in that sense it might be prudent to at least keep the functions that do these things (joining couples, separating divorcees, etc.) clearly separate.

[mhinsch]

And the different doDivorces* need not to have different names when annotated with static person types (if it is so far and we have already different person types).

I don't think we will ever need different person types within the same model, so I don't see the problem.

[AtiyahElsheikh]

(I think this is also in line with Agents.jl's approach, isn't it

I did not dig into that part of Agents.jl.