How do InteractionActivities work and how do they relate to trips?

[fastGeorge]

I've spent the morning experimenting with giving minor activities in my plan the "interaction" suffix with the intent of altering what is included in a trip and subsequent RoutingRequest.

The idea of my run is a plan:
location1 --> location2 interaction -> location1 -> location3 interaction -> location1

Where an ev travels and can charge either at location1 or out on the trip. When location2 isn't an interaction, the trips for the first part are handled as two separate trips between location1 -> location2 and then location2 -> location1. When this is the case it is difficult to say at what time optimal charging would take place. While, if the interaction suffix is used, all trips would be given as location1 -> location1 and then the entire trip where there is a potential demand for charging can be handled at once.

With this as a background I wonder how and where the interaction activities are created. My main issue is that I need to be able to set a duration for the interaction activities based on what is set as the maximum duration in the plans file.

Perhaps I'm searching for a solution in the wrong place and am trying to use MATSim in an unintened way.

[sebhoerl]

Interaction activities are created by the RoutingModules which are in turn created by the TripRouter whenever a trip (between two activities needs to be routed). On the other end of the logic, a "trip" is identified by finding activities which are not interaction activities. So for mode choice and other purposes, there is functionality (TripStructureUtils) that can identify the sequence of trips in a plan (by skipping the interaction activities). Interaction activities are identified by looking for the "interaction" suffix in their name.

I'm not sure, I completely follow your example on charging. In any case, if you are referring to the car mode, the class that creates your route (including the "car interaction" activities) is the NetworkRoutingInclAccessEgressModule.

[fastGeorge]

The idea with the charging was that for a vehicle that has the possibility to charge at A but not B and with a trip A->B->A, in my approach it would need to charge somewhere along the way by finding a public charger and so on. To know if it has charged sufficiently it can simply look at how long the remaining trip is in relation to its current position. However, when A->B and B->A are two separate trips, it is more difficult to answer the question of when the vehicle needs to charge and when is the best time to charge. So far I've used a custom RoutingModule but came across this issue when trying to implement public charging.

The thing is that I named some of the activities with the suffix interaction already in my input plan and it seems that MATSim treats them in a special way already before the RoutingModule, but I might be mistaken. The activities that I've added the suffix to are only interesting in terms of their fixed duration and as a mandatory visit in the plan.

I'm also considering an alternative approach using randomness and scoring to make the vehicles find optimal chargers through the iterative process of MATSim, so that might be the way to go, but I was curious about how to effectively utilise the interaction activities in the trips.

[fastGeorge]

The difference between A and B being that it is okay to arrive at A with a low SOC but not to B.

[sebhoerl]

I'm not sure who is behind your Github name and if we talked recently. In any case, we have added quite a bit of components for charging planning recently. Did you have a look at that?

So what you describe is that you add interaction actviities in your initial plan. Those are indeed detected as "being part of the trip", so they will be replaced when the agents do replanning, dependent on what comes out of the RoutingModule. If you want to keep them with a fixed duration, why not "not" call them interaction?

[fastGeorge]

Sorry about not introducing myself. I'm Gustav, a master student at LTH writing my master thesis with Mattias as my supervisor. You're right in that we should look into your overhaul of the ev-module. In my learning MATSim I just got curious about understanding the structure and purpose of the interaction activities better. From my difficulty in expressing my idea it seems that my understanding of the RoutingModule is too limited.

Thanks for your help, and now I'm instead looking forward to looking into your new charging components!

[kainagel]

From the above comments, it feels to me like the interaction activities (in the matsim sense) have nothing to do with your problem. The interaction activities were "invented" a long time ago, when we needed to go to hierarchical trips, such as "walk to pt stop", "take bus to destination bus stop", "walk to destination". These are all "legs" (in the matsim sense), but the original data model needed an activity between any two legs. Keeping that data model meant that all visualizers kept working. However, those interaction activities are really part of the trip as a whole, and it would be quite involved to give additional meaning to them.