bauhausluftfahrt / matsim-uam Goto Github PK

Hi! The charging feature is very exciting. Will adding of charging information be added to the scenario creation scripts as well? Thanks!

See: http://eqasim.org

See commented warnings in src/main/java/net/bhl/matsim/uam/router/UAMCachedIntermodalRoutingModule.java

So that other MATSim user only have to install(UAM-Extension) and provide the input files.

When generating csv files using the script, the number of trips listed don't match with the number of pt trips from the log file neither with the number of (pt trips in the log file + uam access/egress pt trips)

It seems that UAM travel speeds are now based solely on link's freespeeds, see:

https://github.com/BauhausLuftfahrt/MATSim-UAM/blob/master/src/main/java/net/bhl/matsim/uam/qsim/UAMSpeedModule.java and https://github.com/BauhausLuftfahrt/MATSim-UAM/blob/master/src/main/java/net/bhl/matsim/uam/qsim/UAMLinkSpeedCalculator.java are unsused during simulation, leading to UAM speeds being equal link freespeed.

Would you propose creating a new TravelTime implementation for UAM that does the job or do you have other ideas?

UAM vehicles should have limited range based on their Energy Levels which deplete over time flying and recharge during non-flying time.

For some trips the time between arrival and departure is varying by 3 seconds.

Remove all non-required content from test uam_config.xml

Hello UAM team,

I wanted to check the provided examples for future use, luckily after the merges yesterday I was able to create the UAM files with the RunCreateUAMRoutedScenario and the config files from the "uam-scenario-creation" folder, thanks for the update! I wanted to use the created files and test them with the "RunMainScenario". Unfortunately, I got some errors during the createControler().run() in

Set<String> linkModes = new HashSet<>(hubAjaccio.getAllowedModes());

Looked to me like some leftover from previous testing. Therefore i commented it out. Without it, I got some errors from the station and travel links. The logs can be found in the attachment. Could you maybe have a look at the example scenario or have a look at what I'm missing to make the example scenario work? Thanks a lot!

Cheers
Tobias

logfileWarningsErrors.log
logfile.log

Currently tourists have access to all the modes, but they should not have an access to a private car or a bike mode. So we would need to have an attribute telling us that these people are tourists in order properly apply the mode choice model for them.

Bintray has closed down. Find other service to make MATSim-UAM available through Maven.

The parameters that were formerly in the CustomModeChoiceParameters class: preFlightTimeUAM_Sec, postFlightTimeUAM_sec, turnAroundParameter_sec, deboarding_sec and boarding_sec are being used in the simulation but not in the mode choice when calculating travel times. These parameters are now being taken from UAM Vehicles and UAM Stations.

-Add a mode choice model that between all possible modes for every trip always takes the fastest one

Each UAM station consists of multiple nodes and links (street --> ground access node --> flight access node --> flight level link), without z coordinates, they have the same x and y coordinates, which causes zero-length calculations even though, the link length (within the network file) is set to be >0.

Hey,
I am trying to create a scenario with UAM from an existing MATSim Scenario, so I wanted to Run the RunCreateBeelineScenario method within the UAM Package. It seems to me, that the ConfigAddUAMParameters method which is called is not updated to go with the newest updates in the UAMConfiggroup because i get the Error that ie. the parameter inputUAMFile is not supported anymore. Are there any Works done or planned on that?
Greetings
Tobias

Are the classes marked with @Deprecated suppose to be deleted or kept in the open source UAM extension?

UAM stations should have limited capacity with regards to parking cars, parking UAM, and simultaneous take-off and landing

Let's see whether we can upgrade our implementations to use a newer MATSim version like 11.0

Is it necessary to hard-code the events interval?

It seems to me that the dynamic search radius option is not used properly. The code here:

would make the search radius considerably large. Imagine a situation where the original search radius is 5000 meters and the Euclidian distance of the trip is just 100 meters. This would turn into a 500 km search radius.

I am nost sure what was even meant here to be able to fix it. At a minimum I would put the default of the:

to false

In order to drastically reduce the amount of empty flights.

The uam-test-scenario was not upgraded properly and does not work now. It only requires a few changes to uam_config.xml and uam_vehicles.xml.

The fixed version: uam-test-scenario.tar.gz

Search in radius, if none found, for the current lookup, search again for radius = distance to nearest station + extension radius (e.g. 2 km). Compare this to an oval-shaped radius around a station.

Running the uam-extension for Munich with the demand generated by the model MITO (msmobility/mito), with the UAMRoutingStrategy.PREDEFINED, which already chooses by itself access/egress stations and modes.

When I set up the number of MATSim iterations to 50 I found the following results (only UAM demand is simulated):

Average handling time by iteration (handling time includes a fixe pre-processing, boarding and post-processing plus a demand-dependent component):

Scoring:

As seen, the plan scores get worse after every iteration. The routes get longer as well. The final iteration shows too high waiting times and too long routes. The question is what is MATSim replanning at each iteration.

Any explanation or quick answer to this? Do I simply need more iterations? And why not use the first iteration directly?

Attached the output config file as well.
mito_assignment.output_config.zip

Thanks!

• UAM routing strategies are being called only once at the beginning of the simulations.

• This is happening because the singleton class UAMRoutes is not being cleared in the end of iterations;

• The routing strategy is selected in the calcRoute method in the OptimizedUAMIntermodalRoutingModule ;

• It only makes sense to clear the uamRoutes data and use the routing strategies in every iteration if the departureTimes are changing through iterations (which is not the current case) or the strategies start to use previous information from the last iteration or current selected plans, otherwise it is just more computational time for no changes in the routes.

• The computational time is expected to have a considerable increase when using routing strategies in every iteration.

• This has already been done in the past and can be checked in this commit.

• A switch to choose whether the simulation is going to perform route strategy calculations in every iteration is an idea.

We need to look into optimizing the UAM router.

Since we will need to route in in MNL we can keep that route and use it in the router later on in order to avoid doing everything twice.