Hello all,

I was guided here by many recent papers using AMoDeus as their simulation platforms. From my understanding, this is a platform developed for AMOD assessment extended from MATSim. However, I still don't know when and how I should use AMoDeus.

Some current status of my project: I have generated several necessary files for MATSim simulation (including plan, network, vehicle, config etc.). I want to add AVs into my model and currently learning about the DVRP extension (since many previous papers published between 2016 to 2019 use this).

As a result, how do you suggest my work? Should I continue with my DVRP learning, or I can directly use AMoDeus for AV assessment? Many thanks for your help! :P

I set ReferenceFrame=New York and LocationSpec=New York,then I run the simulation on the software, the software does not recognize it.Only four cities mentioned in the example given on the official website were identified by the software.Why is this happening?Which part of the code should I change?

FuturePathContainer has, as far as i see, the sole purpose of using the ParallelLeastCostPathCalculator, getting a future and then waiting until the future finishes. So basically, it "serializes" the parallel router. In that sense, why not just use the serial version (in fact, the ParallelLeastCostPathCalculator is already a wrapper around the serial version. Originally, the purpose was for instance, to issue some routing tasks in one time step and just retrieve it in the next time step (i.e. one would assume that it is okay for a customer to "wait" one second more for the routing).

Is it true, that in Amodeus, this is always used in serial? Then we should be able to heavily simplify this. Also I'm facing problems right now with the router producing errors, but they are never shown, because they are somehow called in a lambda expression, and then in a thread, or some strange combination which makes the program block without producing any error.

ScenarioOptions always creates a file. However, it is no problem to use it on-the-fly using e.g.

ScenarioOptions options = new ScenarioOptions(new File("."), new Properties());

However, this leads to ambiguity, because next time one runs this there maybe some default values coming from the config file that has been created silently. So best would be to have a standard constructor like new ScenarioOptions()

During the developer meeting, I will push forward the migration from the AV Extension to Amodeus. Here are the points to track progess:

• Discuss at Developer Meeting whether integration with DVRP or DRT makes sense
• Finalize combination of Amodeus with standardized eqasim simulations @ eqasim-java
• Go through pending issues for Amodeus
• Add IterativeTravelTime (long pending task)
• Provide option to use a ConfigGroup instead of ScenarioOptions
• Move AV Extension (av) into Amodeus repository

Afterwards, we can work towards closer integration and clean up many parts.

LPUtils.getNumberOfVehicles arbitrarily expects an av.xml to be located in the working directory to obtain the number of vehicles. This should be passed down from the TravelDataCreator.

The point is that 1) the file could be called differently, and 2) usually (we IVT) do not use it at all, but we configure everything in the code (and thus the information should come from a AVConfig object).

There seems to be a special case in RoboTaxi::notDrivingOnLastLink. For the current scenario that I run the assertion there fails (GlobalAssert.that(avT instanceof AVDriveTask)). This happens very rarely (once or twice in a simulation with 46k requests).

I did some debugging for the problem and it happens in the following situation:

• getSchedule().getCurrentTask() indeed gives AVStayTask
• status is set to REBALANCEDRIVE

So what seems to be happening is that the vehicle has been sent to rebalance, but arrives at the location before it gets further instructions (and hence switches to the AVStayTask). For now, I solved the problem in my development branch by returning true if this special case happens.

Since it happens very rarely, I'm not sure how exactly to write a unit test, or what would be a good approach to write a unit test for that (and I'm not sure if simply returning true in that case has any further implications).

When the simulation runs for more than 127 hours, the timeseries plots which are generated in the postprocessing steps have a major issue. After 127 hours there is a jump in the timeseries back to -126 hours, because the hours are converted from an integer with 32 bit to a byte with 8 bit. (details can be found below)

An exemplary plot looks like this:

In this plot the data which is plotted at the beginning (27th and 28th March) should be at the end of the timeseries (for 7th and 8th April).

When creating the timeseries for the plot the toTime() function inside of the StaticHelper is called for each timestep. At the end of the function an org.jfree.data.time.Second object is created, which creates objects of org.jfree.data.time.Minute, org.jfree.data.time.Hour and org.jfree.data.time.Day in a cascading fashion.
The error occurs when creating the object of org.jfree.data.time.Hour. When creating this object the integer from the constructor is being cast to an byte.

This means that the hours are becoming negative, when the simulation runs longer than 127 hours.
A possible fix would be to adapt the creation of the org.jfree.data.time.Second object in the toTime() function.

For further decoupling of Amodeus with MATSim, we should do some refactoring to remove Amodeus*Task from the Amodeus "core". I read a bit through the code, and basically these classes are mainly used to derive what state a vehicle is currently in and for retrieving additional information (e.g. checking if a vehicle is in AVStay and if so, getting the current link from the StayTask to determine whether the vehicle should be moved somewhere else (because it got the command) or is should stay (because the command has the same location)). So my feeling is that most of what happens with Amodeus*Task in the core can be put behind the RoboTaxi interface, as right now we would usually have something like:

if roboTaxi.task = AVStayTask {
   destination = roboTaxi.task.destination
   # Do something with destination
}

An (incomplete) list of things that still came to my mind during the last refactoring:

