http://www.simulace.info/api.php?action=feedcontributions&user=Shcs00&feedformat=atomSimulace.info - User contributions [en]2024-03-28T16:00:20ZUser contributionsMediaWiki 1.31.1http://www.simulace.info/index.php?title=WS_2021/2022&diff=22238WS 2021/20222021-12-20T15:57:20Z<p>Shcs00: </p>
<hr />
<div>Semestral papers from winter term 2021/2022. Please, put here links to the pages with your paper. First you need to have your [[Assignments WS 2021/2022|assignment approved]]<br />
<br />
[[Carsharing_Fleet_Optimization|Carsharing Fleet Optimization]], Sergei Shcherbinin [[User:Shcs00|shcs00]] 16:57, 20 December 2021 (CET)</div>Shcs00http://www.simulace.info/index.php?title=WS_2021/2022&diff=22237WS 2021/20222021-12-20T15:57:04Z<p>Shcs00: </p>
<hr />
<div>Semestral papers from winter term 2021/2022. Please, put here links to the pages with your paper. First you need to have your [[Assignments WS 2021/2022|assignment approved]]<br />
<br />
[[Carsharing_Fleet_Optimization|CarsharingFleet Optimization]], Sergei Shcherbinin [[User:Shcs00|shcs00]] 16:55, 20 December 2021 (CET)</div>Shcs00http://www.simulace.info/index.php?title=Carsharing_Fleet_Optimization&diff=22236Carsharing Fleet Optimization2021-12-20T15:53:17Z<p>Shcs00: </p>
<hr />
<div>=Introduction=<br />
<br />
Recently, carsharing becomes more and more popular in large cities. Short-term rental (from several minutes to 24 hours) of a car with possibility to drop it anywhere in the allowed area in the city attracts people who, for some reason, do not want to use their own vehicles. However, it is not always convenient. If the fleet is relatively small, the probability that a car will be somewhere close by is also quite low. Cars also must be refueled or recharged sometimes by staff, which would increase cost of the fleet maintenance with increasing of the fleet size.<br />
<br />
=Problem definition=<br />
<br />
Carsharing companies have to solve a problem of optimization of their fleet size, which is not simple. The entire system of carsharing is complex and has many different parameters that must be considered for decision making. For example, if the number of cars available in the city is relatively small the maintenance is also respectively inexpensive. However, in this case, the probability that users can find a car next to their location drops drastically. On the other hand, having too many cars leads to the risk that they will stay with no use for long time. The goal of this simulation is to understand how the carsharing system behaves and propose quantitative solution on optimal number of cars and price of rent to maximize marginal profit of a hypothetical carsharing company.<br />
<br />
=Method=<br />
<br />
Since the system consists of several entities, each of them is able to some extent to make decisions, and system itself is dynamic and requires to take into account spatial factors, agent-based modelling was chosen as the most appropriate tool to design the simulation. Implementation was performed using NetLogo software platform.<br />
<br />
=Model=<br />
<br />
The model is represented by several agents and accepts some simplifications. It is assumed that the simulation will be run on ticks, every tick represents one minute of real time.<br />
<br />
==Agents==<br />
<br />
The model contains 3 types of agents: cars, users, and maintainers.<br />
<br />
===Cars===<br />
<br />
Represent the vehicles used for short-term rentals. Cars have the following characteristics:<br />
* price - cost of rental per minute<br />
* status - current status of the vehicle, can be ''idle'' (the car is ready for rent), ''booked'' (the car is booked but paid rent has not started yet), ''in rent'' (the car is taken in paid rent by some user, for the purpose of this simulation it means that the car is moving), ''needs maintenance'' (the car is not visible for users but visible for maintainers), and ''out of service'' (the car is not visible for users and maintainers, is already under maintenance by one of the maintainers)<br />
* fuel - how many liters of gas is left<br />
* mileage - for how many kilometres the car was already driven, every car must go through maintenance procedure every 10,000 kilometres<br />
* premium - boolean parameter that indicates if the car belongs to premium class<br />
* inspection - boolean parameter indicating that the car needs to undergo an inspection.<br />
<br />
Cars are located in the simulation space and, if possible, can be rented by users. Users can drive cars, i.e., move it from one point of the simulation space to another. Cars can be re-fueled and taken to inspection by maintainers. It is assumed that a car can serve for the purpose of carsharing only for 100,000 km, then the car is replaced with absolutely identical one.<br />
<br />
===Users===<br />
<br />
Represent people holding a driving license, registered in the carsharing service and actively using it. Every tick of the simulation users decide with probability 1% whether they want to travel from the current location to somewhere else and, if so, to what coordinates of the simulation space. However, there are peak hours when most of users want to travel (for example, commute to work). It is assumed that there are 3 such hours every workday, 15 hours during the week, i.e. 9% of all the time. During these hours 50% users want to travel somewhere.<br />
<br />
Then, user starts looking for a car and, if the user finds one near by, decides if he or she wants to book it. The closer the car and the lower the price of the rent, the greater is probability that user takes the car. If user decides to rent a car, the user first books it and walks to the car. Then, user decides whether the user wants to start rent. With probability 1%, user who booked a car will decide not to start paid rent for some reason (for example, the car is dirty). When user decides not to take a car or not to start paid rent, it is assumed that the user gets to the destination point by personal car or by public transport. In the end, user who decided to travel travels anyway, by car or without it. If user travels by car, the user leaves the car exactly at the destination point. Users have the following parameters:<br />
* travel - boolean parameter indicating if user is travelling at the moment<br />
* destination (''destinationx'' and ''destinationy'') - destination where user is travelling to (applicable only if ''travel = True'')<br />
* car_assigned - car which user uses for travelling, could be ''Nobody'' if user travel not using a carsharing car (applicable only if ''travel = True'').<br />
<br />
For every user, maximum acceptable time of walking to the car before booking is 20 minutes (2 km).<br />
<br />
===Maintainers===<br />
<br />
Represent employees of carsharing company who are responsible for maintenance of the cars. They have their own vehicles (not the agent cars) and identify the cars which need maintenance in the simulation space based on the car's parameter status. The identified car is marked as out of service until maintenance is over. It is assumed that as soon as maintainer reaches the car, maintenance is done and car is again ready for rent. Maintainers have the only parameter - car_assigned - indicating the car assigned to them for maintenance (could be ''Nobody'' if no car is assigned). There are only two conditions when a car can be marked as needed maintenance:<br />
* fuel level is below 2.5 liters (for this simulation, it is number close to amount of fuel needed to drive across the square simulation space diagonal)<br />
* car exceeded another 10,000 km and requires inspection.<br />
<br />
==Simplifications==<br />
<br />
Since the carsharing system is very complex, for the purpose of this simulation some simplifications were accepted.<br />
<br />
===Space===<br />
<br />
Space of the simulation is considered uniform, i.e., there is no roads, buildings, and traffic in the simulation space. It does not matter what roads the users will drive across and how much time they will spend in traffic. On the other hand, what matters is duration of rent, which for this simplification does not depend on the traffic. The city is assumed to be of a square size 20×20 km. The simulation field is set of size 100×100 patches, which means that every patch has height and width equal to 200 m (0.2 km).<br />
<br />
===Prices===<br />
<br />
In real life, carsharing companies often offer different plans. It is normally fixed price per minute (usually depending on current demand) and packages with different duration with or without included mileage (for example, 2 hours of rent with 20 km included with fixed price per minute and per km after exceeding the included amount of time and mileage). For this simulation, only fixed prices per minute are available. The reason is that, even though some carsharing providers offer a wide range of different packages and plans, in the end final price does not differ much for each of the package.<br />
<br />
===Cars===<br />
<br />
There are several simplifications related to the cars.<br />
* First, all of them have the same fuel consumption: 7.5 l per 100 km. It means that 1 liter of fuel will cover approximately 13.33 km.<br />
* Second, it is assumed that cars do not need any maintenance except for regular inspection every 10,000 km and re-fueling.<br />
* Third, only users can drive the cars. It is assumed that maintainers do no move the cars (which could happen in real life to adjust the car locations to expected demand) and perform inspection every 10,000 km at the place where the car is located at the moment<br />
* Finally, there are only 2 types of cars: regular and premium, they have totally identical characteristics, only price differs.<br />
<br />
===Users===<br />
<br />
All the users drive cars with the same speed, 40 km/h. All of them are very careful and never have any accidents. Users drive cars only from one point in the simulation space to another, they do not drive between several points and do not leave the rent on pending (in real life, for example, some people could take a car to go for groceries and back and leave the car parked in paid rent while shopping). Without a car, users walk with the speed of 6 km/h.<br />
<br />
==Revenue and expenditures==<br />
<br />
Since the goal of the simulation is to find optimal parameters to maximize marginal profit, a task of financial calculations appears. However, calculations in the simulations are very simple. For the purpose of this simulation, Czech crowns were used as currency for all the financial operations. There is only one way to increase revenue - by renting out the cars. There are several expenditures:<br />
* fuel price (added after every refueling, by default 30 CZK per liter)<br />
* inspection cost (added for each car every inspection, assumed to be equal to 15,000 CZK)<br />
* cost of maintenance, including salary of maintainers, fuel for maintainers' vehicles, and so on (by default 10 CZK per minute).<br />
<br />
Margin profit is calculated as revenue minus expenditures minus initial expenditures. Initial expenditures include the price of the cars. It is assumed that regular car price is 400,000 CZK and premium car price is 800,000 CZK.<br />
<br />
=Results=<br />
<br />
[[File:Demo.gif|200px|thumb|right|Renting of a car]]<br />
The simulation is designed in a way that number of cars, number of users, number of maintainers, number of premium cars, rental price for normal and premium cars, fuel price, and maintenance rate are adjustable.<br />
<br />
Unfortunately, it was not possible to get actual data from a real carsharing company operating in Prague. However, according to publicly available observations in the carsharing operator's application, ratio of cars available for rent is in average 70-80%. Similar results were obtained for 1,000 users and 200 cars (5 users per car).<br />
<br />
It is visible that the results are stable and fluctuations in numbers of cars of each status are within narrow boundaries. Thus, the simulation is considered to be developed well.<br />
<br />
Further in this section, different ratios of users per car considered, all the observations are listed. Since a tick of the simulation is counted as 1 minute of real time, in each case the observation period was set as one quarter (around 131,000 ticks).<br />
<br />
==Normal ratio==<br />
<br />
[[File:Car-statuses.jpeg|250px|thumb|left|Car statuses over time for normal ratio]]<br />
[[File:Normal-finances.jpeg|250px|thumb|right|Revenue and expenditure for normal ratio]]<br />
With normal ratio (5 users per car), results look fine, revenue exceeds expenditures twice. Return of investment may happen already in 3 years, which is okay. However, cost of maintenance starts growing faster closer to the end of the quarter since there are some delayed expenses such as planned inspections. However, this scenario looks good in general and will be used for comparison for the future cases.<br />
<br />
Another important observation here is that with 5 maintainers, almost no cars are in the maintenance state, which means that maintainers manage to work on the car as soon as it needs maintenance.<br />
<br />
==High number of cars==<br />
<br />
[[File:Car-statuses-high.jpeg|250px|thumb|left|Car statuses over time for high number of cars]]<br />
[[File:High-finances.jpeg|250px|thumb|right|Revenue and expenditure for high number of cars]]<br />
In this scenario, number of cars was increased to 1,000 (including 145 premium ones) and was equal to number of users. As a result, 85-90% of cars were in idle state all the time. But it positively affected<br />
profit: now revenue exceeds expenditures three times. Also, the curve of expenditures looks more stable: every car has less mileage and requires less investments. However, considering that initial investments are significantly higher, since number of cars is 5 times greater than in previous scenario, and return of investment would take almost 40 years. Also, for the period of one quarter with such number of cars, expenses on inspections and car replacements are not yet visible on the graph and will be higher (which means smaller gap between revenue and expenditures) in the future.<br />
<br />
Hence, it makes no sense to increase number of cars that much because margin profit in the end will be much worse than in case with 200 available cars.<br />
<br />
==Low number of cars==<br />
<br />
[[File:Car-statuses-low.jpeg|250px|thumb|left|Car statuses over time for low number of cars]]<br />
[[File:Low-finances.jpeg|250px|thumb|right|Revenue and expenditure for low number of cars]]<br />
For this simulation run, 40 cars were left including 12 premium ones. At the same time, it makes no sense to keep 5 maintainers for such a low number of cars and only 1 maintainer was kept. Because of low number of cars, statuses fluctuated more. However, number of idle cars still exceeds number of cars in rent: users are not eager to rent a car because it is mostly far away from them. Due to lower cost of maintenance, revenue is still almost twice greater than expenditures and, due to lower initial investments, return of investments will happen already in 1.5-2 years.<br />
<br />
==Extremes==<br />
<br />
Two extreme scenarios were also tried: 4 cars (including one premium) with 1 maintainer and 10,000 cars (including 1,450 premium ones) with 5 maintainers for 1,000 users. In the first run, revenue barely exceeded expenditures, return of investments would take decades. In the second run, until the end of the quarter, revenue value did not even reach the value of expenditure.<br />
<br />
[[File:Car-statuses-1-maintainer.jpeg|250px|thumb|left|Car statuses over time with only 1 maintainer]]<br />
<br />
==Optimization of the best scenario==<br />
<br />
Last runs of the simulation aimed to increase margin profit by decreasing number of maintainers and slightly increasing number of cars comparing to the best scenario (200 cars per 1,000 users). It turned out that even one maintainer is enough to perform routine maintenance of the fleet. Number of cars waiting for maintenance grew but the profit in the end increased. Graph of car statuses looks similar to what was shown before with a extra red ("need maintenance" status) cars. On the other hand, revenue now exceeds expenditures 2.5 times (comparing to 2 times with 5 maintainers). It means that return of investments may happen already in 1.5-2 years.<br />
<br />
At the same time, increase in number of cars from 200 to 250 (with 1 maintainer) kept the ratio revenue / expenditures at the same level increasing turnover. However, considering greater initial investments, return of investments would happen definitely not sooner than with 200 cars.<br />
<br />
=Conclusion=<br />
<br />
Two optimal sizes of fleet size were discovered:<br />
* few cars (about 25 users per one shared car) - due to relatively small initial investments and revenue significantly exceeding expenditures, return of investments for this scenario will be quite quick, in 1.5-2 years<br />
* ratio mostly used by currently operating services (about 5 users per one shared car) in combination with optimized maintenance costs - greater turnover and revenue, which is 2.5 times greater than expenditures, allows to achieve return of investments in the same 1.5-2 years.<br />
Therefore, new carsharing providers before running their business may choose either of the scenarios based on their abilities to get the initial investments. Already established companies may adjust their user-per-car ratio to the nearest one by either attracting new users or increasing the number of cars in the fleet.<br />
<br />
<br />
=Code=<br />
<br />
[[File:Carsharing.nlogo]]</div>Shcs00http://www.simulace.info/index.php?title=Carsharing_Fleet_Optimization&diff=22235Carsharing Fleet Optimization2021-12-20T15:52:38Z<p>Shcs00: /* Optimization of the best scenario */</p>
<hr />
<div>=Introduction=<br />
<br />
Recently, carsharing becomes more and more popular in large cities. Short-term rental (from several minutes to 24 hours) of a car with possibility to drop it anywhere in the allowed area in the city attracts people who, for some reason, do not want to use their own vehicles. However, it is not always convenient. If the fleet is relatively small, the probability that a car will be somewhere close by is also quite low. Cars also must be refueled or recharged sometimes by staff, which would increase cost of the fleet maintenance with increasing of the fleet size.<br />
<br />
=Problem definition=<br />
<br />
Carsharing companies have to solve a problem of optimization of their fleet size, which is not simple. The entire system of carsharing is complex and has many different parameters that must be considered for decision making. For example, if the number of cars available in the city is relatively small the maintenance is also respectively inexpensive. However, in this case, the probability that users can find a car next to their location drops drastically. On the other hand, having too many cars leads to the risk that they will stay with no use for long time. The goal of this simulation is to understand how the carsharing system behaves and propose quantitative solution on optimal number of cars and price of rent to maximize marginal profit of a hypothetical carsharing company.<br />
<br />
=Method=<br />
<br />
Since the system consists of several entities, each of them is able to some extent to make decisions, and system itself is dynamic and requires to take into account spatial factors, agent-based modelling was chosen as the most appropriate tool to design the simulation. Implementation was performed using NetLogo software platform.<br />
<br />
=Model=<br />
<br />
The model is represented by several agents and accepts some simplifications. It is assumed that the simulation will be run on ticks, every tick represents one minute of real time.<br />
<br />
==Agents==<br />
<br />
The model contains 3 types of agents: cars, users, and maintainers.<br />
<br />
===Cars===<br />
<br />
Represent the vehicles used for short-term rentals. Cars have the following characteristics:<br />
* price - cost of rental per minute<br />
* status - current status of the vehicle, can be ''idle'' (the car is ready for rent), ''booked'' (the car is booked but paid rent has not started yet), ''in rent'' (the car is taken in paid rent by some user, for the purpose of this simulation it means that the car is moving), ''needs maintenance'' (the car is not visible for users but visible for maintainers), and ''out of service'' (the car is not visible for users and maintainers, is already under maintenance by one of the maintainers)<br />
* fuel - how many liters of gas is left<br />
* mileage - for how many kilometres the car was already driven, every car must go through maintenance procedure every 10,000 kilometres<br />
* premium - boolean parameter that indicates if the car belongs to premium class<br />
* inspection - boolean parameter indicating that the car needs to undergo an inspection.<br />
<br />
Cars are located in the simulation space and, if possible, can be rented by users. Users can drive cars, i.e., move it from one point of the simulation space to another. Cars can be re-fueled and taken to inspection by maintainers. It is assumed that a car can serve for the purpose of carsharing only for 100,000 km, then the car is replaced with absolutely identical one.<br />
<br />
===Users===<br />
<br />
Represent people holding a driving license, registered in the carsharing service and actively using it. Every tick of the simulation users decide with probability 1% whether they want to travel from the current location to somewhere else and, if so, to what coordinates of the simulation space. However, there are peak hours when most of users want to travel (for example, commute to work). It is assumed that there are 3 such hours every workday, 15 hours during the week, i.e. 9% of all the time. During these hours 50% users want to travel somewhere.<br />
<br />
Then, user starts looking for a car and, if the user finds one near by, decides if he or she wants to book it. The closer the car and the lower the price of the rent, the greater is probability that user takes the car. If user decides to rent a car, the user first books it and walks to the car. Then, user decides whether the user wants to start rent. With probability 1%, user who booked a car will decide not to start paid rent for some reason (for example, the car is dirty). When user decides not to take a car or not to start paid rent, it is assumed that the user gets to the destination point by personal car or by public transport. In the end, user who decided to travel travels anyway, by car or without it. If user travels by car, the user leaves the car exactly at the destination point. Users have the following parameters:<br />
* travel - boolean parameter indicating if user is travelling at the moment<br />
* destination (''destinationx'' and ''destinationy'') - destination where user is travelling to (applicable only if ''travel = True'')<br />
* car_assigned - car which user uses for travelling, could be ''Nobody'' if user travel not using a carsharing car (applicable only if ''travel = True'').<br />
<br />
For every user, maximum acceptable time of walking to the car before booking is 20 minutes (2 km).<br />
<br />
===Maintainers===<br />
<br />
Represent employees of carsharing company who are responsible for maintenance of the cars. They have their own vehicles (not the agent cars) and identify the cars which need maintenance in the simulation space based on the car's parameter status. The identified car is marked as out of service until maintenance is over. It is assumed that as soon as maintainer reaches the car, maintenance is done and car is again ready for rent. Maintainers have the only parameter - car_assigned - indicating the car assigned to them for maintenance (could be ''Nobody'' if no car is assigned). There are only two conditions when a car can be marked as needed maintenance:<br />
* fuel level is below 2.5 liters (for this simulation, it is number close to amount of fuel needed to drive across the square simulation space diagonal)<br />
* car exceeded another 10,000 km and requires inspection.<br />
<br />
==Simplifications==<br />
<br />
Since the carsharing system is very complex, for the purpose of this simulation some simplifications were accepted.<br />
<br />
===Space===<br />
<br />
Space of the simulation is considered uniform, i.e., there is no roads, buildings, and traffic in the simulation space. It does not matter what roads the users will drive across and how much time they will spend in traffic. On the other hand, what matters is duration of rent, which for this simplification does not depend on the traffic. The city is assumed to be of a square size 20×20 km. The simulation field is set of size 100×100 patches, which means that every patch has height and width equal to 200 m (0.2 km).<br />
<br />
===Prices===<br />
<br />
In real life, carsharing companies often offer different plans. It is normally fixed price per minute (usually depending on current demand) and packages with different duration with or without included mileage (for example, 2 hours of rent with 20 km included with fixed price per minute and per km after exceeding the included amount of time and mileage). For this simulation, only fixed prices per minute are available. The reason is that, even though some carsharing providers offer a wide range of different packages and plans, in the end final price does not differ much for each of the package.<br />
<br />
===Cars===<br />
<br />
There are several simplifications related to the cars.<br />
* First, all of them have the same fuel consumption: 7.5 l per 100 km. It means that 1 liter of fuel will cover approximately 13.33 km.<br />
* Second, it is assumed that cars do not need any maintenance except for regular inspection every 10,000 km and re-fueling.<br />
* Third, only users can drive the cars. It is assumed that maintainers do no move the cars (which could happen in real life to adjust the car locations to expected demand) and perform inspection every 10,000 km at the place where the car is located at the moment<br />
* Finally, there are only 2 types of cars: regular and premium, they have totally identical characteristics, only price differs.<br />
<br />
===Users===<br />
<br />
All the users drive cars with the same speed, 40 km/h. All of them are very careful and never have any accidents. Users drive cars only from one point in the simulation space to another, they do not drive between several points and do not leave the rent on pending (in real life, for example, some people could take a car to go for groceries and back and leave the car parked in paid rent while shopping). Without a car, users walk with the speed of 6 km/h.<br />
<br />
==Revenue and expenditures==<br />
<br />
Since the goal of the simulation is to find optimal parameters to maximize marginal profit, a task of financial calculations appears. However, calculations in the simulations are very simple. For the purpose of this simulation, Czech crowns were used as currency for all the financial operations. There is only one way to increase revenue - by renting out the cars. There are several expenditures:<br />
* fuel price (added after every refueling, by default 30 CZK per liter)<br />
* inspection cost (added for each car every inspection, assumed to be equal to 15,000 CZK)<br />
* cost of maintenance, including salary of maintainers, fuel for maintainers' vehicles, and so on (by default 10 CZK per minute).<br />
<br />
Margin profit is calculated as revenue minus expenditures minus initial expenditures. Initial expenditures include the price of the cars. It is assumed that regular car price is 400,000 CZK and premium car price is 800,000 CZK.<br />
<br />
=Results=<br />
<br />
[[File:Demo.gif|200px|thumb|right|Renting of a car]]<br />
The simulation is designed in a way that number of cars, number of users, number of maintainers, number of premium cars, rental price for normal and premium cars, fuel price, and maintenance rate are adjustable.<br />
<br />
Unfortunately, it was not possible to get actual data from a real carsharing company operating in Prague. However, according to publicly available observations in the carsharing operator's application, ratio of cars available for rent is in average 70-80%. Similar results were obtained for 1,000 users and 200 cars (5 users per car).<br />
<br />
It is visible that the results are stable and fluctuations in numbers of cars of each status are within narrow boundaries. Thus, the simulation is considered to be developed well.<br />
<br />
Further in this section, different ratios of users per car considered, all the observations are listed. Since a tick of the simulation is counted as 1 minute of real time, in each case the observation period was set as one quarter (around 131,000 ticks).<br />
<br />
==Normal ratio==<br />
<br />
[[File:Car-statuses.jpeg|250px|thumb|left|Car statuses over time for normal ratio]]<br />
[[File:Normal-finances.jpeg|250px|thumb|right|Revenue and expenditure for normal ratio]]<br />
With normal ratio (5 users per car), results look fine, revenue exceeds expenditures twice. Return of investment may happen already in 3 years, which is okay. However, cost of maintenance starts growing faster closer to the end of the quarter since there are some delayed expenses such as planned inspections. However, this scenario looks good in general and will be used for comparison for the future cases.<br />
<br />
Another important observation here is that with 5 maintainers, almost no cars are in the maintenance state, which means that maintainers manage to work on the car as soon as it needs maintenance.<br />
<br />
==High number of cars==<br />
<br />
[[File:Car-statuses-high.jpeg|250px|thumb|left|Car statuses over time for high number of cars]]<br />
[[File:High-finances.jpeg|250px|thumb|right|Revenue and expenditure for high number of cars]]<br />
In this scenario, number of cars was increased to 1,000 (including 145 premium ones) and was equal to number of users. As a result, 85-90% of cars were in idle state all the time. But it positively affected<br />
profit: now revenue exceeds expenditures three times. Also, the curve of expenditures looks more stable: every car has less mileage and requires less investments. However, considering that initial investments are significantly higher, since number of cars is 5 times greater than in previous scenario, and return of investment would take almost 40 years. Also, for the period of one quarter with such number of cars, expenses on inspections and car replacements are not yet visible on the graph and will be higher (which means smaller gap between revenue and expenditures) in the future.<br />
<br />
Hence, it makes no sense to increase number of cars that much because margin profit in the end will be much worse than in case with 200 available cars.<br />
<br />
==Low number of cars==<br />
<br />
[[File:Car-statuses-low.jpeg|250px|thumb|left|Car statuses over time for low number of cars]]<br />
[[File:Low-finances.jpeg|250px|thumb|right|Revenue and expenditure for low number of cars]]<br />
For this simulation run, 40 cars were left including 12 premium ones. At the same time, it makes no sense to keep 5 maintainers for such a low number of cars and only 1 maintainer was kept. Because of low number of cars, statuses fluctuated more. However, number of idle cars still exceeds number of cars in rent: users are not eager to rent a car because it is mostly far away from them. Due to lower cost of maintenance, revenue is still almost twice greater than expenditures and, due to lower initial investments, return of investments will happen already in 1.5-2 years.<br />
<br />
==Extremes==<br />
<br />
Two extreme scenarios were also tried: 4 cars (including one premium) with 1 maintainer and 10,000 cars (including 1,450 premium ones) with 5 maintainers for 1,000 users. In the first run, revenue barely exceeded expenditures, return of investments would take decades. In the second run, until the end of the quarter, revenue value did not even reach the value of expenditure.<br />
<br />
==Optimization of the best scenario==<br />
<br />
[[File:Car-statuses-1-maintainer.jpeg|250px|thumb|left|Car statuses over time with only 1 maintainer]]<br />
Last runs of the simulation aimed to increase margin profit by decreasing number of maintainers and slightly increasing number of cars comparing to the best scenario (200 cars per 1,000 users). It turned out that even one maintainer is enough to perform routine maintenance of the fleet. Number of cars waiting for maintenance grew but the profit in the end increased. Graph of car statuses looks similar to what was shown before with a extra red ("need maintenance" status) cars. On the other hand, revenue now exceeds expenditures 2.5 times (comparing to 2 times with 5 maintainers). It means that return of investments may happen already in 1.5-2 years.<br />
<br />
At the same time, increase in number of cars from 200 to 250 (with 1 maintainer) kept the ratio revenue / expenditures at the same level increasing turnover. However, considering greater initial investments, return of investments would happen definitely not sooner than with 200 cars.<br />
<br />
=Conclusion=<br />
<br />
Two optimal sizes of fleet size were discovered:<br />
* few cars (about 25 users per one shared car) - due to relatively small initial investments and revenue significantly exceeding expenditures, return of investments for this scenario will be quite quick, in 1.5-2 years<br />
* ratio mostly used by currently operating services (about 5 users per one shared car) in combination with optimized maintenance costs - greater turnover and revenue, which is 2.5 times greater than expenditures, allows to achieve return of investments in the same 1.5-2 years.<br />
Therefore, new carsharing providers before running their business may choose either of the scenarios based on their abilities to get the initial investments. Already established companies may adjust their user-per-car ratio to the nearest one by either attracting new users or increasing the number of cars in the fleet.<br />
<br />
<br />
=Code=<br />
<br />
[[File:Carsharing.nlogo]]</div>Shcs00http://www.simulace.info/index.php?title=Carsharing_Fleet_Optimization&diff=22234Carsharing Fleet Optimization2021-12-20T15:51:58Z<p>Shcs00: </p>
<hr />
<div>=Introduction=<br />
<br />
Recently, carsharing becomes more and more popular in large cities. Short-term rental (from several minutes to 24 hours) of a car with possibility to drop it anywhere in the allowed area in the city attracts people who, for some reason, do not want to use their own vehicles. However, it is not always convenient. If the fleet is relatively small, the probability that a car will be somewhere close by is also quite low. Cars also must be refueled or recharged sometimes by staff, which would increase cost of the fleet maintenance with increasing of the fleet size.<br />
<br />
=Problem definition=<br />
<br />
Carsharing companies have to solve a problem of optimization of their fleet size, which is not simple. The entire system of carsharing is complex and has many different parameters that must be considered for decision making. For example, if the number of cars available in the city is relatively small the maintenance is also respectively inexpensive. However, in this case, the probability that users can find a car next to their location drops drastically. On the other hand, having too many cars leads to the risk that they will stay with no use for long time. The goal of this simulation is to understand how the carsharing system behaves and propose quantitative solution on optimal number of cars and price of rent to maximize marginal profit of a hypothetical carsharing company.<br />
<br />
=Method=<br />
<br />
Since the system consists of several entities, each of them is able to some extent to make decisions, and system itself is dynamic and requires to take into account spatial factors, agent-based modelling was chosen as the most appropriate tool to design the simulation. Implementation was performed using NetLogo software platform.<br />
<br />
=Model=<br />
<br />
The model is represented by several agents and accepts some simplifications. It is assumed that the simulation will be run on ticks, every tick represents one minute of real time.<br />
<br />
==Agents==<br />
<br />
The model contains 3 types of agents: cars, users, and maintainers.<br />
<br />
===Cars===<br />
<br />
Represent the vehicles used for short-term rentals. Cars have the following characteristics:<br />
* price - cost of rental per minute<br />
* status - current status of the vehicle, can be ''idle'' (the car is ready for rent), ''booked'' (the car is booked but paid rent has not started yet), ''in rent'' (the car is taken in paid rent by some user, for the purpose of this simulation it means that the car is moving), ''needs maintenance'' (the car is not visible for users but visible for maintainers), and ''out of service'' (the car is not visible for users and maintainers, is already under maintenance by one of the maintainers)<br />
* fuel - how many liters of gas is left<br />
* mileage - for how many kilometres the car was already driven, every car must go through maintenance procedure every 10,000 kilometres<br />
* premium - boolean parameter that indicates if the car belongs to premium class<br />
* inspection - boolean parameter indicating that the car needs to undergo an inspection.<br />
<br />
Cars are located in the simulation space and, if possible, can be rented by users. Users can drive cars, i.e., move it from one point of the simulation space to another. Cars can be re-fueled and taken to inspection by maintainers. It is assumed that a car can serve for the purpose of carsharing only for 100,000 km, then the car is replaced with absolutely identical one.<br />
<br />
===Users===<br />
<br />
Represent people holding a driving license, registered in the carsharing service and actively using it. Every tick of the simulation users decide with probability 1% whether they want to travel from the current location to somewhere else and, if so, to what coordinates of the simulation space. However, there are peak hours when most of users want to travel (for example, commute to work). It is assumed that there are 3 such hours every workday, 15 hours during the week, i.e. 9% of all the time. During these hours 50% users want to travel somewhere.<br />
<br />
Then, user starts looking for a car and, if the user finds one near by, decides if he or she wants to book it. The closer the car and the lower the price of the rent, the greater is probability that user takes the car. If user decides to rent a car, the user first books it and walks to the car. Then, user decides whether the user wants to start rent. With probability 1%, user who booked a car will decide not to start paid rent for some reason (for example, the car is dirty). When user decides not to take a car or not to start paid rent, it is assumed that the user gets to the destination point by personal car or by public transport. In the end, user who decided to travel travels anyway, by car or without it. If user travels by car, the user leaves the car exactly at the destination point. Users have the following parameters:<br />
* travel - boolean parameter indicating if user is travelling at the moment<br />
* destination (''destinationx'' and ''destinationy'') - destination where user is travelling to (applicable only if ''travel = True'')<br />
* car_assigned - car which user uses for travelling, could be ''Nobody'' if user travel not using a carsharing car (applicable only if ''travel = True'').<br />
<br />
For every user, maximum acceptable time of walking to the car before booking is 20 minutes (2 km).<br />
<br />
===Maintainers===<br />
<br />
Represent employees of carsharing company who are responsible for maintenance of the cars. They have their own vehicles (not the agent cars) and identify the cars which need maintenance in the simulation space based on the car's parameter status. The identified car is marked as out of service until maintenance is over. It is assumed that as soon as maintainer reaches the car, maintenance is done and car is again ready for rent. Maintainers have the only parameter - car_assigned - indicating the car assigned to them for maintenance (could be ''Nobody'' if no car is assigned). There are only two conditions when a car can be marked as needed maintenance:<br />
* fuel level is below 2.5 liters (for this simulation, it is number close to amount of fuel needed to drive across the square simulation space diagonal)<br />
* car exceeded another 10,000 km and requires inspection.<br />
<br />
==Simplifications==<br />
<br />
Since the carsharing system is very complex, for the purpose of this simulation some simplifications were accepted.<br />
<br />
===Space===<br />
<br />
Space of the simulation is considered uniform, i.e., there is no roads, buildings, and traffic in the simulation space. It does not matter what roads the users will drive across and how much time they will spend in traffic. On the other hand, what matters is duration of rent, which for this simplification does not depend on the traffic. The city is assumed to be of a square size 20×20 km. The simulation field is set of size 100×100 patches, which means that every patch has height and width equal to 200 m (0.2 km).<br />
<br />
===Prices===<br />
<br />
In real life, carsharing companies often offer different plans. It is normally fixed price per minute (usually depending on current demand) and packages with different duration with or without included mileage (for example, 2 hours of rent with 20 km included with fixed price per minute and per km after exceeding the included amount of time and mileage). For this simulation, only fixed prices per minute are available. The reason is that, even though some carsharing providers offer a wide range of different packages and plans, in the end final price does not differ much for each of the package.<br />
<br />
===Cars===<br />
<br />
There are several simplifications related to the cars.<br />
* First, all of them have the same fuel consumption: 7.5 l per 100 km. It means that 1 liter of fuel will cover approximately 13.33 km.<br />
* Second, it is assumed that cars do not need any maintenance except for regular inspection every 10,000 km and re-fueling.<br />
* Third, only users can drive the cars. It is assumed that maintainers do no move the cars (which could happen in real life to adjust the car locations to expected demand) and perform inspection every 10,000 km at the place where the car is located at the moment<br />
* Finally, there are only 2 types of cars: regular and premium, they have totally identical characteristics, only price differs.<br />
<br />
===Users===<br />
<br />
All the users drive cars with the same speed, 40 km/h. All of them are very careful and never have any accidents. Users drive cars only from one point in the simulation space to another, they do not drive between several points and do not leave the rent on pending (in real life, for example, some people could take a car to go for groceries and back and leave the car parked in paid rent while shopping). Without a car, users walk with the speed of 6 km/h.<br />
<br />
==Revenue and expenditures==<br />
<br />
Since the goal of the simulation is to find optimal parameters to maximize marginal profit, a task of financial calculations appears. However, calculations in the simulations are very simple. For the purpose of this simulation, Czech crowns were used as currency for all the financial operations. There is only one way to increase revenue - by renting out the cars. There are several expenditures:<br />
* fuel price (added after every refueling, by default 30 CZK per liter)<br />
* inspection cost (added for each car every inspection, assumed to be equal to 15,000 CZK)<br />
* cost of maintenance, including salary of maintainers, fuel for maintainers' vehicles, and so on (by default 10 CZK per minute).<br />
<br />
Margin profit is calculated as revenue minus expenditures minus initial expenditures. Initial expenditures include the price of the cars. It is assumed that regular car price is 400,000 CZK and premium car price is 800,000 CZK.<br />
<br />
=Results=<br />
<br />
[[File:Demo.gif|200px|thumb|right|Renting of a car]]<br />
The simulation is designed in a way that number of cars, number of users, number of maintainers, number of premium cars, rental price for normal and premium cars, fuel price, and maintenance rate are adjustable.<br />
<br />
Unfortunately, it was not possible to get actual data from a real carsharing company operating in Prague. However, according to publicly available observations in the carsharing operator's application, ratio of cars available for rent is in average 70-80%. Similar results were obtained for 1,000 users and 200 cars (5 users per car).<br />
<br />
It is visible that the results are stable and fluctuations in numbers of cars of each status are within narrow boundaries. Thus, the simulation is considered to be developed well.<br />
<br />
Further in this section, different ratios of users per car considered, all the observations are listed. Since a tick of the simulation is counted as 1 minute of real time, in each case the observation period was set as one quarter (around 131,000 ticks).<br />
<br />
==Normal ratio==<br />
<br />
[[File:Car-statuses.jpeg|250px|thumb|left|Car statuses over time for normal ratio]]<br />
[[File:Normal-finances.jpeg|250px|thumb|right|Revenue and expenditure for normal ratio]]<br />
With normal ratio (5 users per car), results look fine, revenue exceeds expenditures twice. Return of investment may happen already in 3 years, which is okay. However, cost of maintenance starts growing faster closer to the end of the quarter since there are some delayed expenses such as planned inspections. However, this scenario looks good in general and will be used for comparison for the future cases.<br />
<br />
Another important observation here is that with 5 maintainers, almost no cars are in the maintenance state, which means that maintainers manage to work on the car as soon as it needs maintenance.<br />
<br />
==High number of cars==<br />
<br />
[[File:Car-statuses-high.jpeg|250px|thumb|left|Car statuses over time for high number of cars]]<br />
[[File:High-finances.jpeg|250px|thumb|right|Revenue and expenditure for high number of cars]]<br />
In this scenario, number of cars was increased to 1,000 (including 145 premium ones) and was equal to number of users. As a result, 85-90% of cars were in idle state all the time. But it positively affected<br />
profit: now revenue exceeds expenditures three times. Also, the curve of expenditures looks more stable: every car has less mileage and requires less investments. However, considering that initial investments are significantly higher, since number of cars is 5 times greater than in previous scenario, and return of investment would take almost 40 years. Also, for the period of one quarter with such number of cars, expenses on inspections and car replacements are not yet visible on the graph and will be higher (which means smaller gap between revenue and expenditures) in the future.<br />
<br />
Hence, it makes no sense to increase number of cars that much because margin profit in the end will be much worse than in case with 200 available cars.<br />
<br />
==Low number of cars==<br />
<br />
[[File:Car-statuses-low.jpeg|250px|thumb|left|Car statuses over time for low number of cars]]<br />
[[File:Low-finances.jpeg|250px|thumb|right|Revenue and expenditure for low number of cars]]<br />
For this simulation run, 40 cars were left including 12 premium ones. At the same time, it makes no sense to keep 5 maintainers for such a low number of cars and only 1 maintainer was kept. Because of low number of cars, statuses fluctuated more. However, number of idle cars still exceeds number of cars in rent: users are not eager to rent a car because it is mostly far away from them. Due to lower cost of maintenance, revenue is still almost twice greater than expenditures and, due to lower initial investments, return of investments will happen already in 1.5-2 years.<br />
<br />
==Extremes==<br />
<br />
Two extreme scenarios were also tried: 4 cars (including one premium) with 1 maintainer and 10,000 cars (including 1,450 premium ones) with 5 maintainers for 1,000 users. In the first run, revenue barely exceeded expenditures, return of investments would take decades. In the second run, until the end of the quarter, revenue value did not even reach the value of expenditure.<br />
<br />
==Optimization of the best scenario==<br />
<br />
[[File:Car-statuses-1-maintainer.jpeg|250px|thumb|left|Car statuses over time with only 1 maintainer]]<br />
Last runs aimed to increase margin profit by decreasing number of maintainers and slightly increasing number of cars comparing to the best scenario (200 cars per 1,000 users). It turned out that even one maintainer is enough to perform routine maintenance of the fleet. Number of cars waiting for maintenance grew but the profit in the end increased. Graph of car statuses looks similar to what was shown before with a extra red ("need maintenance" status) cars. On the other hand, revenue now exceeds expenditures 2.5 times (comparing to 2 times with 5 maintainers). It means that return of investments may happen already in 1.5-2 years.<br />
<br />
At the same time, increase in number of cars from 200 to 250 (with 1 maintainer) kept the ratio revenue / expenditures at the same level increasing turnover. However, considering greater initial investments, return of investments would happen definitely not sooner than with 200 cars.<br />
<br />
=Conclusion=<br />
<br />
Two optimal sizes of fleet size were discovered:<br />
* few cars (about 25 users per one shared car) - due to relatively small initial investments and revenue significantly exceeding expenditures, return of investments for this scenario will be quite quick, in 1.5-2 years<br />
* ratio mostly used by currently operating services (about 5 users per one shared car) in combination with optimized maintenance costs - greater turnover and revenue, which is 2.5 times greater than expenditures, allows to achieve return of investments in the same 1.5-2 years.<br />
Therefore, new carsharing providers before running their business may choose either of the scenarios based on their abilities to get the initial investments. Already established companies may adjust their user-per-car ratio to the nearest one by either attracting new users or increasing the number of cars in the fleet.<br />
<br />
<br />
=Code=<br />
<br />
[[File:Carsharing.nlogo]]</div>Shcs00http://www.simulace.info/index.php?title=Carsharing_Fleet_Optimization&diff=22233Carsharing Fleet Optimization2021-12-20T15:39:34Z<p>Shcs00: /* Code */</p>
<hr />
<div>=Introduction=<br />
<br />
Recently, carsharing becomes more and more popular in large cities. Short-term rental (from several minutes to 24 hours) of a car with possibility to drop it anywhere in the allowed area in the city attracts people who, for some reason, do not want to use their own vehicles. However, it is not always convenient. If the fleet is relatively small, the probability that a car will be somewhere close by is also quite low. Cars also must be refueled or recharged sometimes by staff, which would increase cost of the fleet maintenance with increasing of the fleet size.<br />
<br />
=Problem definition=<br />
<br />
Carsharing companies have to solve a problem of optimization of their fleet size, which is not simple. The entire system of carsharing is complex and has many different parameters that must be considered for decision making. For example, if the number of cars available in the city is relatively small the maintenance is also respectively inexpensive. However, in this case, the probability that users can find a car next to their location drops drastically. On the other hand, having too many cars leads to the risk that they will stay with no use for long time. The goal of this simulation is to understand how the carsharing system behaves and propose quantitative solution on optimal number of cars and price of rent to maximize marginal profit of a hypothetical carsharing company.<br />
<br />
=Method=<br />
<br />
Since the system consists of several entities, each of them is able to some extent to make decisions, and system itself is dynamic and requires to take into account spatial factors, agent-based modelling was chosen as the most appropriate tool to design the simulation. Implementation was performed using NetLogo software platform.<br />
<br />
=Model=<br />
<br />
The model is represented by several agents and accepts some simplifications. It is assumed that the simulation will be run on ticks, every tick represents one minute of real time.<br />
<br />
==Agents==<br />
<br />
The model contains 3 types of agents: cars, users, and maintainers.<br />
<br />
===Cars===<br />
<br />
Represent the vehicles used for short-term rentals. Cars have the following characteristics:<br />
* price - cost of rental per minute<br />
* status - current status of the vehicle, can be ''idle'' (the car is ready for rent), ''booked'' (the car is booked but paid rent has not started yet), ''in rent'' (the car is taken in paid rent by some user, for the purpose of this simulation it means that the car is moving), ''needs maintenance'' (the car is not visible for users but visible for maintainers), and ''out of service'' (the car is not visible for users and maintainers, is already under maintenance by one of the maintainers)<br />
* fuel - how many liters of gas is left<br />
* mileage - for how many kilometres the car was already driven, every car must go through maintenance procedure every 10,000 kilometres<br />
* premium - boolean parameter that indicates if the car belongs to premium class<br />
* inspection - boolean parameter indicating that the car needs to undergo an inspection.<br />
<br />
Cars are located in the simulation space and, if possible, can be rented by users. Users can drive cars, i.e., move it from one point of the simulation space to another. Cars can be re-fueled and taken to inspection by maintainers. It is assumed that a car can serve for the purpose of carsharing only for 100,000 km, then the car is replaced with absolutely identical one.<br />
<br />
===Users===<br />
<br />
Represent people holding a driving license, registered in the carsharing service and actively using it. Every tick of the simulation users decide with probability 1% whether they want to travel from the current location to somewhere else and, if so, to what coordinates of the simulation space. However, there are peak hours when most of users want to travel (for example, commute to work). It is assumed that there are 3 such hours every workday, 15 hours during the week, i.e. 9% of all the time. During these hours 50% users want to travel somewhere.<br />
<br />
Then, user starts looking for a car and, if the user finds one near by, decides if he or she wants to book it. The closer the car and the lower the price of the rent, the greater is probability that user takes the car. If user decides to rent a car, the user first books it and walks to the car. Then, user decides whether the user wants to start rent. With probability 1%, user who booked a car will decide not to start paid rent for some reason (for example, the car is dirty). When user decides not to take a car or not to start paid rent, it is assumed that the user gets to the destination point by personal car or by public transport. In the end, user who decided to travel travels anyway, by car or without it. If user travels by car, the user leaves the car exactly at the destination point. Users have the following parameters:<br />
* travel - boolean parameter indicating if user is travelling at the moment<br />
* destination (''destinationx'' and ''destinationy'') - destination where user is travelling to (applicable only if ''travel = True'')<br />
* car_assigned - car which user uses for travelling, could be ''Nobody'' if user travel not using a carsharing car (applicable only if ''travel = True'').<br />
<br />
For every user, maximum acceptable time of walking to the car before booking is 20 minutes (2 km).<br />
<br />
===Maintainers===<br />
<br />
Represent employees of carsharing company who are responsible for maintenance of the cars. They have their own vehicles (not the agent cars) and identify the cars which need maintenance in the simulation space based on the car's parameter status. The identified car is marked as out of service until maintenance is over. It is assumed that as soon as maintainer reaches the car, maintenance is done and car is again ready for rent. Maintainers have the only parameter - car_assigned - indicating the car assigned to them for maintenance (could be ''Nobody'' if no car is assigned). There are only two conditions when a car can be marked as needed maintenance:<br />
* fuel level is below 2.5 liters (for this simulation, it is number close to amount of fuel needed to drive across the square simulation space diagonal)<br />
* car exceeded another 10,000 km and requires inspection.<br />
<br />
==Simplifications==<br />
<br />
Since the carsharing system is very complex, for the purpose of this simulation some simplifications were accepted.<br />
<br />
===Space===<br />
<br />
Space of the simulation is considered uniform, i.e., there is no roads, buildings, and traffic in the simulation space. It does not matter what roads the users will drive across and how much time they will spend in traffic. On the other hand, what matters is duration of rent, which for this simplification does not depend on the traffic. The city is assumed to be of a square size 20×20 km. The simulation field is set of size 100×100 patches, which means that every patch has height and width equal to 200 m (0.2 km).<br />
<br />
===Prices===<br />
<br />
In real life, carsharing companies often offer different plans. It is normally fixed price per minute (usually depending on current demand) and packages with different duration with or without included mileage (for example, 2 hours of rent with 20 km included with fixed price per minute and per km after exceeding the included amount of time and mileage). For this simulation, only fixed prices per minute are available. The reason is that, even though some carsharing providers offer a wide range of different packages and plans, in the end final price does not differ much for each of the package.<br />
<br />
===Cars===<br />
<br />
There are several simplifications related to the cars.<br />
* First, all of them have the same fuel consumption: 7.5 l per 100 km. It means that 1 liter of fuel will cover approximately 13.33 km.<br />
* Second, it is assumed that cars do not need any maintenance except for regular inspection every 10,000 km and re-fueling.<br />
* Third, only users can drive the cars. It is assumed that maintainers do no move the cars (which could happen in real life to adjust the car locations to expected demand) and perform inspection every 10,000 km at the place where the car is located at the moment<br />
* Finally, there are only 2 types of cars: regular and premium, they have totally identical characteristics, only price differs.<br />
<br />
===Users===<br />
<br />
All the users drive cars with the same speed, 40 km/h. All of them are very careful and never have any accidents. Users drive cars only from one point in the simulation space to another, they do not drive between several points and do not leave the rent on pending (in real life, for example, some people could take a car to go for groceries and back and leave the car parked in paid rent while shopping). Without a car, users walk with the speed of 6 km/h.<br />
<br />
==Revenue and expenditures==<br />
<br />
Since the goal of the simulation is to find optimal parameters to maximize marginal profit, a task of financial calculations appears. However, calculations in the simulations are very simple. For the purpose of this simulation, Czech crowns were used as currency for all the financial operations. There is only one way to increase revenue - by renting out the cars. There are several expenditures:<br />
* fuel price (added after every refueling, by default 30 CZK per liter)<br />
* inspection cost (added for each car every inspection, assumed to be equal to 15,000 CZK)<br />
* cost of maintenance, including salary of maintainers, fuel for maintainers' vehicles, and so on (by default 10 CZK per minute).<br />
<br />
Margin profit is calculated as revenue minus expenditures minus initial expenditures. Initial expenditures include the price of the cars. It is assumed that regular car price is 400,000 CZK and premium car price is 800,000 CZK.<br />
<br />
=Results=<br />
<br />
[[File:Demo.gif|200px|thumb|right|Renting of a car]]<br />
The simulation is designed in a way that number of cars, number of users, number of maintainers, number of premium cars, rental price for normal and premium cars, fuel price, and maintenance rate are adjustable.<br />
<br />
Unfortunately, it was not possible to get actual data from a real carsharing company operating in Prague. However, according to publicly available observations in the carsharing operator's application, ratio of cars available for rent is in average 70-80%. Similar results were obtained for 1,000 users and 200 cars (5 users per car).<br />
<br />
It is visible that the results are stable and fluctuations in numbers of cars of each status are within narrow boundaries. Thus, the simulation is considered to be developed well.<br />
<br />
Further in this section, different ratios of users per car considered, all the observations are listed. Since a tick of the simulation is counted as 1 minute of real time, in each case the observation period was set as one quarter (around 131,000 ticks).<br />
<br />
==Normal ratio==<br />
<br />
[[File:Car-statuses.jpeg|250px|thumb|left|Car statuses over time for normal ratio]]<br />
[[File:Normal-finances.jpeg|250px|thumb|right|Revenue and expenditure for normal ratio]]<br />
With normal ratio (5 users per car), results look fine, revenue exceeds expenditures twice. Return of investment may happen already in 3 years, which is okay. However, cost of maintenance starts growing faster closer to the end of the quarter since there are some delayed expenses such as planned inspections. However, this scenario looks good in general and will be used for comparison for the future cases.<br />
<br />
Another important observation here is that with 5 maintainers, almost no cars are in the maintenance state, which means that maintainers manage to work on the car as soon as it needs maintenance.<br />
<br />
==High number of cars==<br />
<br />
[[File:Car-statuses-high.jpeg|250px|thumb|left|Car statuses over time for high number of cars]]<br />
[[File:High-finances.jpeg|250px|thumb|right|Revenue and expenditure for high number of cars]]<br />
In this scenario, number of cars was increased to 1,000 (including 145 premium ones) and was equal to number of users. As a result, 85-90% of cars were in idle state all the time. But it positively affected<br />
profit: now revenue exceeds expenditures three times. Also, the curve of expenditures looks more stable: every car has less mileage and requires less investments. However, considering that initial investments are significantly higher, since number of cars is 5 times greater than in previous scenario, and return of investment would take almost 40 years. Also, for the period of one quarter with such number of cars, expenses on inspections and car replacements are not yet visible on the graph and will be higher (which means smaller gap between revenue and expenditures) in the future.<br />
<br />
Hence, it makes no sense to increase number of cars that much because margin profit in the end will be much worse than in case with 200 available cars.<br />
<br />
==Low number of cars==<br />
<br />
[[File:Car-statuses-low.jpeg|250px|thumb|left|Car statuses over time for low number of cars]]<br />
[[File:Low-finances.jpeg|250px|thumb|right|Revenue and expenditure for low number of cars]]<br />
For this simulation run, 40 cars were left including 12 premium ones. At the same time, it makes no sense to keep 5 maintainers for such a low number of cars and only 1 maintainer was kept. Because of low number of cars, statuses fluctuated more. However, number of idle cars still exceeds number of cars in rent: users are not eager to rent a car because it is mostly far away from them. Due to lower cost of maintenance, revenue is still almost twice greater than expenditures and, due to lower initial investments, return of investments will happen already in 1.5 years.<br />
<br />
==Extremes==<br />
<br />
Two extreme scenarios were also tried: 4 cars (including one premium) with 1 maintainer and 10,000 cars (including 1,450 premium ones) with 5 maintainers for 1,000 users. In the first run, revenue barely exceeded expenditures, return of investments would take decades. In the second run, until the end of the quarter, revenue value did not even reach the value of expenditure.<br />
<br />
==Optimization of the best scenario==<br />
<br />
[[File:Car-statuses-1-maintainer.jpeg|250px|thumb|left|Car statuses over time with only 1 maintainer]]<br />
Last runs aimed to increase margin profit by decreasing number of maintainers and slightly increasing number of cars comparing to the best scenario (200 cars per 1,000 users). It turned out that even one maintainer is enough to perform routine maintenance of the fleet. Number of cars waiting for maintenance grew but the profit in the end increased. Graph of car statuses looks similar to what was shown before with a extra red ("need maintenance" status) cars. On the other hand, revenue now exceeds expenditures 2.5 times (comparing to 2 times with 5 maintainers). It means that return of investments may happen already in 1.5-2 years.<br />
<br />
At the same time, increase in number of cars from 200 to 250 (with 1 maintainer) kept the ratio revenue / expenditures at the same level increasing turnover. However, considering greater initial investments, return of investments would happen definitely not sooner than with 200 cars.<br />
<br />
=Conclusion=<br />
<br />
<br />
=Code=<br />
<br />
[[File:Carsharing.nlogo]]</div>Shcs00http://www.simulace.info/index.php?title=File:Carsharing.nlogo&diff=22232File:Carsharing.nlogo2021-12-20T15:39:08Z<p>Shcs00: </p>
<hr />
<div></div>Shcs00http://www.simulace.info/index.php?title=Carsharing_Fleet_Optimization&diff=22231Carsharing Fleet Optimization2021-12-20T15:37:08Z<p>Shcs00: /* Results */</p>
<hr />
<div>=Introduction=<br />
<br />
Recently, carsharing becomes more and more popular in large cities. Short-term rental (from several minutes to 24 hours) of a car with possibility to drop it anywhere in the allowed area in the city attracts people who, for some reason, do not want to use their own vehicles. However, it is not always convenient. If the fleet is relatively small, the probability that a car will be somewhere close by is also quite low. Cars also must be refueled or recharged sometimes by staff, which would increase cost of the fleet maintenance with increasing of the fleet size.<br />
<br />
=Problem definition=<br />
<br />
Carsharing companies have to solve a problem of optimization of their fleet size, which is not simple. The entire system of carsharing is complex and has many different parameters that must be considered for decision making. For example, if the number of cars available in the city is relatively small the maintenance is also respectively inexpensive. However, in this case, the probability that users can find a car next to their location drops drastically. On the other hand, having too many cars leads to the risk that they will stay with no use for long time. The goal of this simulation is to understand how the carsharing system behaves and propose quantitative solution on optimal number of cars and price of rent to maximize marginal profit of a hypothetical carsharing company.<br />
<br />
=Method=<br />
<br />
Since the system consists of several entities, each of them is able to some extent to make decisions, and system itself is dynamic and requires to take into account spatial factors, agent-based modelling was chosen as the most appropriate tool to design the simulation. Implementation was performed using NetLogo software platform.<br />
<br />
=Model=<br />
<br />
The model is represented by several agents and accepts some simplifications. It is assumed that the simulation will be run on ticks, every tick represents one minute of real time.<br />
<br />
==Agents==<br />
<br />
The model contains 3 types of agents: cars, users, and maintainers.<br />
<br />
===Cars===<br />
<br />
Represent the vehicles used for short-term rentals. Cars have the following characteristics:<br />
* price - cost of rental per minute<br />
* status - current status of the vehicle, can be ''idle'' (the car is ready for rent), ''booked'' (the car is booked but paid rent has not started yet), ''in rent'' (the car is taken in paid rent by some user, for the purpose of this simulation it means that the car is moving), ''needs maintenance'' (the car is not visible for users but visible for maintainers), and ''out of service'' (the car is not visible for users and maintainers, is already under maintenance by one of the maintainers)<br />
* fuel - how many liters of gas is left<br />
* mileage - for how many kilometres the car was already driven, every car must go through maintenance procedure every 10,000 kilometres<br />
* premium - boolean parameter that indicates if the car belongs to premium class<br />
* inspection - boolean parameter indicating that the car needs to undergo an inspection.<br />
<br />
Cars are located in the simulation space and, if possible, can be rented by users. Users can drive cars, i.e., move it from one point of the simulation space to another. Cars can be re-fueled and taken to inspection by maintainers. It is assumed that a car can serve for the purpose of carsharing only for 100,000 km, then the car is replaced with absolutely identical one.<br />
<br />
===Users===<br />
<br />
Represent people holding a driving license, registered in the carsharing service and actively using it. Every tick of the simulation users decide with probability 1% whether they want to travel from the current location to somewhere else and, if so, to what coordinates of the simulation space. However, there are peak hours when most of users want to travel (for example, commute to work). It is assumed that there are 3 such hours every workday, 15 hours during the week, i.e. 9% of all the time. During these hours 50% users want to travel somewhere.<br />
<br />
Then, user starts looking for a car and, if the user finds one near by, decides if he or she wants to book it. The closer the car and the lower the price of the rent, the greater is probability that user takes the car. If user decides to rent a car, the user first books it and walks to the car. Then, user decides whether the user wants to start rent. With probability 1%, user who booked a car will decide not to start paid rent for some reason (for example, the car is dirty). When user decides not to take a car or not to start paid rent, it is assumed that the user gets to the destination point by personal car or by public transport. In the end, user who decided to travel travels anyway, by car or without it. If user travels by car, the user leaves the car exactly at the destination point. Users have the following parameters:<br />
* travel - boolean parameter indicating if user is travelling at the moment<br />
* destination (''destinationx'' and ''destinationy'') - destination where user is travelling to (applicable only if ''travel = True'')<br />
* car_assigned - car which user uses for travelling, could be ''Nobody'' if user travel not using a carsharing car (applicable only if ''travel = True'').<br />
<br />
For every user, maximum acceptable time of walking to the car before booking is 20 minutes (2 km).<br />
<br />
===Maintainers===<br />
<br />
Represent employees of carsharing company who are responsible for maintenance of the cars. They have their own vehicles (not the agent cars) and identify the cars which need maintenance in the simulation space based on the car's parameter status. The identified car is marked as out of service until maintenance is over. It is assumed that as soon as maintainer reaches the car, maintenance is done and car is again ready for rent. Maintainers have the only parameter - car_assigned - indicating the car assigned to them for maintenance (could be ''Nobody'' if no car is assigned). There are only two conditions when a car can be marked as needed maintenance:<br />
* fuel level is below 2.5 liters (for this simulation, it is number close to amount of fuel needed to drive across the square simulation space diagonal)<br />
* car exceeded another 10,000 km and requires inspection.<br />
<br />
==Simplifications==<br />
<br />
Since the carsharing system is very complex, for the purpose of this simulation some simplifications were accepted.<br />
<br />
===Space===<br />
<br />
Space of the simulation is considered uniform, i.e., there is no roads, buildings, and traffic in the simulation space. It does not matter what roads the users will drive across and how much time they will spend in traffic. On the other hand, what matters is duration of rent, which for this simplification does not depend on the traffic. The city is assumed to be of a square size 20×20 km. The simulation field is set of size 100×100 patches, which means that every patch has height and width equal to 200 m (0.2 km).<br />
<br />
===Prices===<br />
<br />
In real life, carsharing companies often offer different plans. It is normally fixed price per minute (usually depending on current demand) and packages with different duration with or without included mileage (for example, 2 hours of rent with 20 km included with fixed price per minute and per km after exceeding the included amount of time and mileage). For this simulation, only fixed prices per minute are available. The reason is that, even though some carsharing providers offer a wide range of different packages and plans, in the end final price does not differ much for each of the package.<br />
<br />
===Cars===<br />
<br />
There are several simplifications related to the cars.<br />
* First, all of them have the same fuel consumption: 7.5 l per 100 km. It means that 1 liter of fuel will cover approximately 13.33 km.<br />
* Second, it is assumed that cars do not need any maintenance except for regular inspection every 10,000 km and re-fueling.<br />
* Third, only users can drive the cars. It is assumed that maintainers do no move the cars (which could happen in real life to adjust the car locations to expected demand) and perform inspection every 10,000 km at the place where the car is located at the moment<br />
* Finally, there are only 2 types of cars: regular and premium, they have totally identical characteristics, only price differs.<br />
<br />
===Users===<br />
<br />
All the users drive cars with the same speed, 40 km/h. All of them are very careful and never have any accidents. Users drive cars only from one point in the simulation space to another, they do not drive between several points and do not leave the rent on pending (in real life, for example, some people could take a car to go for groceries and back and leave the car parked in paid rent while shopping). Without a car, users walk with the speed of 6 km/h.<br />
<br />
==Revenue and expenditures==<br />
<br />
Since the goal of the simulation is to find optimal parameters to maximize marginal profit, a task of financial calculations appears. However, calculations in the simulations are very simple. For the purpose of this simulation, Czech crowns were used as currency for all the financial operations. There is only one way to increase revenue - by renting out the cars. There are several expenditures:<br />
* fuel price (added after every refueling, by default 30 CZK per liter)<br />
* inspection cost (added for each car every inspection, assumed to be equal to 15,000 CZK)<br />
* cost of maintenance, including salary of maintainers, fuel for maintainers' vehicles, and so on (by default 10 CZK per minute).<br />
<br />
Margin profit is calculated as revenue minus expenditures minus initial expenditures. Initial expenditures include the price of the cars. It is assumed that regular car price is 400,000 CZK and premium car price is 800,000 CZK.<br />
<br />
=Results=<br />
<br />
[[File:Demo.gif|200px|thumb|right|Renting of a car]]<br />
The simulation is designed in a way that number of cars, number of users, number of maintainers, number of premium cars, rental price for normal and premium cars, fuel price, and maintenance rate are adjustable.<br />
<br />
Unfortunately, it was not possible to get actual data from a real carsharing company operating in Prague. However, according to publicly available observations in the carsharing operator's application, ratio of cars available for rent is in average 70-80%. Similar results were obtained for 1,000 users and 200 cars (5 users per car).<br />
<br />
It is visible that the results are stable and fluctuations in numbers of cars of each status are within narrow boundaries. Thus, the simulation is considered to be developed well.<br />
<br />
Further in this section, different ratios of users per car considered, all the observations are listed. Since a tick of the simulation is counted as 1 minute of real time, in each case the observation period was set as one quarter (around 131,000 ticks).<br />
<br />
==Normal ratio==<br />
<br />
[[File:Car-statuses.jpeg|250px|thumb|left|Car statuses over time for normal ratio]]<br />
[[File:Normal-finances.jpeg|250px|thumb|right|Revenue and expenditure for normal ratio]]<br />
With normal ratio (5 users per car), results look fine, revenue exceeds expenditures twice. Return of investment may happen already in 3 years, which is okay. However, cost of maintenance starts growing faster closer to the end of the quarter since there are some delayed expenses such as planned inspections. However, this scenario looks good in general and will be used for comparison for the future cases.<br />
<br />
Another important observation here is that with 5 maintainers, almost no cars are in the maintenance state, which means that maintainers manage to work on the car as soon as it needs maintenance.<br />
<br />
==High number of cars==<br />
<br />
[[File:Car-statuses-high.jpeg|250px|thumb|left|Car statuses over time for high number of cars]]<br />
[[File:High-finances.jpeg|250px|thumb|right|Revenue and expenditure for high number of cars]]<br />
In this scenario, number of cars was increased to 1,000 (including 145 premium ones) and was equal to number of users. As a result, 85-90% of cars were in idle state all the time. But it positively affected<br />
profit: now revenue exceeds expenditures three times. Also, the curve of expenditures looks more stable: every car has less mileage and requires less investments. However, considering that initial investments are significantly higher, since number of cars is 5 times greater than in previous scenario, and return of investment would take almost 40 years. Also, for the period of one quarter with such number of cars, expenses on inspections and car replacements are not yet visible on the graph and will be higher (which means smaller gap between revenue and expenditures) in the future.<br />
<br />
Hence, it makes no sense to increase number of cars that much because margin profit in the end will be much worse than in case with 200 available cars.<br />
<br />
==Low number of cars==<br />
<br />
[[File:Car-statuses-low.jpeg|250px|thumb|left|Car statuses over time for low number of cars]]<br />
[[File:Low-finances.jpeg|250px|thumb|right|Revenue and expenditure for low number of cars]]<br />
For this simulation run, 40 cars were left including 12 premium ones. At the same time, it makes no sense to keep 5 maintainers for such a low number of cars and only 1 maintainer was kept. Because of low number of cars, statuses fluctuated more. However, number of idle cars still exceeds number of cars in rent: users are not eager to rent a car because it is mostly far away from them. Due to lower cost of maintenance, revenue is still almost twice greater than expenditures and, due to lower initial investments, return of investments will happen already in 1.5 years.<br />
<br />
==Extremes==<br />
<br />
Two extreme scenarios were also tried: 4 cars (including one premium) with 1 maintainer and 10,000 cars (including 1,450 premium ones) with 5 maintainers for 1,000 users. In the first run, revenue barely exceeded expenditures, return of investments would take decades. In the second run, until the end of the quarter, revenue value did not even reach the value of expenditure.<br />
<br />
==Optimization of the best scenario==<br />
<br />
[[File:Car-statuses-1-maintainer.jpeg|250px|thumb|left|Car statuses over time with only 1 maintainer]]<br />
Last runs aimed to increase margin profit by decreasing number of maintainers and slightly increasing number of cars comparing to the best scenario (200 cars per 1,000 users). It turned out that even one maintainer is enough to perform routine maintenance of the fleet. Number of cars waiting for maintenance grew but the profit in the end increased. Graph of car statuses looks similar to what was shown before with a extra red ("need maintenance" status) cars. On the other hand, revenue now exceeds expenditures 2.5 times (comparing to 2 times with 5 maintainers). It means that return of investments may happen already in 1.5-2 years.<br />
<br />
At the same time, increase in number of cars from 200 to 250 (with 1 maintainer) kept the ratio revenue / expenditures at the same level increasing turnover. However, considering greater initial investments, return of investments would happen definitely not sooner than with 200 cars.<br />
<br />
=Conclusion=<br />
<br />
<br />
=Code=<br />
<br />
[[File:carsharing.nlogo]]</div>Shcs00http://www.simulace.info/index.php?title=File:Car-statuses-1-maintainer.jpeg&diff=22230File:Car-statuses-1-maintainer.jpeg2021-12-20T15:37:03Z<p>Shcs00: </p>
<hr />
<div></div>Shcs00http://www.simulace.info/index.php?title=File:Low-finances.jpeg&diff=22229File:Low-finances.jpeg2021-12-20T14:56:17Z<p>Shcs00: </p>
<hr />
<div></div>Shcs00http://www.simulace.info/index.php?title=File:Car-statuses-low.jpeg&diff=22228File:Car-statuses-low.jpeg2021-12-20T14:55:55Z<p>Shcs00: </p>
<hr />
<div></div>Shcs00http://www.simulace.info/index.php?title=File:High-finances.jpeg&diff=22227File:High-finances.jpeg2021-12-20T14:32:13Z<p>Shcs00: </p>
<hr />
<div></div>Shcs00http://www.simulace.info/index.php?title=File:Car-statuses-high.jpeg&diff=22226File:Car-statuses-high.jpeg2021-12-20T14:31:59Z<p>Shcs00: </p>
<hr />
<div></div>Shcs00http://www.simulace.info/index.php?title=File:Normal-finances.jpeg&diff=22225File:Normal-finances.jpeg2021-12-20T14:15:37Z<p>Shcs00: </p>
<hr />
<div></div>Shcs00http://www.simulace.info/index.php?title=Carsharing_Fleet_Optimization&diff=22224Carsharing Fleet Optimization2021-12-20T13:49:43Z<p>Shcs00: /* Results */</p>
<hr />
<div>=Introduction=<br />
<br />
Recently, carsharing becomes more and more popular in large cities. Short-term rental (from several minutes to 24 hours) of a car with possibility to drop it anywhere in the allowed area in the city attracts people who, for some reason, do not want to use their own vehicles. However, it is not always convenient. If the fleet is relatively small, the probability that a car will be somewhere close by is also quite low. Cars also must be refueled or recharged sometimes by staff, which would increase cost of the fleet maintenance with increasing of the fleet size.<br />
<br />
=Problem definition=<br />
<br />
Carsharing companies have to solve a problem of optimization of their fleet size, which is not simple. The entire system of carsharing is complex and has many different parameters that must be considered for decision making. For example, if the number of cars available in the city is relatively small the maintenance is also respectively inexpensive. However, in this case, the probability that users can find a car next to their location drops drastically. On the other hand, having too many cars leads to the risk that they will stay with no use for long time. The goal of this simulation is to understand how the carsharing system behaves and propose quantitative solution on optimal number of cars and price of rent to maximize marginal profit of a hypothetical carsharing company.<br />
<br />
=Method=<br />
<br />
Since the system consists of several entities, each of them is able to some extent to make decisions, and system itself is dynamic and requires to take into account spatial factors, agent-based modelling was chosen as the most appropriate tool to design the simulation. Implementation was performed using NetLogo software platform.<br />
<br />
=Model=<br />
<br />
The model is represented by several agents and accepts some simplifications. It is assumed that the simulation will be run on ticks, every tick represents one minute of real time.<br />
<br />
==Agents==<br />
<br />
The model contains 3 types of agents: cars, users, and maintainers.<br />
<br />
===Cars===<br />
<br />
Represent the vehicles used for short-term rentals. Cars have the following characteristics:<br />
* price - cost of rental per minute<br />
* status - current status of the vehicle, can be ''idle'' (the car is ready for rent), ''booked'' (the car is booked but paid rent has not started yet), ''in rent'' (the car is taken in paid rent by some user, for the purpose of this simulation it means that the car is moving), ''needs maintenance'' (the car is not visible for users but visible for maintainers), and ''out of service'' (the car is not visible for users and maintainers, is already under maintenance by one of the maintainers)<br />
* fuel - how many liters of gas is left<br />
* mileage - for how many kilometres the car was already driven, every car must go through maintenance procedure every 10,000 kilometres<br />
* premium - boolean parameter that indicates if the car belongs to premium class<br />
* inspection - boolean parameter indicating that the car needs to undergo an inspection.<br />
<br />
Cars are located in the simulation space and, if possible, can be rented by users. Users can drive cars, i.e., move it from one point of the simulation space to another. Cars can be re-fueled and taken to inspection by maintainers. It is assumed that a car can serve for the purpose of carsharing only for 100,000 km, then the car is replaced with absolutely identical one.<br />
<br />
===Users===<br />
<br />
Represent people holding a driving license, registered in the carsharing service and actively using it. Every tick of the simulation users decide with probability 1% whether they want to travel from the current location to somewhere else and, if so, to what coordinates of the simulation space. However, there are peak hours when most of users want to travel (for example, commute to work). It is assumed that there are 3 such hours every workday, 15 hours during the week, i.e. 9% of all the time. During these hours 50% users want to travel somewhere.<br />
<br />
Then, user starts looking for a car and, if the user finds one near by, decides if he or she wants to book it. The closer the car and the lower the price of the rent, the greater is probability that user takes the car. If user decides to rent a car, the user first books it and walks to the car. Then, user decides whether the user wants to start rent. With probability 1%, user who booked a car will decide not to start paid rent for some reason (for example, the car is dirty). When user decides not to take a car or not to start paid rent, it is assumed that the user gets to the destination point by personal car or by public transport. In the end, user who decided to travel travels anyway, by car or without it. If user travels by car, the user leaves the car exactly at the destination point. Users have the following parameters:<br />
* travel - boolean parameter indicating if user is travelling at the moment<br />
* destination (''destinationx'' and ''destinationy'') - destination where user is travelling to (applicable only if ''travel = True'')<br />
* car_assigned - car which user uses for travelling, could be ''Nobody'' if user travel not using a carsharing car (applicable only if ''travel = True'').<br />
<br />
For every user, maximum acceptable time of walking to the car before booking is 20 minutes (2 km).<br />
<br />
===Maintainers===<br />
<br />
Represent employees of carsharing company who are responsible for maintenance of the cars. They have their own vehicles (not the agent cars) and identify the cars which need maintenance in the simulation space based on the car's parameter status. The identified car is marked as out of service until maintenance is over. It is assumed that as soon as maintainer reaches the car, maintenance is done and car is again ready for rent. Maintainers have the only parameter - car_assigned - indicating the car assigned to them for maintenance (could be ''Nobody'' if no car is assigned). There are only two conditions when a car can be marked as needed maintenance:<br />
* fuel level is below 2.5 liters (for this simulation, it is number close to amount of fuel needed to drive across the square simulation space diagonal)<br />
* car exceeded another 10,000 km and requires inspection.<br />
<br />
==Simplifications==<br />
<br />
Since the carsharing system is very complex, for the purpose of this simulation some simplifications were accepted.<br />
<br />
===Space===<br />
<br />
Space of the simulation is considered uniform, i.e., there is no roads, buildings, and traffic in the simulation space. It does not matter what roads the users will drive across and how much time they will spend in traffic. On the other hand, what matters is duration of rent, which for this simplification does not depend on the traffic. The city is assumed to be of a square size 20×20 km. The simulation field is set of size 100×100 patches, which means that every patch has height and width equal to 200 m (0.2 km).<br />
<br />
===Prices===<br />
<br />
In real life, carsharing companies often offer different plans. It is normally fixed price per minute (usually depending on current demand) and packages with different duration with or without included mileage (for example, 2 hours of rent with 20 km included with fixed price per minute and per km after exceeding the included amount of time and mileage). For this simulation, only fixed prices per minute are available. The reason is that, even though some carsharing providers offer a wide range of different packages and plans, in the end final price does not differ much for each of the package.<br />
<br />
===Cars===<br />
<br />
There are several simplifications related to the cars.<br />
* First, all of them have the same fuel consumption: 7.5 l per 100 km. It means that 1 liter of fuel will cover approximately 13.33 km.<br />
* Second, it is assumed that cars do not need any maintenance except for regular inspection every 10,000 km and re-fueling.<br />
* Third, only users can drive the cars. It is assumed that maintainers do no move the cars (which could happen in real life to adjust the car locations to expected demand) and perform inspection every 10,000 km at the place where the car is located at the moment<br />
* Finally, there are only 2 types of cars: regular and premium, they have totally identical characteristics, only price differs.<br />
<br />
===Users===<br />
<br />
All the users drive cars with the same speed, 40 km/h. All of them are very careful and never have any accidents. Users drive cars only from one point in the simulation space to another, they do not drive between several points and do not leave the rent on pending (in real life, for example, some people could take a car to go for groceries and back and leave the car parked in paid rent while shopping). Without a car, users walk with the speed of 6 km/h.<br />
<br />
==Revenue and expenditures==<br />
<br />
Since the goal of the simulation is to find optimal parameters to maximize marginal profit, a task of financial calculations appears. However, calculations in the simulations are very simple. For the purpose of this simulation, Czech crowns were used as currency for all the financial operations. There is only one way to increase revenue - by renting out the cars. There are several expenditures:<br />
* fuel price (added after every refueling, by default 30 CZK per liter)<br />
* inspection cost (added for each car every inspection, assumed to be equal to 15,000 CZK)<br />
* cost of maintenance, including salary of maintainers, fuel for maintainers' vehicles, and so on (by default 10 CZK per minute).<br />
<br />
Margin profit is calculated as revenue minus expenditures minus initial expenditures. Initial expenditures include the price of the cars. It is assumed that regular car price is 400,000 CZK and premium car price is 800,000 CZK.<br />
<br />
=Results=<br />
<br />
[[File:Car-statuses.jpeg|250px|thumb|left|Car statuses over time]]<br />
The simulation is designed in a way that number of cars, number of users, number of maintainers, number of premium cars, rental price for normal and premium cars, fuel price, and maintenance rate are adjustable.<br />
<br />
Unfortunately, it was not possible to get actual data from a real carsharing company operating in Prague. However, according to publicly available observations in the carsharing operator's application, ratio of cars available for rent is in average 70-80%. Similar results were obtained for 1,000 users and 200 cars.<br />
<br />
[[File:Demo.gif|200px|thumb|right|Renting of a car]]<br />
<br />
=Conclusion=<br />
<br />
<br />
=Code=<br />
<br />
[[File:carsharing.nlogo]]</div>Shcs00http://www.simulace.info/index.php?title=File:Demo.gif&diff=22223File:Demo.gif2021-12-20T13:48:48Z<p>Shcs00: </p>
<hr />
<div></div>Shcs00http://www.simulace.info/index.php?title=Carsharing_Fleet_Optimization&diff=22222Carsharing Fleet Optimization2021-12-20T13:48:34Z<p>Shcs00: /* Results */</p>
<hr />
<div>=Introduction=<br />
<br />
Recently, carsharing becomes more and more popular in large cities. Short-term rental (from several minutes to 24 hours) of a car with possibility to drop it anywhere in the allowed area in the city attracts people who, for some reason, do not want to use their own vehicles. However, it is not always convenient. If the fleet is relatively small, the probability that a car will be somewhere close by is also quite low. Cars also must be refueled or recharged sometimes by staff, which would increase cost of the fleet maintenance with increasing of the fleet size.<br />
<br />
=Problem definition=<br />
<br />
Carsharing companies have to solve a problem of optimization of their fleet size, which is not simple. The entire system of carsharing is complex and has many different parameters that must be considered for decision making. For example, if the number of cars available in the city is relatively small the maintenance is also respectively inexpensive. However, in this case, the probability that users can find a car next to their location drops drastically. On the other hand, having too many cars leads to the risk that they will stay with no use for long time. The goal of this simulation is to understand how the carsharing system behaves and propose quantitative solution on optimal number of cars and price of rent to maximize marginal profit of a hypothetical carsharing company.<br />
<br />
=Method=<br />
<br />
Since the system consists of several entities, each of them is able to some extent to make decisions, and system itself is dynamic and requires to take into account spatial factors, agent-based modelling was chosen as the most appropriate tool to design the simulation. Implementation was performed using NetLogo software platform.<br />
<br />
=Model=<br />
<br />
The model is represented by several agents and accepts some simplifications. It is assumed that the simulation will be run on ticks, every tick represents one minute of real time.<br />
<br />
==Agents==<br />
<br />
The model contains 3 types of agents: cars, users, and maintainers.<br />
<br />
===Cars===<br />
<br />
Represent the vehicles used for short-term rentals. Cars have the following characteristics:<br />
* price - cost of rental per minute<br />
* status - current status of the vehicle, can be ''idle'' (the car is ready for rent), ''booked'' (the car is booked but paid rent has not started yet), ''in rent'' (the car is taken in paid rent by some user, for the purpose of this simulation it means that the car is moving), ''needs maintenance'' (the car is not visible for users but visible for maintainers), and ''out of service'' (the car is not visible for users and maintainers, is already under maintenance by one of the maintainers)<br />
* fuel - how many liters of gas is left<br />
* mileage - for how many kilometres the car was already driven, every car must go through maintenance procedure every 10,000 kilometres<br />
* premium - boolean parameter that indicates if the car belongs to premium class<br />
* inspection - boolean parameter indicating that the car needs to undergo an inspection.<br />
<br />
Cars are located in the simulation space and, if possible, can be rented by users. Users can drive cars, i.e., move it from one point of the simulation space to another. Cars can be re-fueled and taken to inspection by maintainers. It is assumed that a car can serve for the purpose of carsharing only for 100,000 km, then the car is replaced with absolutely identical one.<br />
<br />
===Users===<br />
<br />
Represent people holding a driving license, registered in the carsharing service and actively using it. Every tick of the simulation users decide with probability 1% whether they want to travel from the current location to somewhere else and, if so, to what coordinates of the simulation space. However, there are peak hours when most of users want to travel (for example, commute to work). It is assumed that there are 3 such hours every workday, 15 hours during the week, i.e. 9% of all the time. During these hours 50% users want to travel somewhere.<br />
<br />
Then, user starts looking for a car and, if the user finds one near by, decides if he or she wants to book it. The closer the car and the lower the price of the rent, the greater is probability that user takes the car. If user decides to rent a car, the user first books it and walks to the car. Then, user decides whether the user wants to start rent. With probability 1%, user who booked a car will decide not to start paid rent for some reason (for example, the car is dirty). When user decides not to take a car or not to start paid rent, it is assumed that the user gets to the destination point by personal car or by public transport. In the end, user who decided to travel travels anyway, by car or without it. If user travels by car, the user leaves the car exactly at the destination point. Users have the following parameters:<br />
* travel - boolean parameter indicating if user is travelling at the moment<br />
* destination (''destinationx'' and ''destinationy'') - destination where user is travelling to (applicable only if ''travel = True'')<br />
* car_assigned - car which user uses for travelling, could be ''Nobody'' if user travel not using a carsharing car (applicable only if ''travel = True'').<br />
<br />
For every user, maximum acceptable time of walking to the car before booking is 20 minutes (2 km).<br />
<br />
===Maintainers===<br />
<br />
Represent employees of carsharing company who are responsible for maintenance of the cars. They have their own vehicles (not the agent cars) and identify the cars which need maintenance in the simulation space based on the car's parameter status. The identified car is marked as out of service until maintenance is over. It is assumed that as soon as maintainer reaches the car, maintenance is done and car is again ready for rent. Maintainers have the only parameter - car_assigned - indicating the car assigned to them for maintenance (could be ''Nobody'' if no car is assigned). There are only two conditions when a car can be marked as needed maintenance:<br />
* fuel level is below 2.5 liters (for this simulation, it is number close to amount of fuel needed to drive across the square simulation space diagonal)<br />
* car exceeded another 10,000 km and requires inspection.<br />
<br />
==Simplifications==<br />
<br />
Since the carsharing system is very complex, for the purpose of this simulation some simplifications were accepted.<br />
<br />
===Space===<br />
<br />
Space of the simulation is considered uniform, i.e., there is no roads, buildings, and traffic in the simulation space. It does not matter what roads the users will drive across and how much time they will spend in traffic. On the other hand, what matters is duration of rent, which for this simplification does not depend on the traffic. The city is assumed to be of a square size 20×20 km. The simulation field is set of size 100×100 patches, which means that every patch has height and width equal to 200 m (0.2 km).<br />
<br />
===Prices===<br />
<br />
In real life, carsharing companies often offer different plans. It is normally fixed price per minute (usually depending on current demand) and packages with different duration with or without included mileage (for example, 2 hours of rent with 20 km included with fixed price per minute and per km after exceeding the included amount of time and mileage). For this simulation, only fixed prices per minute are available. The reason is that, even though some carsharing providers offer a wide range of different packages and plans, in the end final price does not differ much for each of the package.<br />
<br />
===Cars===<br />
<br />
There are several simplifications related to the cars.<br />
* First, all of them have the same fuel consumption: 7.5 l per 100 km. It means that 1 liter of fuel will cover approximately 13.33 km.<br />
* Second, it is assumed that cars do not need any maintenance except for regular inspection every 10,000 km and re-fueling.<br />
* Third, only users can drive the cars. It is assumed that maintainers do no move the cars (which could happen in real life to adjust the car locations to expected demand) and perform inspection every 10,000 km at the place where the car is located at the moment<br />
* Finally, there are only 2 types of cars: regular and premium, they have totally identical characteristics, only price differs.<br />
<br />
===Users===<br />
<br />
All the users drive cars with the same speed, 40 km/h. All of them are very careful and never have any accidents. Users drive cars only from one point in the simulation space to another, they do not drive between several points and do not leave the rent on pending (in real life, for example, some people could take a car to go for groceries and back and leave the car parked in paid rent while shopping). Without a car, users walk with the speed of 6 km/h.<br />
<br />
==Revenue and expenditures==<br />
<br />
Since the goal of the simulation is to find optimal parameters to maximize marginal profit, a task of financial calculations appears. However, calculations in the simulations are very simple. For the purpose of this simulation, Czech crowns were used as currency for all the financial operations. There is only one way to increase revenue - by renting out the cars. There are several expenditures:<br />
* fuel price (added after every refueling, by default 30 CZK per liter)<br />
* inspection cost (added for each car every inspection, assumed to be equal to 15,000 CZK)<br />
* cost of maintenance, including salary of maintainers, fuel for maintainers' vehicles, and so on (by default 10 CZK per minute).<br />
<br />
Margin profit is calculated as revenue minus expenditures minus initial expenditures. Initial expenditures include the price of the cars. It is assumed that regular car price is 400,000 CZK and premium car price is 800,000 CZK.<br />
<br />
=Results=<br />
<br />
[[File:Car-statuses.jpeg|250px|thumb|left|Car statuses over time]]<br />
The simulation is designed in a way that number of cars, number of users, number of maintainers, number of premium cars, rental price for normal and premium cars, fuel price, and maintenance rate are adjustable.<br />
<br />
Unfortunately, it was not possible to get actual data from a real carsharing company operating in Prague. However, according to publicly available observations in the carsharing operator's application, ratio of cars available for rent is in average 70-80%. Similar results were obtained for 1,000 users and 200 cars.<br />
<br />
[[File:demo.gif|300px|thumb|right|Renting of a car]]<br />
<br />
=Conclusion=<br />
<br />
<br />
=Code=<br />
<br />
[[File:carsharing.nlogo]]</div>Shcs00http://www.simulace.info/index.php?title=Carsharing_Fleet_Optimization&diff=22221Carsharing Fleet Optimization2021-12-20T13:47:53Z<p>Shcs00: /* Results */</p>
<hr />
<div>=Introduction=<br />
<br />
Recently, carsharing becomes more and more popular in large cities. Short-term rental (from several minutes to 24 hours) of a car with possibility to drop it anywhere in the allowed area in the city attracts people who, for some reason, do not want to use their own vehicles. However, it is not always convenient. If the fleet is relatively small, the probability that a car will be somewhere close by is also quite low. Cars also must be refueled or recharged sometimes by staff, which would increase cost of the fleet maintenance with increasing of the fleet size.<br />
<br />
=Problem definition=<br />
<br />
Carsharing companies have to solve a problem of optimization of their fleet size, which is not simple. The entire system of carsharing is complex and has many different parameters that must be considered for decision making. For example, if the number of cars available in the city is relatively small the maintenance is also respectively inexpensive. However, in this case, the probability that users can find a car next to their location drops drastically. On the other hand, having too many cars leads to the risk that they will stay with no use for long time. The goal of this simulation is to understand how the carsharing system behaves and propose quantitative solution on optimal number of cars and price of rent to maximize marginal profit of a hypothetical carsharing company.<br />
<br />
=Method=<br />
<br />
Since the system consists of several entities, each of them is able to some extent to make decisions, and system itself is dynamic and requires to take into account spatial factors, agent-based modelling was chosen as the most appropriate tool to design the simulation. Implementation was performed using NetLogo software platform.<br />
<br />
=Model=<br />
<br />
The model is represented by several agents and accepts some simplifications. It is assumed that the simulation will be run on ticks, every tick represents one minute of real time.<br />
<br />
==Agents==<br />
<br />
The model contains 3 types of agents: cars, users, and maintainers.<br />
<br />
===Cars===<br />
<br />
Represent the vehicles used for short-term rentals. Cars have the following characteristics:<br />
* price - cost of rental per minute<br />
* status - current status of the vehicle, can be ''idle'' (the car is ready for rent), ''booked'' (the car is booked but paid rent has not started yet), ''in rent'' (the car is taken in paid rent by some user, for the purpose of this simulation it means that the car is moving), ''needs maintenance'' (the car is not visible for users but visible for maintainers), and ''out of service'' (the car is not visible for users and maintainers, is already under maintenance by one of the maintainers)<br />
* fuel - how many liters of gas is left<br />
* mileage - for how many kilometres the car was already driven, every car must go through maintenance procedure every 10,000 kilometres<br />
* premium - boolean parameter that indicates if the car belongs to premium class<br />
* inspection - boolean parameter indicating that the car needs to undergo an inspection.<br />
<br />
Cars are located in the simulation space and, if possible, can be rented by users. Users can drive cars, i.e., move it from one point of the simulation space to another. Cars can be re-fueled and taken to inspection by maintainers. It is assumed that a car can serve for the purpose of carsharing only for 100,000 km, then the car is replaced with absolutely identical one.<br />
<br />
===Users===<br />
<br />
Represent people holding a driving license, registered in the carsharing service and actively using it. Every tick of the simulation users decide with probability 1% whether they want to travel from the current location to somewhere else and, if so, to what coordinates of the simulation space. However, there are peak hours when most of users want to travel (for example, commute to work). It is assumed that there are 3 such hours every workday, 15 hours during the week, i.e. 9% of all the time. During these hours 50% users want to travel somewhere.<br />
<br />
Then, user starts looking for a car and, if the user finds one near by, decides if he or she wants to book it. The closer the car and the lower the price of the rent, the greater is probability that user takes the car. If user decides to rent a car, the user first books it and walks to the car. Then, user decides whether the user wants to start rent. With probability 1%, user who booked a car will decide not to start paid rent for some reason (for example, the car is dirty). When user decides not to take a car or not to start paid rent, it is assumed that the user gets to the destination point by personal car or by public transport. In the end, user who decided to travel travels anyway, by car or without it. If user travels by car, the user leaves the car exactly at the destination point. Users have the following parameters:<br />
* travel - boolean parameter indicating if user is travelling at the moment<br />
* destination (''destinationx'' and ''destinationy'') - destination where user is travelling to (applicable only if ''travel = True'')<br />
* car_assigned - car which user uses for travelling, could be ''Nobody'' if user travel not using a carsharing car (applicable only if ''travel = True'').<br />
<br />
For every user, maximum acceptable time of walking to the car before booking is 20 minutes (2 km).<br />
<br />
===Maintainers===<br />
<br />
Represent employees of carsharing company who are responsible for maintenance of the cars. They have their own vehicles (not the agent cars) and identify the cars which need maintenance in the simulation space based on the car's parameter status. The identified car is marked as out of service until maintenance is over. It is assumed that as soon as maintainer reaches the car, maintenance is done and car is again ready for rent. Maintainers have the only parameter - car_assigned - indicating the car assigned to them for maintenance (could be ''Nobody'' if no car is assigned). There are only two conditions when a car can be marked as needed maintenance:<br />
* fuel level is below 2.5 liters (for this simulation, it is number close to amount of fuel needed to drive across the square simulation space diagonal)<br />
* car exceeded another 10,000 km and requires inspection.<br />
<br />
==Simplifications==<br />
<br />
Since the carsharing system is very complex, for the purpose of this simulation some simplifications were accepted.<br />
<br />
===Space===<br />
<br />
Space of the simulation is considered uniform, i.e., there is no roads, buildings, and traffic in the simulation space. It does not matter what roads the users will drive across and how much time they will spend in traffic. On the other hand, what matters is duration of rent, which for this simplification does not depend on the traffic. The city is assumed to be of a square size 20×20 km. The simulation field is set of size 100×100 patches, which means that every patch has height and width equal to 200 m (0.2 km).<br />
<br />
===Prices===<br />
<br />
In real life, carsharing companies often offer different plans. It is normally fixed price per minute (usually depending on current demand) and packages with different duration with or without included mileage (for example, 2 hours of rent with 20 km included with fixed price per minute and per km after exceeding the included amount of time and mileage). For this simulation, only fixed prices per minute are available. The reason is that, even though some carsharing providers offer a wide range of different packages and plans, in the end final price does not differ much for each of the package.<br />
<br />
===Cars===<br />
<br />
There are several simplifications related to the cars.<br />
* First, all of them have the same fuel consumption: 7.5 l per 100 km. It means that 1 liter of fuel will cover approximately 13.33 km.<br />
* Second, it is assumed that cars do not need any maintenance except for regular inspection every 10,000 km and re-fueling.<br />
* Third, only users can drive the cars. It is assumed that maintainers do no move the cars (which could happen in real life to adjust the car locations to expected demand) and perform inspection every 10,000 km at the place where the car is located at the moment<br />
* Finally, there are only 2 types of cars: regular and premium, they have totally identical characteristics, only price differs.<br />
<br />
===Users===<br />
<br />
All the users drive cars with the same speed, 40 km/h. All of them are very careful and never have any accidents. Users drive cars only from one point in the simulation space to another, they do not drive between several points and do not leave the rent on pending (in real life, for example, some people could take a car to go for groceries and back and leave the car parked in paid rent while shopping). Without a car, users walk with the speed of 6 km/h.<br />
<br />
==Revenue and expenditures==<br />
<br />
Since the goal of the simulation is to find optimal parameters to maximize marginal profit, a task of financial calculations appears. However, calculations in the simulations are very simple. For the purpose of this simulation, Czech crowns were used as currency for all the financial operations. There is only one way to increase revenue - by renting out the cars. There are several expenditures:<br />
* fuel price (added after every refueling, by default 30 CZK per liter)<br />
* inspection cost (added for each car every inspection, assumed to be equal to 15,000 CZK)<br />
* cost of maintenance, including salary of maintainers, fuel for maintainers' vehicles, and so on (by default 10 CZK per minute).<br />
<br />
Margin profit is calculated as revenue minus expenditures minus initial expenditures. Initial expenditures include the price of the cars. It is assumed that regular car price is 400,000 CZK and premium car price is 800,000 CZK.<br />
<br />
=Results=<br />
<br />
The simulation is designed in a way that number of cars, number of users, number of maintainers, number of premium cars, rental price for normal and premium cars, fuel price, and maintenance rate are adjustable.<br />
<br />
[[File:Car-statuses.jpeg|150px|thumb|left|car statuses]]<br />
Unfortunately, it was not possible to get actual data from a real carsharing company operating in Prague. However, according to publicly available observations in the carsharing operator's application, ratio of cars available for rent is in average 70-80%. Similar results were obtained for 1,000 users and 200 cars.<br />
<br />
[[File:demo.gif|300px|thumb|right|renting of a car]]<br />
<br />
=Conclusion=<br />
<br />
<br />
=Code=<br />
<br />
[[File:carsharing.nlogo]]</div>Shcs00http://www.simulace.info/index.php?title=File:Car-statuses.jpeg&diff=22220File:Car-statuses.jpeg2021-12-20T13:46:42Z<p>Shcs00: </p>
<hr />
<div></div>Shcs00http://www.simulace.info/index.php?title=Carsharing_Fleet_Optimization&diff=22219Carsharing Fleet Optimization2021-12-20T13:46:07Z<p>Shcs00: /* Results */</p>
<hr />
<div>=Introduction=<br />
<br />
Recently, carsharing becomes more and more popular in large cities. Short-term rental (from several minutes to 24 hours) of a car with possibility to drop it anywhere in the allowed area in the city attracts people who, for some reason, do not want to use their own vehicles. However, it is not always convenient. If the fleet is relatively small, the probability that a car will be somewhere close by is also quite low. Cars also must be refueled or recharged sometimes by staff, which would increase cost of the fleet maintenance with increasing of the fleet size.<br />
<br />
=Problem definition=<br />
<br />
Carsharing companies have to solve a problem of optimization of their fleet size, which is not simple. The entire system of carsharing is complex and has many different parameters that must be considered for decision making. For example, if the number of cars available in the city is relatively small the maintenance is also respectively inexpensive. However, in this case, the probability that users can find a car next to their location drops drastically. On the other hand, having too many cars leads to the risk that they will stay with no use for long time. The goal of this simulation is to understand how the carsharing system behaves and propose quantitative solution on optimal number of cars and price of rent to maximize marginal profit of a hypothetical carsharing company.<br />
<br />
=Method=<br />
<br />
Since the system consists of several entities, each of them is able to some extent to make decisions, and system itself is dynamic and requires to take into account spatial factors, agent-based modelling was chosen as the most appropriate tool to design the simulation. Implementation was performed using NetLogo software platform.<br />
<br />
=Model=<br />
<br />
The model is represented by several agents and accepts some simplifications. It is assumed that the simulation will be run on ticks, every tick represents one minute of real time.<br />
<br />
==Agents==<br />
<br />
The model contains 3 types of agents: cars, users, and maintainers.<br />
<br />
===Cars===<br />
<br />
Represent the vehicles used for short-term rentals. Cars have the following characteristics:<br />
* price - cost of rental per minute<br />
* status - current status of the vehicle, can be ''idle'' (the car is ready for rent), ''booked'' (the car is booked but paid rent has not started yet), ''in rent'' (the car is taken in paid rent by some user, for the purpose of this simulation it means that the car is moving), ''needs maintenance'' (the car is not visible for users but visible for maintainers), and ''out of service'' (the car is not visible for users and maintainers, is already under maintenance by one of the maintainers)<br />
* fuel - how many liters of gas is left<br />
* mileage - for how many kilometres the car was already driven, every car must go through maintenance procedure every 10,000 kilometres<br />
* premium - boolean parameter that indicates if the car belongs to premium class<br />
* inspection - boolean parameter indicating that the car needs to undergo an inspection.<br />
<br />
Cars are located in the simulation space and, if possible, can be rented by users. Users can drive cars, i.e., move it from one point of the simulation space to another. Cars can be re-fueled and taken to inspection by maintainers. It is assumed that a car can serve for the purpose of carsharing only for 100,000 km, then the car is replaced with absolutely identical one.<br />
<br />
===Users===<br />
<br />
Represent people holding a driving license, registered in the carsharing service and actively using it. Every tick of the simulation users decide with probability 1% whether they want to travel from the current location to somewhere else and, if so, to what coordinates of the simulation space. However, there are peak hours when most of users want to travel (for example, commute to work). It is assumed that there are 3 such hours every workday, 15 hours during the week, i.e. 9% of all the time. During these hours 50% users want to travel somewhere.<br />
<br />
Then, user starts looking for a car and, if the user finds one near by, decides if he or she wants to book it. The closer the car and the lower the price of the rent, the greater is probability that user takes the car. If user decides to rent a car, the user first books it and walks to the car. Then, user decides whether the user wants to start rent. With probability 1%, user who booked a car will decide not to start paid rent for some reason (for example, the car is dirty). When user decides not to take a car or not to start paid rent, it is assumed that the user gets to the destination point by personal car or by public transport. In the end, user who decided to travel travels anyway, by car or without it. If user travels by car, the user leaves the car exactly at the destination point. Users have the following parameters:<br />
* travel - boolean parameter indicating if user is travelling at the moment<br />
* destination (''destinationx'' and ''destinationy'') - destination where user is travelling to (applicable only if ''travel = True'')<br />
* car_assigned - car which user uses for travelling, could be ''Nobody'' if user travel not using a carsharing car (applicable only if ''travel = True'').<br />
<br />
For every user, maximum acceptable time of walking to the car before booking is 20 minutes (2 km).<br />
<br />
===Maintainers===<br />
<br />
Represent employees of carsharing company who are responsible for maintenance of the cars. They have their own vehicles (not the agent cars) and identify the cars which need maintenance in the simulation space based on the car's parameter status. The identified car is marked as out of service until maintenance is over. It is assumed that as soon as maintainer reaches the car, maintenance is done and car is again ready for rent. Maintainers have the only parameter - car_assigned - indicating the car assigned to them for maintenance (could be ''Nobody'' if no car is assigned). There are only two conditions when a car can be marked as needed maintenance:<br />
* fuel level is below 2.5 liters (for this simulation, it is number close to amount of fuel needed to drive across the square simulation space diagonal)<br />
* car exceeded another 10,000 km and requires inspection.<br />
<br />
==Simplifications==<br />
<br />
Since the carsharing system is very complex, for the purpose of this simulation some simplifications were accepted.<br />
<br />
===Space===<br />
<br />
Space of the simulation is considered uniform, i.e., there is no roads, buildings, and traffic in the simulation space. It does not matter what roads the users will drive across and how much time they will spend in traffic. On the other hand, what matters is duration of rent, which for this simplification does not depend on the traffic. The city is assumed to be of a square size 20×20 km. The simulation field is set of size 100×100 patches, which means that every patch has height and width equal to 200 m (0.2 km).<br />
<br />
===Prices===<br />
<br />
In real life, carsharing companies often offer different plans. It is normally fixed price per minute (usually depending on current demand) and packages with different duration with or without included mileage (for example, 2 hours of rent with 20 km included with fixed price per minute and per km after exceeding the included amount of time and mileage). For this simulation, only fixed prices per minute are available. The reason is that, even though some carsharing providers offer a wide range of different packages and plans, in the end final price does not differ much for each of the package.<br />
<br />
===Cars===<br />
<br />
There are several simplifications related to the cars.<br />
* First, all of them have the same fuel consumption: 7.5 l per 100 km. It means that 1 liter of fuel will cover approximately 13.33 km.<br />
* Second, it is assumed that cars do not need any maintenance except for regular inspection every 10,000 km and re-fueling.<br />
* Third, only users can drive the cars. It is assumed that maintainers do no move the cars (which could happen in real life to adjust the car locations to expected demand) and perform inspection every 10,000 km at the place where the car is located at the moment<br />
* Finally, there are only 2 types of cars: regular and premium, they have totally identical characteristics, only price differs.<br />
<br />
===Users===<br />
<br />
All the users drive cars with the same speed, 40 km/h. All of them are very careful and never have any accidents. Users drive cars only from one point in the simulation space to another, they do not drive between several points and do not leave the rent on pending (in real life, for example, some people could take a car to go for groceries and back and leave the car parked in paid rent while shopping). Without a car, users walk with the speed of 6 km/h.<br />
<br />
==Revenue and expenditures==<br />
<br />
Since the goal of the simulation is to find optimal parameters to maximize marginal profit, a task of financial calculations appears. However, calculations in the simulations are very simple. For the purpose of this simulation, Czech crowns were used as currency for all the financial operations. There is only one way to increase revenue - by renting out the cars. There are several expenditures:<br />
* fuel price (added after every refueling, by default 30 CZK per liter)<br />
* inspection cost (added for each car every inspection, assumed to be equal to 15,000 CZK)<br />
* cost of maintenance, including salary of maintainers, fuel for maintainers' vehicles, and so on (by default 10 CZK per minute).<br />
<br />
Margin profit is calculated as revenue minus expenditures minus initial expenditures. Initial expenditures include the price of the cars. It is assumed that regular car price is 400,000 CZK and premium car price is 800,000 CZK.<br />
<br />
=Results=<br />
<br />
The simulation is designed in a way that number of cars, number of users, number of maintainers, number of premium cars, rental price for normal and premium cars, fuel price, and maintenance rate are adjustable.<br />
<br />
[[File:car-statuses|150px|thumb|left|car statuses]]<br />
Unfortunately, it was not possible to get actual data from a real carsharing company operating in Prague. However, according to publicly available observations in the carsharing operator's application, ratio of cars available for rent is in average 70-80%. Similar results were obtained for 1,000 users and 200 cars.<br />
<br />
[[File:demo.gif|300px|thumb|right|renting of a car]]<br />
<br />
=Conclusion=<br />
<br />
<br />
=Code=<br />
<br />
[[File:carsharing.nlogo]]</div>Shcs00http://www.simulace.info/index.php?title=Carsharing_Fleet_Optimization&diff=22217Carsharing Fleet Optimization2021-12-20T13:35:19Z<p>Shcs00: Shcs00 moved page Carsharing-fleet-optimization to Carsharing Fleet Optimization</p>
<hr />
<div>=Introduction=<br />
<br />
Recently, carsharing becomes more and more popular in large cities. Short-term rental (from several minutes to 24 hours) of a car with possibility to drop it anywhere in the allowed area in the city attracts people who, for some reason, do not want to use their own vehicles. However, it is not always convenient. If the fleet is relatively small, the probability that a car will be somewhere close by is also quite low. Cars also must be refueled or recharged sometimes by staff, which would increase cost of the fleet maintenance with increasing of the fleet size.<br />
<br />
=Problem definition=<br />
<br />
Carsharing companies have to solve a problem of optimization of their fleet size, which is not simple. The entire system of carsharing is complex and has many different parameters that must be considered for decision making. For example, if the number of cars available in the city is relatively small the maintenance is also respectively inexpensive. However, in this case, the probability that users can find a car next to their location drops drastically. On the other hand, having too many cars leads to the risk that they will stay with no use for long time. The goal of this simulation is to understand how the carsharing system behaves and propose quantitative solution on optimal number of cars and price of rent to maximize marginal profit of a hypothetical carsharing company.<br />
<br />
=Method=<br />
<br />
Since the system consists of several entities, each of them is able to some extent to make decisions, and system itself is dynamic and requires to take into account spatial factors, agent-based modelling was chosen as the most appropriate tool to design the simulation. Implementation was performed using NetLogo software platform.<br />
<br />
=Model=<br />
<br />
The model is represented by several agents and accepts some simplifications. It is assumed that the simulation will be run on ticks, every tick represents one minute of real time.<br />
<br />
==Agents==<br />
<br />
The model contains 3 types of agents: cars, users, and maintainers.<br />
<br />
===Cars===<br />
<br />
Represent the vehicles used for short-term rentals. Cars have the following characteristics:<br />
* price - cost of rental per minute<br />
* status - current status of the vehicle, can be ''idle'' (the car is ready for rent), ''booked'' (the car is booked but paid rent has not started yet), ''in rent'' (the car is taken in paid rent by some user, for the purpose of this simulation it means that the car is moving), ''needs maintenance'' (the car is not visible for users but visible for maintainers), and ''out of service'' (the car is not visible for users and maintainers, is already under maintenance by one of the maintainers)<br />
* fuel - how many liters of gas is left<br />
* mileage - for how many kilometres the car was already driven, every car must go through maintenance procedure every 10,000 kilometres<br />
* premium - boolean parameter that indicates if the car belongs to premium class<br />
* inspection - boolean parameter indicating that the car needs to undergo an inspection.<br />
<br />
Cars are located in the simulation space and, if possible, can be rented by users. Users can drive cars, i.e., move it from one point of the simulation space to another. Cars can be re-fueled and taken to inspection by maintainers. It is assumed that a car can serve for the purpose of carsharing only for 100,000 km, then the car is replaced with absolutely identical one.<br />
<br />
===Users===<br />
<br />
Represent people holding a driving license, registered in the carsharing service and actively using it. Every tick of the simulation users decide with probability 1% whether they want to travel from the current location to somewhere else and, if so, to what coordinates of the simulation space. However, there are peak hours when most of users want to travel (for example, commute to work). It is assumed that there are 3 such hours every workday, 15 hours during the week, i.e. 9% of all the time. During these hours 50% users want to travel somewhere.<br />
<br />
Then, user starts looking for a car and, if the user finds one near by, decides if he or she wants to book it. The closer the car and the lower the price of the rent, the greater is probability that user takes the car. If user decides to rent a car, the user first books it and walks to the car. Then, user decides whether the user wants to start rent. With probability 1%, user who booked a car will decide not to start paid rent for some reason (for example, the car is dirty). When user decides not to take a car or not to start paid rent, it is assumed that the user gets to the destination point by personal car or by public transport. In the end, user who decided to travel travels anyway, by car or without it. If user travels by car, the user leaves the car exactly at the destination point. Users have the following parameters:<br />
* travel - boolean parameter indicating if user is travelling at the moment<br />
* destination (''destinationx'' and ''destinationy'') - destination where user is travelling to (applicable only if ''travel = True'')<br />
* car_assigned - car which user uses for travelling, could be ''Nobody'' if user travel not using a carsharing car (applicable only if ''travel = True'').<br />
<br />
For every user, maximum acceptable time of walking to the car before booking is 20 minutes (2 km).<br />
<br />
===Maintainers===<br />
<br />
Represent employees of carsharing company who are responsible for maintenance of the cars. They have their own vehicles (not the agent cars) and identify the cars which need maintenance in the simulation space based on the car's parameter status. The identified car is marked as out of service until maintenance is over. It is assumed that as soon as maintainer reaches the car, maintenance is done and car is again ready for rent. Maintainers have the only parameter - car_assigned - indicating the car assigned to them for maintenance (could be ''Nobody'' if no car is assigned). There are only two conditions when a car can be marked as needed maintenance:<br />
* fuel level is below 2.5 liters (for this simulation, it is number close to amount of fuel needed to drive across the square simulation space diagonal)<br />
* car exceeded another 10,000 km and requires inspection.<br />
<br />
==Simplifications==<br />
<br />
Since the carsharing system is very complex, for the purpose of this simulation some simplifications were accepted.<br />
<br />
===Space===<br />
<br />
Space of the simulation is considered uniform, i.e., there is no roads, buildings, and traffic in the simulation space. It does not matter what roads the users will drive across and how much time they will spend in traffic. On the other hand, what matters is duration of rent, which for this simplification does not depend on the traffic. The city is assumed to be of a square size 20×20 km. The simulation field is set of size 100×100 patches, which means that every patch has height and width equal to 200 m (0.2 km).<br />
<br />
===Prices===<br />
<br />
In real life, carsharing companies often offer different plans. It is normally fixed price per minute (usually depending on current demand) and packages with different duration with or without included mileage (for example, 2 hours of rent with 20 km included with fixed price per minute and per km after exceeding the included amount of time and mileage). For this simulation, only fixed prices per minute are available. The reason is that, even though some carsharing providers offer a wide range of different packages and plans, in the end final price does not differ much for each of the package.<br />
<br />
===Cars===<br />
<br />
There are several simplifications related to the cars.<br />
* First, all of them have the same fuel consumption: 7.5 l per 100 km. It means that 1 liter of fuel will cover approximately 13.33 km.<br />
* Second, it is assumed that cars do not need any maintenance except for regular inspection every 10,000 km and re-fueling.<br />
* Third, only users can drive the cars. It is assumed that maintainers do no move the cars (which could happen in real life to adjust the car locations to expected demand) and perform inspection every 10,000 km at the place where the car is located at the moment<br />
* Finally, there are only 2 types of cars: regular and premium, they have totally identical characteristics, only price differs.<br />
<br />
===Users===<br />
<br />
All the users drive cars with the same speed, 40 km/h. All of them are very careful and never have any accidents. Users drive cars only from one point in the simulation space to another, they do not drive between several points and do not leave the rent on pending (in real life, for example, some people could take a car to go for groceries and back and leave the car parked in paid rent while shopping). Without a car, users walk with the speed of 6 km/h.<br />
<br />
==Revenue and expenditures==<br />
<br />
Since the goal of the simulation is to find optimal parameters to maximize marginal profit, a task of financial calculations appears. However, calculations in the simulations are very simple. For the purpose of this simulation, Czech crowns were used as currency for all the financial operations. There is only one way to increase revenue - by renting out the cars. There are several expenditures:<br />
* fuel price (added after every refueling, by default 30 CZK per liter)<br />
* inspection cost (added for each car every inspection, assumed to be equal to 15,000 CZK)<br />
* cost of maintenance, including salary of maintainers, fuel for maintainers' vehicles, and so on (by default 10 CZK per minute).<br />
<br />
Margin profit is calculated as revenue minus expenditures minus initial expenditures. Initial expenditures include the price of the cars. It is assumed that regular car price is 400,000 CZK and premium car price is 800,000 CZK.<br />
<br />
=Results=<br />
<br />
The simulation is designed in a way that number of cars, number of users, number of maintainers, number of premium cars, rental price for normal and premium cars, fuel price, and maintenance rate are adjustable.<br />
<br />
Unfortunately, it was not possible to get actual data from a real carsharing company operating in Prague. However, according to publicly available observations in the carsharing operator's application, ratio of cars available for rent is in average 70-80%.<br />
<br />
=Conclusion=<br />
<br />
<br />
=Code=<br />
<br />
[[File:carsharing.nlogo]]</div>Shcs00http://www.simulace.info/index.php?title=Carsharing-fleet-optimization&diff=22218Carsharing-fleet-optimization2021-12-20T13:35:19Z<p>Shcs00: Shcs00 moved page Carsharing-fleet-optimization to Carsharing Fleet Optimization</p>
<hr />
<div>#REDIRECT [[Carsharing Fleet Optimization]]</div>Shcs00http://www.simulace.info/index.php?title=Carsharing_Fleet_Optimization&diff=22216Carsharing Fleet Optimization2021-12-20T13:34:40Z<p>Shcs00: Created page with "=Introduction= Recently, carsharing becomes more and more popular in large cities. Short-term rental (from several minutes to 24 hours) of a car with possibility to drop it a..."</p>
<hr />
<div>=Introduction=<br />
<br />
Recently, carsharing becomes more and more popular in large cities. Short-term rental (from several minutes to 24 hours) of a car with possibility to drop it anywhere in the allowed area in the city attracts people who, for some reason, do not want to use their own vehicles. However, it is not always convenient. If the fleet is relatively small, the probability that a car will be somewhere close by is also quite low. Cars also must be refueled or recharged sometimes by staff, which would increase cost of the fleet maintenance with increasing of the fleet size.<br />
<br />
=Problem definition=<br />
<br />
Carsharing companies have to solve a problem of optimization of their fleet size, which is not simple. The entire system of carsharing is complex and has many different parameters that must be considered for decision making. For example, if the number of cars available in the city is relatively small the maintenance is also respectively inexpensive. However, in this case, the probability that users can find a car next to their location drops drastically. On the other hand, having too many cars leads to the risk that they will stay with no use for long time. The goal of this simulation is to understand how the carsharing system behaves and propose quantitative solution on optimal number of cars and price of rent to maximize marginal profit of a hypothetical carsharing company.<br />
<br />
=Method=<br />
<br />
Since the system consists of several entities, each of them is able to some extent to make decisions, and system itself is dynamic and requires to take into account spatial factors, agent-based modelling was chosen as the most appropriate tool to design the simulation. Implementation was performed using NetLogo software platform.<br />
<br />
=Model=<br />
<br />
The model is represented by several agents and accepts some simplifications. It is assumed that the simulation will be run on ticks, every tick represents one minute of real time.<br />
<br />
==Agents==<br />
<br />
The model contains 3 types of agents: cars, users, and maintainers.<br />
<br />
===Cars===<br />
<br />
Represent the vehicles used for short-term rentals. Cars have the following characteristics:<br />
* price - cost of rental per minute<br />
* status - current status of the vehicle, can be ''idle'' (the car is ready for rent), ''booked'' (the car is booked but paid rent has not started yet), ''in rent'' (the car is taken in paid rent by some user, for the purpose of this simulation it means that the car is moving), ''needs maintenance'' (the car is not visible for users but visible for maintainers), and ''out of service'' (the car is not visible for users and maintainers, is already under maintenance by one of the maintainers)<br />
* fuel - how many liters of gas is left<br />
* mileage - for how many kilometres the car was already driven, every car must go through maintenance procedure every 10,000 kilometres<br />
* premium - boolean parameter that indicates if the car belongs to premium class<br />
* inspection - boolean parameter indicating that the car needs to undergo an inspection.<br />
<br />
Cars are located in the simulation space and, if possible, can be rented by users. Users can drive cars, i.e., move it from one point of the simulation space to another. Cars can be re-fueled and taken to inspection by maintainers. It is assumed that a car can serve for the purpose of carsharing only for 100,000 km, then the car is replaced with absolutely identical one.<br />
<br />
===Users===<br />
<br />
Represent people holding a driving license, registered in the carsharing service and actively using it. Every tick of the simulation users decide with probability 1% whether they want to travel from the current location to somewhere else and, if so, to what coordinates of the simulation space. However, there are peak hours when most of users want to travel (for example, commute to work). It is assumed that there are 3 such hours every workday, 15 hours during the week, i.e. 9% of all the time. During these hours 50% users want to travel somewhere.<br />
<br />
Then, user starts looking for a car and, if the user finds one near by, decides if he or she wants to book it. The closer the car and the lower the price of the rent, the greater is probability that user takes the car. If user decides to rent a car, the user first books it and walks to the car. Then, user decides whether the user wants to start rent. With probability 1%, user who booked a car will decide not to start paid rent for some reason (for example, the car is dirty). When user decides not to take a car or not to start paid rent, it is assumed that the user gets to the destination point by personal car or by public transport. In the end, user who decided to travel travels anyway, by car or without it. If user travels by car, the user leaves the car exactly at the destination point. Users have the following parameters:<br />
* travel - boolean parameter indicating if user is travelling at the moment<br />
* destination (''destinationx'' and ''destinationy'') - destination where user is travelling to (applicable only if ''travel = True'')<br />
* car_assigned - car which user uses for travelling, could be ''Nobody'' if user travel not using a carsharing car (applicable only if ''travel = True'').<br />
<br />
For every user, maximum acceptable time of walking to the car before booking is 20 minutes (2 km).<br />
<br />
===Maintainers===<br />
<br />
Represent employees of carsharing company who are responsible for maintenance of the cars. They have their own vehicles (not the agent cars) and identify the cars which need maintenance in the simulation space based on the car's parameter status. The identified car is marked as out of service until maintenance is over. It is assumed that as soon as maintainer reaches the car, maintenance is done and car is again ready for rent. Maintainers have the only parameter - car_assigned - indicating the car assigned to them for maintenance (could be ''Nobody'' if no car is assigned). There are only two conditions when a car can be marked as needed maintenance:<br />
* fuel level is below 2.5 liters (for this simulation, it is number close to amount of fuel needed to drive across the square simulation space diagonal)<br />
* car exceeded another 10,000 km and requires inspection.<br />
<br />
==Simplifications==<br />
<br />
Since the carsharing system is very complex, for the purpose of this simulation some simplifications were accepted.<br />
<br />
===Space===<br />
<br />
Space of the simulation is considered uniform, i.e., there is no roads, buildings, and traffic in the simulation space. It does not matter what roads the users will drive across and how much time they will spend in traffic. On the other hand, what matters is duration of rent, which for this simplification does not depend on the traffic. The city is assumed to be of a square size 20×20 km. The simulation field is set of size 100×100 patches, which means that every patch has height and width equal to 200 m (0.2 km).<br />
<br />
===Prices===<br />
<br />
In real life, carsharing companies often offer different plans. It is normally fixed price per minute (usually depending on current demand) and packages with different duration with or without included mileage (for example, 2 hours of rent with 20 km included with fixed price per minute and per km after exceeding the included amount of time and mileage). For this simulation, only fixed prices per minute are available. The reason is that, even though some carsharing providers offer a wide range of different packages and plans, in the end final price does not differ much for each of the package.<br />
<br />
===Cars===<br />
<br />
There are several simplifications related to the cars.<br />
* First, all of them have the same fuel consumption: 7.5 l per 100 km. It means that 1 liter of fuel will cover approximately 13.33 km.<br />
* Second, it is assumed that cars do not need any maintenance except for regular inspection every 10,000 km and re-fueling.<br />
* Third, only users can drive the cars. It is assumed that maintainers do no move the cars (which could happen in real life to adjust the car locations to expected demand) and perform inspection every 10,000 km at the place where the car is located at the moment<br />
* Finally, there are only 2 types of cars: regular and premium, they have totally identical characteristics, only price differs.<br />
<br />
===Users===<br />
<br />
All the users drive cars with the same speed, 40 km/h. All of them are very careful and never have any accidents. Users drive cars only from one point in the simulation space to another, they do not drive between several points and do not leave the rent on pending (in real life, for example, some people could take a car to go for groceries and back and leave the car parked in paid rent while shopping). Without a car, users walk with the speed of 6 km/h.<br />
<br />
==Revenue and expenditures==<br />
<br />
Since the goal of the simulation is to find optimal parameters to maximize marginal profit, a task of financial calculations appears. However, calculations in the simulations are very simple. For the purpose of this simulation, Czech crowns were used as currency for all the financial operations. There is only one way to increase revenue - by renting out the cars. There are several expenditures:<br />
* fuel price (added after every refueling, by default 30 CZK per liter)<br />
* inspection cost (added for each car every inspection, assumed to be equal to 15,000 CZK)<br />
* cost of maintenance, including salary of maintainers, fuel for maintainers' vehicles, and so on (by default 10 CZK per minute).<br />
<br />
Margin profit is calculated as revenue minus expenditures minus initial expenditures. Initial expenditures include the price of the cars. It is assumed that regular car price is 400,000 CZK and premium car price is 800,000 CZK.<br />
<br />
=Results=<br />
<br />
The simulation is designed in a way that number of cars, number of users, number of maintainers, number of premium cars, rental price for normal and premium cars, fuel price, and maintenance rate are adjustable.<br />
<br />
Unfortunately, it was not possible to get actual data from a real carsharing company operating in Prague. However, according to publicly available observations in the carsharing operator's application, ratio of cars available for rent is in average 70-80%.<br />
<br />
=Conclusion=<br />
<br />
<br />
=Code=<br />
<br />
[[File:carsharing.nlogo]]</div>Shcs00http://www.simulace.info/index.php?title=Assignments_WS_2021/2022&diff=22186Assignments WS 2021/20222021-12-08T11:34:55Z<p>Shcs00: </p>
<hr />
<div>{{Ambox<br />
| text = <div><br />
Please, put here your assignments. Do not forget to sign them. You can use <nowiki>~~~~</nowiki> (four tildas) for an automatic signature. Use Show preview in order to check the result before your final sumbition.<br />
</div><br />
}}<br />
<br />
{{Ambox<br />
| text = <div><br />
Please, strive to formulate your assignment carefully. We expect an adequate effort to formulate the assignment as it is your semestral paper. Do not forget that your main goal is a research paper. It means your simulation model must generate the results that are specific, measurable and verifiable. Think twice how you will develop your model, which entities you will use, draw a model diagram, consider what you will measure. No sooner than when you have a good idea about the model, submit your assignment. And of course, read [[How to deal with the simulation assignment|How to deal with the simulation assignment]].<br />
</div><br />
}}<br />
<br />
{{Ambox<br />
| text = <div><br />
Topics on gambling, cards, etc. are not welcome.<br />
</div><br />
}}<br />
<br />
{{Ambox<br />
| type = content<br />
| text = <div><br />
In order to avoid possible confusion, please, check if you have added '''approved''' in bold somewhere in our comment under your submission. If there is no '''approved''', it means the assignment was not approved yet.<br />
</div><br />
}}<br />
<br />
== Spread of covid19 in closed/open area markets ==<br />
<br />
In winter 2021 in Czechia the christmas markets were banned due to another covid19 infection wave. On the other hand people are free to go into shopping malls. It would be interesting to use existing data about covid19 virus transmission in agent based simulation to see how many people get infected and in what speed depending on whether they are in a christmas (open) market, or in a shopping mall (closed). The main goal will be to see if the simulation would backup the decision that has been made about christmas markets.<br />
<br />
Possible research papers that contain data about covid spreading<br />
* [https://www.kaggle.com/guidant/covid19-evolution-transmission-spatialpatterns/ Kaggle notebook - Covid19, Evolution, Transmission, Spatial Patterns]<br />
* [https://link.springer.com/article/10.1007/s10668-020-00884-x/ Research - Understanding COVID-19 transmission, health impacts and mitigation: timely social distancing is the key]<br />
<br />
This simulation would be realised using NetLogo.<br />
<br />
Summary:<br />
<br />
'''WHAT will be simulated'''<br />
* market place, which can be both open space or closed space.<br />
* people with or without masks, who will walk from shop to shop, with some intention and some of them will be virus carriers<br />
* virus, which will spread in places where people go through (depending on the closed/open area, the infection rates will differ)<br />
<br />
'''GOAL of the simulation'''<br />
* answer the question: "Where is the virus spread more significant? At the market place, or at the shopping mall?"<br />
<br />
'''TOOL used for the simulation'''<br />
* NetLogo<br />
* Agent based simulation<br />
<br />
'''Author:''' Angel Kostov, xkosa20<br />
<br />
== Effects of COVID-19 vaccination on the spread of infection ==<br />
<br />
<br />
'''Simulation'''<br />
<br />
Currently, there is a new wave of the COVID-19 pandemic. Although a certain percentage of the population has already been vaccinated, this is not enough to prevent further COVID-19 measures. The purpose of the simulation is to show how COVID-19 vaccination affects the spread of the pandemic. I will use an agent-based model to simulate the scenario based on existing scientific data. In addition, current COVID-19 measures are considered. <br />
<br />
'''The goal is:'''<br />
* to determine how vaccination reduces the spread of infection.<br />
<br />
'''Method'''<br />
* NetLogo<br />
<br />
'''Author:''' Laura Kundmueller<br />
<br />
== Simulation of genetic algorithm: Travelling Salesman Problem ==<br />
<br />
'''Simulation'''<br />
<br />
The topic of this simulation is an old graph problem, Travelling Salesman Problem. My approach would be based on genetic learning algorithm. A random map will be generated at the start. Salesman is travelling in a car with some gas. The gas is used as he travels, it can be recharged at gas stations but it costs money. The map contains some hills and flat roads, which have a different cost of gas when going through. <br />
<br />
'''The goal is:'''<br />
* to find the optimum path between the towns.<br />
<br />
'''The parameters are:'''<br />
* number of agents (travelling salesmen)<br />
* gas in car<br />
* money<br />
<br />
* number of towns<br />
* number of hills<br />
* number of gas stations<br />
<br />
'''Method'''<br />
* NetLogo<br />
<br />
'''Author:''' Tomáš Martínek, mart13<br />
<br />
== Optimizing the process of baking wedding sweets ==<br />
<br />
'''Simulation'''<br />
There is a wedding tradition in Czech Republic of baking wedding sweets and then handing them out to the guests of the weeding as a form of invitation. Process of baking usually takes whole day and several helpers in the kitchen are needed. Into paper baskets are usually packaged two types of sweets: several small ones with 3 different flavours and one so-called "rohový koláč". Which are then delivered by the bride to wedding guests. For the purpose of this simulation are process and needed ingredients simplified.<br />
<br />
'''The goal is:'''<br />
The goal is to optimize the number of helpers in the kitchen and find optimal amount of basic ingredients for specified number of guests.<br />
<br />
'''Method:'''<br />
Discrete simulation - SIMPROCESS<br />
<br />
'''Entities:'''<br />
* sweets<br />
* paper baskets<br />
* baking trays<br />
<br />
'''Resources'''<br />
* pastry-cooks<br />
* bride<br />
* flour<br />
* sugar<br />
* curd<br />
* plum jam<br />
* poppy seed filling<br />
<br />
'''Process steps'''<br />
* order for paper basket<br />
* preparing sweets: small ones (3 different flavours), "rohove kolače" sweets (using all flavours)<br />
* baking in the oven<br />
* sugar coating<br />
* packaging<br />
* delivery<br />
<br />
'''Data:'''<br />
* https://www.svetsvateb.cz/2021/02/623262-svatebni-kolacky/<br />
* https://megvkuchyni.cz/recepty/speciality/svatebni-special-jak-na-svatebni-kolacky/<br />
* experience<br />
<br />
'''Author:''' [[User:Cerm18|Michaela Červinková (cerm18)]] ([[User talk:Cerm18|talk]]) 10:16, 8 December 2021 (CET)<br />
<br />
== Carsharing company fleet optimization ==<br />
<br />
'''Problem definition'''<br />
<br />
Recently, carsharing becomes more and more popular in large cities. Short-term rental (from several minutes to 24 hours) of a car with possibility to drop it anywhere in the allowed area in the city attracts people who for some reasons do not want to use their own vehicles. However, it is not always convenient. If the fleet is relatively small, the probability that a car will be somewhere close by is also quite low. Cars also must be refueled or recharged sometimes by external staff, which would increase cost of the fleet maintenance with increasing of the fleet size.<br />
<br />
'''Simulation'''<br />
<br />
The proposing agent-based simulation will reproduce real situation with shared cars.<br />
Two types of agents are planned:<br />
* cars with different states (waiting, in rent, maintenance) and characteristics (mileage, fuel level)<br />
* drivers - users of the service, who rent the cars and have their own behavior, including decision making on taking a car, driving style, and so on.<br />
Some data for the model will be obtained as personal observations of two carsharing services operating in Prague, [https://anytimecar.cz/ Anytime] and [https://www.uniqway.cz/ Uniqway] (for example, number of available cars, which is visible in mobile applications). Another source of data would be statistics collected by other services abroad, for example, by operating in Russia service Yandex.Drive[https://www.statista.com/statistics/1224178/daily-use-duration-of-car-sharing-vehicles-in-moscow-by-vehicle-type/].<br />
<br />
'''The goal is:'''<br />
to find out optimal fleet size and structure and price policy to maximize revenue of a carsharing company.<br />
<br />
'''Method:'''<br />
agent-based simulation - NetLogo<br />
<br />
'''Author:''' [[User:Shcs00|Sergei Shcherbinin (shcs00)]] ([[User talk:Shcs00|talk]]) 12:34, 8 December 2021 (CET)</div>Shcs00