ABM improve assigned locations framework

[DavidKerkmann]

Motivation / Current Behaviour

We assign fixed locations such as Home, School, Work to all agents, which is there go-to location when they move to the respective location type. This makes sense and works well with the normal mobility rules. However, we might miss a representative group and trips of people, e.g. teachers, elderly care workers, physicians, nurses, visits of other peoples home, or in general people that go to places where the intentions mismatches with the assigned location. When working with the trips, this is not so much an issue as we can define specific trips that allow to go to other locations.

A second issue is that we need the option to have multiple assigned locations. This is most relevant for people that go to multiple social events, which is very common and less relevant for people that go to different work places, schools, or else.

Enhancement description

For the first issue, it is enough to modify or improve the set_assigned_location function to not necessarily take the location type as the intent, but have the option to state the intent. An overload seems to be the easiest way to fix this.

For the second issue, more thought needs to be put in, especially how one would decide which of the locations to chose. A random choice is not realistic, as social gatherings wouldn't be likely to happen.

Additional context

No response

Checklist

• [X] Attached labels, especially loc:: or model:: labels.
• [X] Linked to project

[DavidKerkmann]

We discussed this further in our regular meeting.

There are multiple points that influence each other. Above, it was already stated that a

• location choice model is required to decide which location to go to. This goes into the behavioral aspects, and should be set up in a way that the user can change this. As a default, we can about which things can be taken into account, such as the location capacities.
• The capacities are already discussed in #758. In particular, issues with parallelization occur when we have a hard capacity check. Instead, a soft capacity could be used which diminishes the amount of people going there. If a hard cap is sustained, some sort of resolve needs to happen to determine what happens in case of a location overflow. Thus,
• it would be useful to have alternatives for each trip, if they cannot happen due to being denied. This can, of course, also happen due to other reasons than overflow, such as a positive test. In order to manage these aspects, we found that
• a trip scheduler can be used which generates trips for a whole day or a fixed time period into the future before the current time step is executed. This also helps with #785, as daily trips can be generated accordingly. For fixed trips each day, this can be implemented as a "fixed trip" for that person, and the scheduler will produce the actual trip each day. One-time trips can be scheduled similarly.
• Damping of location visits would be seen as independent from this and are implemented as a factor in the location choice model.

[xsaschako]

Keep in mind lockdown rules as a form of damping, consider adding lockdown rules as a parametrizable sruct.