Generate chain of events for individuals inc. for mni dataframe

[marghe-molaro]

This PR updates previous PR draft #1468

Now includes changes in the mother_and_newborn_info dataframe.

[marghe-molaro]

To add following discussion at Q4:

• Add option for users to specify characteristics of individuals for which histories are tracked;
• Ensure events after death are not logged (a few of these may slip through via pop-wide events)

[tamuri]

Are the copies of pop dataframe/rows "deep" enough? Do columns containing series and lists need to be copied iteratively?

The following population dataframe columns have object type i.e. the ones to check are copied/checked properly:

>>> [col for col in df.columns if df[col].dtype == 'object']
['rt_injuries_to_cast', 'rt_injuries_for_minor_surgery', 'rt_injuries_for_major_surgery', 'rt_injuries_to_heal_with_time', 'rt_injuries_for_open_fracture_treatment', 'rt_injuries_left_untreated']

[marghe-molaro]

Hi @tamuri,
This is now ready for review. Notable changes:

• Fixed issue with nan values being incorrectly logged as having changed;
• Unified approach to copying pop df + mni dictionary, and ensured object types are copied by value;
• In postprocessing, ensured events which may have been logged after the individual's death are not kept in the final histories (there won't be many)

[marghe-molaro]

Added features:

• Individuals now have an additional property called track_history. Events are only logged for individuals for whom track_history = True either before or after the event has ran. Developers are free to specify how this variable is updated by events in the simulation.

Note:

• Inpatient_Care is currently not an event associated with a specific individual, therefore (by definition) it is not logged by the individual history tracker

[marghe-molaro]

Now additionally tracking consumable, equipment, and bed days access for each individual

[tamuri]

A few suggestions below...

Looking at the logs, I don't know how common is the following scenario: same individual, repeated same event on the same dat i.e. you would get a number of entries that were potentially of a different execution of the same event. If so, you could add an incrementing counter that gets logged as an identifier to group the entries in the EAV table. Might not be necessary if this doesn't happen.

[tamuri]

Change key to same format as elsewhere: consumables.post-request_consumables

[marghe-molaro]

So unlike elsewhere, where the broadcasting happens before or after the named function is called, in this case the broadcasting occurs inside the _request_consumable fnc...so I opted to rename it consumables.on_request-consumables, but please let me know if you disagree

[tamuri]

I think it should still be called post-request_consumables. It is the state of things at the end of that function's block of code (like a postcondition), doesn't need to be in the caller.

[tamuri]

I think you don't need the to_broadcast argument here (I see that you check elsewhere where the individual tracker is registered) and simply use the existing `to_log? The notifier should always broadcast messages. Then the listeners register themselves to receive the message. If nothing is listening, there is no error. The obvious example is if a different module wants to listen for notifications.

[marghe-molaro]

My reasoning for adding a check ahead of the broadcasting is not to avoid error, but rather to avoid having to create the items_available, items_not_available, and items_used dictionaries if they're not going to be used (through logging or broadcasting, though I think safest to disentangle the broadcasting from "to_log"). I have opted to check if the module is included here.

[tamuri]

I understand. It's still worth decoupling the notification from the module. Add the following to notify.py:

    def has_listeners(self, notification_key):
        """
        Check if there are any listeners registered for a specific notification.

        :param notification_key: The identifier to check.
        :return: True if there are listeners, False otherwise.
        """
        return notification_key in self.listeners and len(self.listeners[notification_key]) > 0

Then use it in the consumables at the point of notification i.e.

if notifier.has_listeners('consumables.post-request_consumables'):
    # prepare the data
    # ....
    notifier.dispatch("consumables.post-request_consumables", data=....)