• Define classes such as VirtualNetworkReaderXml, VirtualNetworkReaderBinary, VirtualNetworkWriterX and the same for TravelData in a more object-oriented style like is done in MATSim, e.g. for the NetworkReader/Writer
• Define such readers and writers for ScenarioOptions and LPOptions to make it easier to handle them (not relying on the working directory, etc.)
• Remove SafeConfig, but instead have expressive configuration classes for the dispatchers. There should be, for instance an BasicDispatcherConfig with getters and setters for publishPeriod, rebalancePerid, dispatchPeriod, but dispatchers with more configuration could define classes such as GlobalBipartiteMatchingConfig with additional configuration options if they are necessary.

The av extension now supports separate definitions for "dropoff time per stop" and "dropoff time per passenger". Currently, Amodeus is not capable of working with the latter. The problem is easy to replicate if one sets "dropoffDurationPerPassenger" in testScenario/full_config.xml to a value larger than 0.0.

Then, any shared (not unit) dispatcher will fail eventually when the SharedRoboTaxiTest is run. I assume the error originates from SharedUniversalDispatcher::exexuteDropoffs. Need to check further what is happening there (certainly, only the dropoff time per stop is used for something) and compare how things are done in the unit case.

I guess this also raises the question what happens when an agent is "late" for pickup, as this seems to be the opposite problem. Unfortunately, we don't have a unit test yet where an agent is late. Need to add this.

To do:

• Look into dropoff time per passenger and shared dispatchers
• Write unit test where an agent is late for pickup in unit/shared case

If "completeGraph" = "false" is used with MatsimShapeFileVirtualNetworkCreator an error occurs if not all links in the MATSim network are covered by the shape file (i.e. if only a subpart of the scenario should be used for AV operation).

Hey everyone, first of all thanks for the great work on amodeus so far.
I played around a bit to verify if amodeus fits to my needs for simulating taxi services in Munich.

Actually I'm struggeling with the values given in the Simulation report. It seams, that the distances calculated do not match to the real driven distances inside the simulation. Is there any know Issue related to this.

To get closer I tried a simple run with one vehicle and two requests. The two rides have an original distance of 7,8 km

The report shows that the total distance with customer for example is 4,30 km, where the total distance taken from the output_plans.xml is 7,2 km. Due to other routes driven in the simulation this should be the correct distance.

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE population SYSTEM "http://www.matsim.org/files/dtd/population_v6.dtd">

<population>

	<attributes>
		<attribute name="coordinateReferenceSystem" class="java.lang.String" >EPSG:25832</attribute>
	</attributes>


<!-- ====================================================================== -->

	<person id="74106653">
		<plan score="16.371905150264233" selected="yes">
			<activity type="activity" link="81488" x="689102.4713871534" y="5336865.173642203" end_time="00:00:11" >
			</activity>
			<leg mode="av" dep_time="00:00:11">
				<route type="av" start_link="106689" end_link="10888" trav_time="00:00:00" distance="5730.515483306246">{"inVehicleTime":"NaN","price":"NaN","waitingTime":300.0,"operatorId":"op1"}</route>
			</leg>
			<activity type="activity" link="10888" x="693285.7122613986" y="5334743.275227725" >
			</activity>
		</plan>

	</person>

<!-- ====================================================================== -->

	<person id="74106660">
		<plan score="16.682785827886924" selected="yes">
			<activity type="activity" link="26840" x="691752.5100729803" y="5335422.55546116" end_time="00:00:44" >
			</activity>
			<leg mode="av" dep_time="00:00:44">
				<route type="av" start_link="109926" end_link="41942" trav_time="00:00:00" distance="1511.421616468973">{"inVehicleTime":"NaN","price":"NaN","waitingTime":300.0,"operatorId":"op1"}</route>
			</leg>
			<activity type="activity" link="41942" x="690526.904471905" y="5334972.770260792" >
			</activity>
		</plan>

	</person>
</population>

Often, Amodeus uses Enums at strange locations. For instance, I see that there is a
MatsimShapeFileVirtualNetworkCreator
that I find in one old run script for a paper. Now I want to check if there is a different one, that creates me a VirtualNetwork on the fly. The "natural" Java way (in my opinion) would now be to go to MATSimShapeFileVirtualNetworkCreator, find the interface that it implements (which would be VirtualNetworkCreator) and then check for the implementations. The way it is now I have to look though the whole project to find a class (/enum) that does what I want, but without any indication that it has a certain purpose (i.e. creating a network). I think Amodeus does this not only in this case but in several other places.

Right now, there is a method to create TravelData:

TravelDataCreator.create(...)

It works perfectly, but at the end the feedforward dispatcher will complain that it doesn't understand the "LPEmpty" TravelData. After tracing the error, I found that TravelDataCreator.create calls LPPreparer.run, which silently tries to load information from a file called "LPOptions.properties" in the working directory.

• First step would probably be to add an exception there so people are aware that something is missing.
• Second step would be to provide a way to do this cleanly without the need of an auxiliary file.

In Request::Request(double departureTime, Link fromLink, Link toLink) an error is thrown if departureTime is later than 24h. Not sure why this is? I don't see why, for instance, TravelData would not work with a longer time span?