Difference between revisions of "Assignments WS 2024/2025"

From Simulace.info
Jump to: navigation, search
 
(50 intermediate revisions by 17 users not shown)
Line 51: Line 51:
 
</div>
 
</div>
 
}}
 
}}
 +
 +
==Ant Colony==
 +
 +
'''What will be simulated:'''
 +
*Ant colony growth
 +
 +
'''Goal of the simulation:'''
 +
*The simulation aims to demonstrate how the complex, organized behaviors of an ant colony emerge from simple, decentralized rules followed by individual ants.
 +
 +
'''Who would use the simulation and how it helps them:'''
 +
*There is a diverse list of potential users of this simulation.
 +
**Biologists can use the simulation to study and analyze the behavior of individual ants, their collective actions, and the emergent behavior of the ant colony.
 +
**Biology educators can use this simulation as an engaging, interactive tool to demonstrate how the complex, organized behaviors of an ant colony emerge from simple, decentralized rules followed by individual ants.
 +
**Exotic cuisine chefs can use this simulation to predict and optimize ant colony growth. This allows them to manage colonies sustainably and maximize the yield of their unique ingredient.
 +
 +
'''Method and simulation environment:'''
 +
*Method: Multiagent simulation
 +
*Simulation environment: NetLogo
 +
 +
'''Variables in the model:'''
 +
*Deterministic Variables:
 +
**Queen's Egg-Laying Rate
 +
**Egg Development Time
 +
**Worker Task Allocation
 +
**Environmental Constants
 +
*Random Variables:
 +
**Egg Survival Rate
 +
**Worker Behavior
 +
**Worker Lifespan
 +
**Environmental Threats
 +
 +
'''Data sources:'''
 +
*Observational data
 +
*Research articles
 +
 +
[[User:Spis03|Spis03]] ([[User talk:Spis03|talk]]) 14:33, 9 December 2024 (CET)
 +
 +
'''APPROVED''' [[User:Tomáš|Tomáš]] ([[User talk:Tomáš|talk]]) 16:28, 17 December 2024 (CET)
 +
----
 +
 +
 +
'''Assignment Proposal (Draft) Title:'''
 +
*Simulation of pension reform in the Czech Republic: Analysis of long-term sustainability
 +
 +
'''What will be simulated:'''
 +
*A system dynamics model of the Czech pension system that simulates the long-term financial sustainability under varying demographic, economic, and policy scenarios. The simulation will project future balances of the pension system, incorporating the flows of revenues (social insurance contributions) and expenditures (pension payouts)
 +
 +
'''Goal of the simulation (What problem should the simulation solve):'''
 +
*The main goal is to analyze how different pension reform strategies (e.g., adjusting retirement age, altering contribution rates, changing the indexation formula of pensions) will affect the long-term stability of the Czech pension system. The simulation aims to identify specific policy levers and thresholds that ensure the pension system’s financial equilibrium over a multi-decade horizon, despite changing demographic and economic conditions.
 +
 +
'''Who would use the simulation and how it helps them:'''
 +
*The potential users include not only the Ministry of Finance, the Ministry of Labour and Social Affairs, but also the general public and the media. Although the model does not simulate the pension system in complete detail, it provides a general overview and helps users understand the basic mechanisms and trends that will shape the future of the pension system. In this way, users can:
 +
**Gain a preliminary orientation and inspiration: By experimenting with simple scenarios (e.g., raising the retirement age or altering contribution rates), users can gain a clearer picture of how different reform steps could influence the stability of the pension system.
 +
**Provide context for public debate: The model can assist citizens, journalists, and non-profit organizations in better understanding the issues surrounding pension reform. This allows them to critically evaluate political proposals or expert recommendations.
 +
**Lead to more informed decision-making: While this is not a tool for detailed macroeconomic forecasting, the simulation provides a general insight into potential long-term trends. This can contribute to a broader understanding of the necessity for reforms and their impact on future generations.
 +
 +
'''Method and simulation environment:'''
 +
 +
*Method: System Dynamics
 +
*Simulation environment: Vensim PLE (freely available for academic use)
 +
 +
'''Variables in the model (deterministic and random):'''
 +
 +
*Core Population Variables:
 +
**Number of children (new entrants to future workforce)
 +
**Number of working-age population (workers contributing to the system)
 +
**Number of pensioners (beneficiaries)
 +
 +
*Policy Variables:
 +
**Statutory retirement age
 +
**Contribution rate to social insurance (percentage of wage)
 +
**Pension benefit formula and indexation mechanism
 +
 +
*Economic Variables:
 +
**Average wage (influences contributions)
 +
**Inflation rate (influences indexation of pensions and wage growth)
 +
 +
*Fiscal Variables:
 +
**Total contributions collected (based on number of workers, contribution rate, and average wage)
 +
**Total pension expenditure (based on number of pensioners and average pension)
 +
**Pension system reserve fund (if applicable) and its depletion or accumulation
 +
 +
*Random Variables:
 +
**The model will incorporate stochastic elements through probability distributions derived from historical data and OECD/EUROSTAT projections to reflect uncertainty in:
 +
***Fertility rate (affects future workforce size; random from projected distribution)
 +
***Mortality rate / Life expectancy changes (stochastic variation around central OECD forecasts)
 +
***Inflation rate (stochastic variation around central forecast from CNB/OECD data)
 +
***Retirement rate (number of people retire each year +-)
 +
 +
'''Data sources (for deterministic baseline and to derive distributions):'''
 +
*Czech Statistical Office (ČSÚ) for historical demographic data
 +
*OECD demographic and economic projections for Czech Republic
 +
*Eurostat long-term demographic projections for EU countries
 +
 +
'''Formulas in the simulation (examples):'''
 +
*Pension Expenditure: Total Pension Expenditure = Number of Pensioners * Average Pension
 +
*Average Pension Calculation: Average Pension(t+1) = Average Pension(t) * (1 + InflationIndex)
 +
*Contribution Revenue: Total Contributions = Number of Workers * Average Wage * Contribution Rate
 +
*System Balance: Annual Balance = Total Contributions - Total Pension Expenditure
 +
*Accumulation or depletion of the pension reserve fund is then modeled as a stock: Reserve(t+1) = Reserve(t) + Annual Balance.
 +
 +
'''Model complexity and data linking:'''
 +
*'''Causal loop diagrams (CLD):''' Will illustrate feedback loops such as how employment and wage growth influence contributions, and how demographic changes influence the ratio of workers to retirees.
 +
*'''Stock and Flow Diagrams:''' Will detail population stocks (children, workers, retirees), and financial stocks (pension fund reserves), along with flows (entrants to workforce, retirees, death rates, pension contributions, and payouts).
 +
 +
'''Specific, measurable, and verifiable results:'''
 +
*Specificity: The model will project the pension system’s financial status from year X to year X+50 under various reform scenarios, providing exact quantitative outcomes (e.g., fund balance in billions CZK, pension-to-wage ratio).
 +
 +
*Measurable metrics:
 +
**Dependency ratio (number of pensioners per 100 workers)
 +
**Pension system annual balance (CZK) and cumulative reserves over time
 +
**Average replacement rate (pension/average wage ratio)
 +
**Sensitivity of sustainability gap to changes in retirement age or contribution rate
 +
 +
*Verifiability: The initial model run will be calibrated against historical data for the past decade. Adjustments to parameters and comparison with known OECD and ČSÚ forecasts will verify the model’s credibility.
 +
 +
[[User:Omaj01|Omaj01]] ([[User talk:Omaj01|talk]])
 +
::'''APPROVED'''[[User:Oleg.Svatos|Oleg.Svatos]] ([[User talk:Oleg.Svatos|talk]]) 17:57, 6 December 2024 (CET)
 +
 +
 +
----
 +
 +
 +
==Simulation concept – Invasive Plant Species vs. Native Plants vs. Herbivores Jan César (cesj05)==
 +
 +
''' Objectives: '''
 +
 +
Understand the dynamics of competition between invasive plant species and native plants in a shared environment
 +
 +
Explore the conditions under which either the invasive species dominates, coexists, or fails to establish.
 +
 +
''' Environment: '''
 +
 +
Each patch represents a piece of land that can grow either a natrive or invasive plant (or remain empty)
 +
 +
Plants compete for resources on each path
 +
 +
''' Agents: '''
 +
 +
Native Plants: Slower growth but more resistant to herbivores or harsh conditions.
 +
 +
Invasive Plants: Faster growth and higher seed dispersal rate but less resistant to herbivores.
 +
 +
Herbivores: Agents that eat plants, with a preference for invasive or native species (modifiable by the user).
 +
 +
''' Methods '''
 +
 +
Initialization:
 +
 +
Randomly populate the grid with a mix of invasive and native plants.
 +
 +
Set up resource levels for each patch.
 +
 +
Place herbivores randomly across the grid.
 +
 +
 +
''' Simulation Steps (Turtles/Agents): '''
 +
 +
Each plant (agent) checks:
 +
 +
Whether it has resources to grow or reproduce.
 +
 +
If conditions are favorable, it spreads seeds to nearby patches.
 +
 +
Herbivores move and consume plants on the patches they visit.
 +
 +
Competition between plants on shared patches determines which survives.
 +
 +
 +
Interaction Dynamics: Modify the probability of herbivory or the effectiveness of seed dispersal as sliders to explore different scenarios.
 +
 +
 +
The simulation will be done in NetLogo, as for the data, I have chosen these plants:
 +
 +
''' Kudzu (Pueraria montana) '''
 +
 +
Growth Rate: Kudzu is renowned for its rapid growth, capable of extending up to 0.3 meters (1 foot) per day, with mature vines reaching lengths of 30 meters (98 feet).
 +
 +
 +
Resource Utilization: As a nitrogen-fixing plant, kudzu thrives in nitrogen-deficient soils, enhancing its competitive advantage in such environments.
 +
 +
 +
Competitive Strategy: Kudzu's aggressive growth allows it to overtop and shade native vegetation, effectively outcompeting other species for sunlight and space.
 +
 +
 +
''' Purple Coneflower (Echinacea purpurea) '''
 +
 +
Growth Characteristics: This perennial herb typically grows to heights of 1 to 3 feet (approximately 0.3 to 0.9 meters) and produces a woody rhizome.
 +
 +
 +
Resource Requirements: Purple coneflower prefers sunny sites with low levels of competition and soils rich in magnesium and calcium.
 +
 +
 +
Competitive Ability: While it can coexist with other species, purple coneflower may require management to prevent being outcompeted by more aggressive plants.
 +
 +
This description of chosen plant species will be used to set up their behaviour in NetLogo.
 +
 +
''' Resources: '''
 +
 +
For Kudzu (Pueraria montana):
 +
 +
Forest Service, U.S. Department of Agriculture. (n.d.). Pueraria montana var. lobata: Kudzu. Retrieved from https://www.fs.usda.gov/database/feis/plants/vine/puemonl/all.html
 +
 +
National Center for Biotechnology Information. (2024). PMC Article on Kudzu Growth Dynamics. Retrieved from https://pmc.ncbi.nlm.nih.gov/articles/PMC9824185/
 +
 +
Wikipedia contributors. (n.d.). Kudzu in the United States. Retrieved from https://en.wikipedia.org/wiki/Kudzu_in_the_United_States
 +
 +
For Purple Coneflower (Echinacea purpurea):
 +
 +
USDA Natural Resources Conservation Service. (n.d.). Plant guide: Echinacea purpurea. Retrieved from https://plants.usda.gov/DocumentLibrary/plantguide/pdf/pg_ecan2.pdf
 +
 +
Plant Delights Nursery. (n.d.). Purple Coneflower (Echinacea purpurea). Retrieved from https://www.plantdelights.com/blogs/articles/purple-coneflower-echinacea-purpurea-plant
 +
 +
USDA Natural Resources Conservation Service. (n.d.). Echinacea purpurea Fact Sheet. Retrieved from https://plants.usda.gov/DocumentLibrary/factsheet/pdf/fs_ecpu.pdf
 +
 +
 +
 +
 +
If needed, more studies will be used.
 +
 +
This simulation can be used by gardeners trying to maintain their garden.  [[User:Cesj05|Cesj05]] ([[User talk:Cesj05|talk]]) 17:53, 6 December 2024 (CET)
 +
----
 +
It is necessary to use real-world data. For simplicity sake, I strongly recommend to pick a particular specie or a couple species where are you able obtain data. Otherwise the task wouldn't be verifiable. [[User:Tomáš|Tomáš]] ([[User talk:Tomáš|talk]]) 16:33, 17 December 2024 (CET)
 +
 +
 +
Updated - particular species chosen with attributes and resources, I hope it is alright, Mr. Svatoš already told me on class that if I provided some relevant resources, it should be approved without a problem (meaning even without specifically chosen plant species), thank you [[User:Cesj05|Cesj05]] ([[User talk:Cesj05|talk]]) 13:23, 20 December 2024 (CET)
 +
'''APPROVED''' [[User:Tomáš|Tomáš]] ([[User talk:Tomáš|talk]]) 14:00, 20 December 2024 (CET)
 +
== Simulation Concept – Traffic Accident Risk Analysis ==
 +
 +
=== Objectives ===
 +
* Understand the dynamics of traffic accidents based on road conditions, traffic density, and driver behavior.
 +
* Explore the conditions under which accidents become frequent, and how they impact overall traffic flow.
 +
* Test mitigation strategies like improved road quality or stricter speed limits.
 +
 +
=== Environment ===
 +
* '''Patches''': Represent road segments and intersections, each with a defined condition:
 +
** '''Good''': Low accident probability.
 +
** '''Bad''': Increased accident probability.
 +
** '''Under Construction''': High accident probability and slower movement for cars.
 +
* '''Road Network''': A grid-based layout with straight roads and intersections where traffic can flow.
 +
 +
=== Agents ===
 +
# '''Cars (Turtles):'''
 +
## Each car has a speed, a destination, and a probability of making a driving error.
 +
## Movement is influenced by traffic density and road conditions.
 +
# '''Accidents:'''
 +
## Simulated as blocked road segments.
 +
## Cause delays and force cars to reroute.
 +
# '''Traffic Lights (Optional):'''
 +
## Located at intersections to control flow.
 +
## Can be toggled on/off to explore their impact on accidents.
 +
 +
=== Methods ===
 +
==== Initialization ====
 +
* Randomly distribute cars across the road network with initial speeds and destinations.
 +
* Assign random conditions (good, bad, under construction) to road segments based on user input.
 +
 +
==== Simulation Steps (Turtles/Agents) ====
 +
# '''Movement:'''
 +
## Cars follow road segments, moving faster on good roads and slower on bad/under-construction ones.
 +
# '''Accident Risk:'''
 +
## Probability of an accident increases with:
 +
### Poor road conditions.
 +
### High speed.
 +
### High traffic density.
 +
# '''Accident Handling:'''
 +
## If an accident occurs, the road segment is temporarily blocked.
 +
## Cars reroute to avoid the blocked segment, increasing congestion elsewhere.
 +
# '''Recovery:'''
 +
## Accidents are cleared after a set duration, restoring traffic flow.
 +
 +
==== Interaction Dynamics ====
 +
* '''User Controls:'''
 +
** Traffic density, road condition distribution, speed limits, and driver error probabilities can be adjusted with sliders.
 +
* '''Scenarios:'''
 +
** Test high traffic density with poor roads versus low traffic density with good roads.
 +
** Simulate stricter traffic laws by reducing driver errors and imposing speed limits.
 +
 +
=== Simulation Details ===
 +
* '''Platform''': NetLogo.
 +
* '''Data Source''': Synthetic data will be used to mimic real-world traffic dynamics based on studies and assumptions.
 +
* '''Behavior Setup''': Modeled on findings from traffic and safety research:
 +
** [https://www.tandfonline.com/doi/full/10.1080/13669877.2010.547259 Study 1]
 +
** [https://www.tandfonline.com/doi/pdf/10.1080/23311916.2020.1834659 Study 2]
 +
** [https://www.tandfonline.com/doi/pdf/10.1080/16483840.2003.10414070 Study 3]
 +
* Additional studies will be incorporated if needed to refine parameters.
 +
[[User:Sim timm03|Sim timm03]] ([[User talk:Sim timm03|talk]]) 16:11, 7 December 2024 (CET)
 +
 +
: '''APPROVED''' Dont forget to keep the model testable, meaning all parameters should have a reasonable justification. [[User:Tomáš|Tomáš]] ([[User talk:Tomáš|talk]]) 14:02, 20 December 2024 (CET)
 +
 +
= Assignment Proposal (Draft) =
 +
 +
== Title ==
 +
'''Simulation of Security Efficiency in a Store: Analyzing Optimal Guard Allocation Based on Obstruction and Escape Dynamics'''
 +
 +
== What will be simulated ==
 +
*A simulation of a store environment where security guards patrol to prevent thieves from stealing goods and escaping through designated exits. The store layout includes customizable obstacles (regals), guards, and thieves. The simulation focuses on the limited visibility due to obstacles and models the dynamic interaction between guards and thieves, exploring how the required number of guards changes based on the number of thieves.*
 +
 +
== Goal of the simulation (What problem should the simulation solve) ==
 +
*The simulation aims to determine the optimal number of guards needed to secure a store effectively under varying conditions of thief count. The ultimate goal is to provide recommendations for store security design based on quantitative analysis.*
 +
 +
== Who would use the simulation and how it helps them ==
 +
*Store Managers and Security Companies*: Helps in designing security layouts and determining the number of security guards needed to maximize efficiency and minimize theft. 
 +
*Students*: Offers insights into visibility-limited environments and agent-based modeling techniques.
 +
 +
== Method and simulation environment ==
 +
* '''Method''': Agent-based modeling 
 +
* '''Simulation environment''': NetLogo 
 +
 +
== Variables in the model (deterministic and random) ==
 +
 +
=== Deterministic Variables ===
 +
* Number of guards 
 +
* Number of thieves 
 +
* Number of regals (obstacles): Fixed positions 
 +
* Store size: 
 +
* Guard and thief placement: Guards are placed on opposite sides of the store to maximize coverage; thieves are placed randomly.
 +
 +
=== Random Variables ===
 +
* Movement paths: Thieves and guards move dynamically based on patrol or escape strategies. 
 +
* Thief behavior: Randomized target selection for obstacles and exits. 
 +
* Guard patrol patterns: Random movement within patrol zones unless a thief is spotted. 
 +
 +
== Formulas in the simulation (examples) ==
 +
* '''Guard visibility''': 
 +
  * \( \text{Visible range} = d \), where \( d \) is the number of unobstructed cells (line of sight blocked by obstacles). 
 +
* '''Thief capture condition''': 
 +
  * A thief is captured if a guard moves onto the same cell. 
 +
* '''Escape success''': 
 +
  * A thief escapes if it reaches an exit before being captured. 
 +
* '''Capture efficiency''': 
 +
  * \( \text{Efficiency} = \frac{\text{Captured thieves}}{\text{Total thieves}} \) 
 +
 +
== Model complexity and data linking ==
 +
* '''Guard and thief dynamics''': 
 +
  * Guards patrol predefined zones or reactively chase thieves if spotted. 
 +
  * Thieves move toward regals to "steal" and then to exits to escape. 
 +
* '''Obstacle placement''': 
 +
  * Regals are fixed in predefined locations that block visibility and movement. 
 +
* '''Outputs''': 
 +
  * Capture success rate 
 +
  * Number of escaped thieves 
 +
  * Guard efficiency metrics 
 +
 +
== Specific, measurable, and verifiable results ==
 +
* '''Specificity''': 
 +
  * The model provides quantitative insights into the number of guards needed to maintain security across various scenarios. 
 +
* '''Measurable metrics''': 
 +
  * Capture rate (% of thieves caught) 
 +
  * Escape rate (% of thieves successfully escaped) 
 +
  * Average patrol effectiveness (distance covered by guards and time to interception). 
 +
 +
== Key questions the simulation will answer ==
 +
# How does the number of guards required to secure the store change with varying numbers of thieves? 
 +
# What are the most effective patrol strategies for guards in a fixed environment with limited visibility? 
 +
# How does the coordination or randomness of thieves’ behavior influence the effectiveness of the store's security? 
 +
 +
[[User:Holp11|Holp11]] ([[User talk:Holp11|talk]]) 21:06, 7 December 2024 (CET)
 +
 +
: '''APPROVED''', but: under all circumstances, obtain real data and base the simulation upon them. This simulation is relatively simple to develop, the real data are what could make it valuable. [[User:Tomáš|Tomáš]] ([[User talk:Tomáš|talk]]) 14:25, 20 December 2024 (CET)
 +
 +
== Customers at Traditional and Self-Service Checkouts ==
 +
 +
=== Topic ===
 +
'''Simulation of the customer check-in process at the checkout''', including incoming customers, their checkout selection (including self-service options), queuing, and service. The model reflects different service speeds, customer behavior (e.g., transitioning between checkouts), and satisfaction levels.
 +
 +
=== Problem ===
 +
The supermarket lacks rules for opening and closing checkouts, resulting in either excessive staff costs or low customer satisfaction. Data-based rules for checkout operations can optimize efficiency and satisfaction.
 +
 +
=== Goal ===
 +
Establish optimal rules for opening and closing checkouts to maintain customer satisfaction above 70%.
 +
 +
=== Simulation Stakeholders ===
 +
* '''HR Managers:''' Determine employee requirements per shift.
 +
* '''Shift Leaders:''' Establish rules for opening new checkouts.
 +
* '''Financial Manager:''' Optimize employee costs.
 +
 +
== Method ==
 +
* '''Platform:''' NetLogo
 +
* '''Method:''' Agent-based simulation
 +
 +
== Requirements ==
 +
 +
=== Reality Abstraction Plan ===
 +
 +
==== Customers ====
 +
* '''Number of Items in Purchase:''' Lognormal distribution (µ=3, σ=0.3).
 +
* '''Checkout Type Preference:'''
 +
    * Items > 20: Preference = 1 (regular checkouts only).
 +
    * Items > 10: Lognormal distribution on scale 1-100 (µ=2.8, σ=0.7).
 +
    * Items ≤ 10: 100 - (Lognormal distribution on scale 1-100, µ=2.8, σ=0.7).
 +
* '''Willingness to Switch Checkouts:''' Lognormal distribution on scale 1-100 (µ=2.9, σ=0.4). Drops to half after switching.
 +
* '''Satisfaction:''' Depends on waiting time, switching, and checkout type.
 +
    * Initial value: Normal distribution (mean=95, std=5).
 +
    * '''Waiting Time:'''
 +
        * ≤ 3 min: No change.
 +
        * > 3 min: Decreases logarithmically: \( S(t) = 100 - 10 \cdot \ln(1 + (t - 3)) \).
 +
    * '''Switching Checkouts:'''
 +
        * Willingness > 80: No change.
 +
        * Willingness ≤ 80: Decreases by a range (e.g., 1-5 points for willingness ≤ 80 & > 60).
 +
    * '''Checkout Type:''' Satisfaction changes based on preference and actual service type (e.g., increases by 5-10 points if preference > 60 and served at self-checkout).
 +
    * Satisfaction cannot be negative.
 +
* '''Goal:''' Leave the supermarket as satisfied as possible.
 +
 +
==== Checkouts ====
 +
* '''Regular Checkouts (Count: 5):'''
 +
    * '''Service Speed:'''
 +
        * Payment: Normal distribution (mean=1 min, std=0.2).
 +
        * Marking Items: 80% EAN-coded items (mean=0.02 min, std=0.01); 20% non-EAN (mean=0.03 min, std=0.01).
 +
    * '''Checkout Error:''' 0.1% probability; solving time = Normal distribution (mean=0.5 min, std=0.1).
 +
* '''Self-Service Checkouts (Count: 8):'''
 +
    * '''Service Speed:'''
 +
        * Payment: Normal distribution (mean=1.2 min, std=0.3).
 +
        * Marking Items: 80% EAN-coded items (mean=0.03 min, std=0.01); 20% non-EAN (mean=0.04 min, std=0.01).
 +
    * '''Checkout Error:''' 1% probability; solving time = Normal distribution (mean=0.5 min, std=0.1).
 +
 +
=== Simulation Rules ===
 +
* '''Operating Hours:''' 7:00-20:00 (1 average day).
 +
* '''Customer Arrivals:'''
 +
    * Peak Hours (7:00-10:00 & 16:00-18:00): Normal distribution (mean=4, std=1).
 +
    * Non-Peak Hours (10:00-16:00 & 18:00-20:00): Normal distribution (mean=2, std=1).
 +
* '''Goal of Checkouts:''' Maintain customer satisfaction above 70% with minimal open regular checkouts.
 +
* The simulation will not address scenarios outside the checkout area.
 +
* One customer corresponds to one purchase.
 +
 +
 +
 +
[[User:Rysc00|Rysc00]] ([[User talk:Rysc00|talk]]) 13:23, 08 December 2024 (CET)
 +
 +
: Please, elaborate it. What will be the real data you will base it on. What supermarket/store.?
 +
: BTW: Don't use HTML for editing these documents, Wiki uses Markup. Using HTML makes the document messy.
 +
 +
Update: The mentioned supermarket is supposed to be Tesco in Vodňany, my hometown. The supermarket will not share exact data with me - the values are based on my own experience and observation. Is that a sufficient base for the simulation? Obtaining such data from the supermarket is not realistic, and as to any other sources - research papers on this topic are not from the same socio-geographical background, which influences customer behavior a lot. The simulation would be less realistic if I based it on research papers.
 +
 +
[[User:Rysc00|Rysc00]] ([[User talk:Rysc00|talk]]) 22:17, 20 December 2024 (CET)
 +
 +
= What you will simulate: =
 +
# I will simulate the process of artificially snowing a ski slope, including the operation of snow cannons, and the influence of temperature, humidity, and wind on snow production and the maintenance of a snow cover.
 +
 +
== The goal of the simulation: ==
 +
# The objective is to optimize the snowmaking process to achieve the desired snow cover height at the lowest possible energy and water costs, while accounting for changing weather conditions.
 +
 +
== Who would actually use such simulation and how: ==
 +
# A typical user might be a ski resort manager or the operator of snowmaking equipment. The simulation would help them plan and optimize their snowmaking strategy in advance, reduce operational costs, and ensure quality snow conditions for skiers.
 +
 +
== What method and simulation environment: ==
 +
# Multi-agent simulation in NetLogo
 +
 +
== What variables will be incorporated: ==
 +
# Deterministic variables: the placement of snow cannons, the energy demands of the snow cannons, and the target snow cover height.
 +
# State variables: the current snow depth on the slope, and the current water and energy consumption.
 +
 +
== What variables will be random: ==
 +
# Weather conditions (temperature, humidity, wind, and any natural snowfall) will be generated with random fluctuations within the range of observed real-world values.
 +
 +
== What exact data you will base values of your variables on: ==
 +
# The values for weather and the performance of snow cannons will be based on literature and technical specifications from manufacturers (average seasonal temperatures, typical humidity ranges, average efficiency of snow cannons).
 +
 +
[[User:Lanm14|Lanm14]] ([[User talk:Lanm14|talk]]) 15:00, 08 December 2024 (CET)
 +
 +
: '''APPROVED''' [[User:Tomáš|Tomáš]] ([[User talk:Tomáš|talk]]) 14:32, 20 December 2024 (CET)
 +
 +
 +
=Lightning Network Channel Dynamics Simulation=
 +
 +
<p>The Lightning Network represents a promising solution to Bitcoin's scalability challenges, enabling fast and low-cost transactions. In the Czech Republic, it's gaining practical adoption with merchants like Alza.cz, Rohlik.cz and payment processors like Qerko and GoPay.</p>
 +
<p> The network consists of payment channels, direct connections between two participants. Each channel has a fixed capacity, representing the total funds locked in for transactions. This capacity is shared between the two participants, with each holding a portion of the total on his side of the channel. Payments update the balance distribution within the channel. If two participants don’t have a direct channel, the network routes payments through connected channels, relying on intermediary nodes with enough capacity to complete the transfer. </p>
 +
<h2>What will be simulated:</h2>
 +
 +
<p>A NetLogo agent-based simulation of Lightning Network payment channels that models:</p>
 +
<ul>
 +
    <li>Nodes (merchants, customers, routing nodes) as agents with defined balances and behaviors</li>
 +
    <li>Payment channels as links between nodes with specific capacities</li>
 +
    <li>Transaction routing through the network</li>
 +
    <li>Channel balance changes and payment success/failure dynamics</li>
 +
</ul>
 +
 +
<h2>Goal of the simulation:</h2>
 +
 +
<p>To analyze how different network configurations affect payment success rates and channel efficiency, specifically:</p>
 +
<ul>
 +
    <li>Identify optimal channel capacity distribution for maximizing successful payments</li>
 +
    <li>Determine relationship between node connectivity and network reliability</li>
 +
    <li>Find bottlenecks in payment routing that cause transaction failures</li>
 +
</ul>
 +
 +
<h2>Who would use the simulation and how it helps them:</h2>
 +
 +
<p>Primary users:</p>
 +
<ol>
 +
    <li>New merchants considering Lightning Network adoption:
 +
        <ul>
 +
            <li>Understand required number of payment channels</li>
 +
            <li>Plan initial channel capacity requirements</li>
 +
            <li>Estimate liquidity needs</li>
 +
        </ul>
 +
    </li>
 +
    <li>Lightning Network node operators:
 +
        <ul>
 +
            <li>Optimize channel configurations</li>
 +
            <li>Understand routing effectiveness</li>
 +
            <li>Plan capital allocation</li>
 +
        </ul>
 +
    </li>
 +
</ol>
 +
 +
<h2>Method and simulation environment:</h2>
 +
 +
<ul>
 +
    <li>Method: Agent-based modeling</li>
 +
    <li>Environment: NetLogo</li>
 +
</ul>
 +
 +
<h2>Variables incorporated:</h2>
 +
 +
<h3>Deterministic Variables:</h3>
 +
<ol>
 +
    <li>Number of nodes (N):
 +
        <ul>
 +
            <li>Initial setup: 100-200 nodes</li>
 +
            <li>Based on small subset of real network for feasibility</li>
 +
            <li>Can be adjusted via interface slider</li>
 +
        </ul>
 +
    </li>
 +
    <li>Initial channel capacity (C):
 +
        <ul>
 +
            <li>Range: 0.001 - 0.1 BTC per channel</li>
 +
            <li>Based on average values from 1ML.com statistics</li>
 +
            <li>Set at channel creation time</li>
 +
        </ul>
 +
    </li>
 +
    <li>Node types:
 +
        <ul>
 +
            <li>Merchant: 20% of nodes</li>
 +
            <li>Customer: 70% of nodes</li>
 +
            <li>Routing-node: 10% of nodes</li>
 +
            <li>Proportions based on network analysis papers</li>
 +
        </ul>
 +
    </li>
 +
    <li>Base fee per transaction:
 +
        <ul>
 +
            <li>Default: 1 satoshi base + 0.001% of amount</li>
 +
            <li>Based on common Lightning node configurations</li>
 +
        </ul>
 +
    </li>
 +
    <li>Network topology structure:
 +
        <ul>
 +
            <li>Average connections per node: 3-8</li>
 +
            <li>Based on observed network patterns</li>
 +
            <li>Follows power-law distribution</li>
 +
        </ul>
 +
    </li>
 +
</ol>
 +
 +
<h3>Random Variables:</h3>
 +
<ol>
 +
    <li>Transaction amounts:
 +
        <ul>
 +
            <li>Distribution: Log-normal</li>
 +
            <li>Mean: 50,000 satoshis</li>
 +
            <li>Standard deviation: 25,000 satoshis</li>
 +
            <li>Based on public Lightning Network statistics</li>
 +
        </ul>
 +
    </li>
 +
    <li>Transaction timing:
 +
        <ul>
 +
            <li>Poisson distribution</li>
 +
            <li>Mean arrival rate (λ): 0.1 transactions per node per minute</li>
 +
            <li>Can be adjusted via interface slider</li>
 +
        </ul>
 +
    </li>
 +
    <li>Channel balance fluctuations:
 +
        <ul>
 +
            <li>Random walk within channel capacity</li>
 +
            <li>Step size: Normal distribution (μ=0, σ=0.01 × capacity)</li>
 +
            <li>Updates every simulation tick</li>
 +
        </ul>
 +
    </li>
 +
    <li>Node connection preferences:
 +
        <ul>
 +
            <li>Probability of connection decreases with distance</li>
 +
            <li>Weighted by node type and existing connections</li>
 +
            <li>Uses preferential attachment model</li>
 +
        </ul>
 +
    </li>
 +
    <li>Payment success probability:
 +
        <ul>
 +
            <li>Base probability: 0.95</li>
 +
            <li>Modified by:
 +
                <ul>
 +
                    <li>Channel capacity utilization</li>
 +
                    <li>Path length</li>
 +
                    <li>Node type</li>
 +
                </ul>
 +
            </li>
 +
        </ul>
 +
    </li>
 +
</ol>
 +
 +
<h2>Data sources for variable values:</h2>
 +
 +
<ol>
 +
    <li>Network structure and capacities:
 +
        <ul>
 +
            <li>Public Lightning Network explorer (1ML.com):
 +
                <ul>
 +
                    <li>Current number of nodes (~17,000)</li>
 +
                    <li>Average channel capacity (~0.03 BTC)</li>
 +
                    <li>Node distribution and connectivity patterns</li>
 +
                </ul>
 +
            </li>
 +
            <li>Mempool.space statistics:
 +
                <ul>
 +
                    <li>Total network capacity</li>
 +
                    <li>Channel count</li>
 +
                    <li>Node count</li>
 +
                </ul>
 +
            </li>
 +
        </ul>
 +
    </li>
 +
    <li>Transaction patterns:
 +
        <ul>
 +
            <li>Public Lightning Network statistics from Bitcoin Visuals (bitcoinvisuals.com)</li>
 +
            <li>Academic research papers on Lightning Network analysis:
 +
                <ul>
 +
                    <li>"Lightning Network: a second path towards centralisation of the Bitcoin economy" (Lin et al., 2020)</li>
 +
                    <li>"A Quantitative Analysis of Security, Anonymity and Scalability for the Lightning Network" (Tikhomirov et al., 2020)</li>
 +
                </ul>
 +
            </li>
 +
        </ul>
 +
    </li>
 +
</ol>
 +
 +
<h2>Simulation behavior formulas based on:</h2>
 +
 +
<ol>
 +
    <li>Payment routing:
 +
        <ul>
 +
            <li>Lightning Network specifications (BOLTs) from lightning-rfc repository</li>
 +
            <li>LND implementation documentation</li>
 +
            <li>Published research on routing behavior</li>
 +
        </ul>
 +
    </li>
 +
    <li>Channel balancing:
 +
        <ul>
 +
            <li>Lightning Network whitepaper formulas</li>
 +
            <li>Public node operation best practices</li>
 +
            <li>Academic analysis of channel dynamics</li>
 +
        </ul>
 +
    </li>
 +
</ol>
 +
 +
[[User:Filip Simulátor|mikf02]] ([[User talk:Filip Simulátor|talk]]) 19:58, 8 December 2024 (CET)
 +
 +
: '''APPROVED''' Don't use HTML for writing WIKI!!!
 +
 +
= Performance of Solar Power Plant Using Monte Carlo Simulation and ERA5 Data (matj27)=
 +
 +
== What will you simulate? ==
 +
The simulation will model the potential energy output of a power plant. Simulation will be based upon meteorological data from the ERA5 reanalysis dataset with panel efficiency variability to determine an energy production estimates over a year in Louny (Roughly N 50°21′00″; E 013°47′00″; ERA5 resolution is cca. 31 km - 0.25° grid (bbox: [[13.75, 50.5],[14.00, 50.5],[14.00, 50.25],[13.75, 50.25],[13.75, 50.5]])).
 +
 +
== Goal of the simulation ==
 +
The goal is to analyze the impact of daily solar radiance variability and panel efficiency fluctuations on the power plant energy output.
 +
 +
== Users ==
 +
Solar power plants companies and solar power plants owners to calculate financial feasibility, ROI etc.
 +
 +
== Methods, environment ==
 +
'''Methods:''' Monte Carlo simulation
 +
 +
'''Environment:''' Python - to process ERA5 GRIB data, Excel - to run Monte Carlo simulation
 +
 +
== Variables incorporated ==
 +
Solar panels power and efficiency, solar radiance from ERA5.
 +
 +
Historical ERA5 data will define the mean and variance of solar radiance.
 +
 +
Panel efficiency variability will be sourced from manufacturer specifications.
 +
 +
== Data for simulation behavior formulas ==
 +
Formula to estimate the electricity generated in output of a photovoltaic system: E = A * r * H * PR
 +
 +
E = Energy (kWh)
 +
 +
A = Total solar panel Area (m2)
 +
 +
r = solar panel yield or efficiency (%)
 +
 +
H = Annual average solar radiation on tilted panels (based on solar radiance)
 +
 +
PR = Performance ratio, coefficient for losses (range between 0.5 and 0.9, default value = 0.75)
 +
 +
Based on https://photovoltaic-software.com/principle-ressources/how-calculate-solar-energy-power-pv-systems[https://photovoltaic-software.com/principle-ressources/how-calculate-solar-energy-power-pv-systems]
 +
 +
 +
[[User:matj27|matj27]] ([[User talk:matj27|talk]]) 19:07, 9th December 2024 (CET)
 +
:: '''Approved''' [[User:Oleg.Svatos|Oleg.Svatos]] ([[User talk:Oleg.Svatos|talk]]) 15:16, 12 December 2024 (CET)
 +
 +
= Simulation of traffic flow efficiency on highway D1 (based od traffic restrictions) =
 +
 +
== What will be simulated ==
 +
 +
Simulation of arrival delay based on number of traffic restrictions on highway D1. How many restrictions are "acceptable" so that there is not too much delay compared to driving without any restrictions. The user will be able to set the number of restricted kilometers and the number of restritions.
 +
 +
== Goal ==
 +
 +
Find out how many restrictions are too much and if it's better to have more smaller ones or less bigger ones.
 +
 +
== Usefulness ==
 +
 +
 +
The simulation can show us how much delay is caused by restrictions on the highway, and whether the highway is too restricted or whether restrictions can be increased without significantly reducing travel time. It can also show us whether it is better to have more restrictions in smaller chunks or fewer restrictions over a longer stretch.
 +
 +
== Simulation method ==
 +
 +
Simulation in application NetLogo
 +
 +
== Variables ==
 +
- Number of cars
 +
 +
- Percentage of truks (slower cars)
 +
 +
- Number of restricted kilometres
 +
 +
- Number of restrictions
 +
 +
- Percentage of aggresive drivers
 +
 +
== Radnom variables ==
 +
 +
- Speed of cars
 +
 +
- Lane changing
 +
 +
- Random restriction placement
 +
 +
 +
==  Source for data ==
 +
 +
https://dopravniinfo.cz/D1
 +
https://d1.dd.cz/?direction=12
 +
 +
[[User:Sedp11|Sedp11]] ([[User talk:Sedp11|talk]]) 16:40, 10 December 2024 (CET) - I had this topis last year but never made it. If its not OK I will make a new one.
 +
 +
: '''APPROVED''' [[User:Tomáš|Tomáš]] ([[User talk:Tomáš|talk]]) 14:38, 20 December 2024 (CET)
 +
 +
= System Dynamics Simulation of Hybrid Work Models =
 +
 +
== What will be simulated ==
 +
The simulation will model workplace dynamics under three work modes—remote, hybrid, and in-office—focusing on the interplay between key factors: productivity, collaboration, employee satisfaction, and cost. The model will explore how these variables interact over time in different work environments.
 +
 +
== The goal of the simulation ==
 +
To analyze the relationships and feedback loops between productivity, collaboration, satisfaction, and cost under various work modes, and provide actionable insights into:
 +
* How collaboration affects productivity over time.
 +
* How employee satisfaction changes in response to work mode, workload, and collaboration.
 +
* The trade-offs between cost-efficiency and employee performance.
 +
 +
== Example User and How would it help ==
 +
* Example User: HR managers, workplace strategists, or organizational leaders in medium to large enterprises
 +
* How it helps: The simulation provides data-driven insights into the long-term effects of different work modes, helping organizations create work policies that optimize employee performance and satisfaction while maintaining cost efficiency.
 +
 +
== Method and Simulation Environment ==
 +
* Method: System dynamics simulation to model causal relationships and feedback loops.
 +
* Simulation Environment: Vensim PLE
 +
 +
== Variables ==
 +
* Productivity: Represents the task completion rate over time. Influenced by collaboration, workload, and satisfaction
 +
* Collaboration: Measures teamwork effectiveness. Remote work has the lowest collaboration, hybrid has moderate, and in-office has the highest levels.
 +
* Satisfaction: Reflects employee morale and well-being. Satisfaction increases with productivity and effective collaboration but decreases with excessive workload.
 +
* Cost: Represents daily operational expenses per employee. Fixed based on the work mode.
 +
 +
== Data ==
 +
Based on studies and reports from Statista, workplace surveys and industry averages for operational costs in each work mode.
 +
 +
== What exact data you will base your formulas in the simulation (simulation behavior) on ==
 +
* Productivity Formula: Productivity = Baseline Productivity × Collaboration Index × Satisfaction Level
 +
* Collaboration Formula: Collaboration = Baseline Collaboration × (1 − Remote_Work_Proportion)
 +
* Satisfaction Formula: Satisfaction = Baseline Satisfaction + (0.2 × Productivity) − (0.1 × Workload Index)
 +
* Cost Formula: Fixed cost values for each work mode.
 +
* Feedback Loops:
 +
** Positive Loop: High collaboration → Higher productivity → Higher satisfaction → Improved collaboration.
 +
** Negative Loop: Excessive workload → Lower satisfaction → Reduced productivity.
 +
 +
[[User:Tara04|Tara04]] ([[User talk:Tara04|talk]]) 20:15, 11 December 2024 (CET)
 +
:: '''Approved''' [[User:Oleg.Svatos|Oleg.Svatos]] ([[User talk:Oleg.Svatos|talk]]) 15:23, 12 December 2024 (CET)
 +
 +
----
 +
 +
= Robotic Vacuum Algorithms Simulation by kulv05 =
 +
 +
== What will be simulated: ==
 +
 +
In this task I want to simulate a robotic vacuum cleaner that cleans a room, navigate around obstacles and collecting dust and trash.
 +
 +
== The goal of the simulation ==
 +
The goal of the simulation is to compare the effectiveness of different movement algorithms for a robot vacuum, find the one that is the most efficient. I aim to determine which algorithm completes the cleaning task in the least time, consumes the least power, overall efficiency as well.
 +
The formulas for comparison:
 +
Efficiency_time= Ticks needed to finish cleaning/Dust Collected;
 +
Efficiency_power=Power usage/Trash Collected;
 +
Efficiency_overall=Trash Collected/(Ticks needed to finish cleaning×Power usage);
 +
 +
== Who would actually use such simulation ==
 +
 +
The results can be theoretically valuable for developers working on autonomous home devices and manufacturers of robotic vacuum cleaners such as iRobot, Xiaomi etc. Customers can also find it useful when choosing a new vacuum.
 +
 +
== What method and simulation environment you plan to use ==
 +
 +
The simulation will be developed using the NetLogo agent-based model
 +
 +
== What variables will be incorporated ==
 +
 +
''Agents'':
 +
 +
• Vacuum
 +
• Trash
 +
• Room(The space within which the robot operates, including obstacles like furniture)
 +
 +
''Parameters'':
 +
 +
• Type of algorithm
 +
• Ticks needed to finish cleaning
 +
• Power usage
 +
• Trash Collected
 +
 +
==What variables will be random==
 +
 +
Trash placement
 +
 +
Start position
 +
 +
== What exact data you will base your formulas in the simulation (simulation behavior) on ==
 +
 +
The algorithms used for comparison:
 +
Random walk(reactive), Zigzag, Spiral, Wall to wall, SLAM(if possible to implement in netlogo), A* (if possible to implement in netlogo)
 +
 +
https://www.diva-portal.org/smash/get/diva2:1213349/FULLTEXT02.pdf [https://www.diva-portal.org/smash/get/diva2:1213349/FULLTEXT02.pdf]
 +
 +
https://ouster.com/insights/blog/introduction-to-slam-simultaneous-localization-and-mapping [https://ouster.com/insights/blog/introduction-to-slam-simultaneous-localization-and-mapping]
 +
 +
https://www.geeksforgeeks.org/a-search-algorithm/ [https://www.geeksforgeeks.org/a-search-algorithm/]
 +
 +
Evaluation:
 +
 +
Efficiency_time= Ticks needed to finish cleaning/Dust Collected
 +
 +
Efficiency_power=Power usage/Trash Collected
 +
 +
Efficiency_overall=Trash Collected/(Ticks needed to finish cleaning×Power usage)
 +
 +
[[User:Kulv05|Kulv05]] ([[User talk:Kulv05|talk]]) 01:44, 13 December 2024 (CET)
 +
 +
: '''APPROVED''' [[User:Tomáš|Tomáš]] ([[User talk:Tomáš|talk]]) 17:30, 20 December 2024 (CET)
 +
~
 +
----
 +
 +
= Simulation Concept – Bee Foraging Behavior =
 +
 +
=== Objectives ===
 +
* Understand the dynamics of bee foraging behavior and its efficiency in collecting nectar.
 +
* Explore the influence of environmental factors like nectar replenishment rates and bee memory retention on foraging success.
 +
* Simulate how communication methods like the waggle dance influence the collective behavior of bees.
 +
 +
=== Environment ===
 +
* '''Patches''': Represent flowers scattered across a 2D grid, each containing a limited amount of nectar that replenishes over time.
 +
* '''Hive''': A central location on the grid where bees return after collecting nectar.
 +
 +
=== Agents ===
 +
# '''Bees (Turtles):'''
 +
## Search for flowers with nectar and collect it.
 +
## Return to the hive to deposit nectar and signal flower locations using the waggle dance.
 +
# '''Flowers (Patches):'''
 +
## Have a specific amount of nectar that can be collected.
 +
## Nectar levels decrease as bees forage and replenish over time.
 +
 +
=== Methods ===
 +
==== Initialization ====
 +
* Randomly distribute flowers across the grid with initial nectar levels.
 +
* Initialize a fixed number of bees at the hive.
 +
 +
==== Simulation Steps (Turtles/Agents) ====
 +
# '''Foraging:'''
 +
## Bees search randomly or follow waggle dance signals to locate flowers with nectar.
 +
## Once nectar is collected, they return to the hive to deposit it.
 +
# '''Waggle Dance Communication:'''
 +
## Bees that successfully find nectar signal its location to other bees in the hive.
 +
## Other bees decide whether to follow these signals or continue searching independently.
 +
# '''Nectar Replenishment:'''
 +
## Flowers regenerate nectar at a rate defined by the user.
 +
# '''Memory Retention:'''
 +
## Bees remember flower locations for a limited time, after which they must search anew or rely on waggle dance signals.
 +
 +
==== Interaction Dynamics ====
 +
* '''User Inputs:'''
 +
** Number of bees.
 +
** Nectar replenishment rate.
 +
** Bee memory retention (time).
 +
* '''Scenarios to Explore:'''
 +
** High vs. low nectar replenishment rates.
 +
** Effect of longer or shorter memory retention.
 +
** Impact of increased hive communication (more bees following waggle dances).
 +
 +
=== Simulation Details ===
 +
* '''Platform''': NetLogo.
 +
* '''Data Source''': Synthetic data to simulate nectar levels and bee behavior, designed to mimic real-world phenomena based on biological studies.
 +
* '''Behavior Setup''': Inspired by findings in bee foraging and communication studies:
 +
** [https://link.springer.com/article/10.1556/ABiol.63.2012.Suppl.2.8?utm_source=chatgpt.com Effects of Flower Patches on Bee Foraging].
 +
** [https://academic.oup.com/beheco/article/19/2/255/212470 The Role of the Waggle Dance in Foraging Success].
 +
 +
[[User:Lozd00|Lozd00]] ([[User talk:Lozd00|talk]]) 10:11, 13 December 2024 (CET)
 +
 +
: '''APPROVED''' [[User:Tomáš|Tomáš]] ([[User talk:Tomáš|talk]]) 17:32, 20 December 2024 (CET)
 +
----
 +
 +
= Simulation of Urban Bicycle-Sharing System =
 +
 +
== Problem ==
 +
Bike-sharing systems often struggle with uneven bicycle distribution across stations, leading to user frustration, inefficient system usage, and increased operational costs for redistribution.
 +
 +
== Goal ==
 +
Develop and analyze optimal strategies for bicycle redistribution that maximize user accessibility and system efficiency while minimizing operational costs.
 +
 +
== Simulation Stakeholders ==
 +
* City Transportation Planners: Optimize bicycle-sharing system infrastructure
 +
* Bike-Sharing System Operators: Improve operational efficiency
 +
* Municipal Mobility Departments: Understand urban mobility patterns
 +
 +
== Method and simulation environment ==
 +
* '''Method''': Agent-based modeling 
 +
* '''Simulation environment''': NetLogo
 +
 +
== Agents ==
 +
=== Bicycles ===
 +
Total fleet size based on real data from successful bike-sharing systems (Barcelona bike sharing)
 +
 +
'''Individual bicycle characteristics:'''
 +
* Battery level
 +
* Maintenance status
 +
* Current station location
 +
 +
=== Stations ===
 +
* Geographically distributed across area
 +
* Capacity limits based on real urban infrastructure
 +
* Dock availability
 +
* Location attractiveness (proximity to popular destinations)
 +
 +
=== Users ===
 +
'''Trip Characteristics:'''
 +
* Origin and destination points
 +
* Time of day
 +
 +
'''User Behavior:'''
 +
* Willingness to walk to alternative stations
 +
* Tolerance for bicycle unavailability
 +
 +
=== Random Variables ===
 +
 +
'''User Arrival Rates'''
 +
* Varying by time of day (peak/off-peak hours)
 +
** Probability distribution: Poisson distribution with parameters from actual bike-sharing system data
 +
 +
== Simulation rules ==
 +
* system operates 24/7
 +
* '''Station emptiness:'''
 +
** < 10% empty
 +
** > 80% full
 +
 +
== Data Limitations ==
 +
* aggregated data will be used
 +
* no real city will be used for simulation, it will be set in made up part of city with points of interest and bike sharing stations
 +
 +
== Data sources ==
 +
* '''Research papers:'''
 +
** https://www.sciencedirect.com/science/article/abs/pii/S2210670719319286
 +
 +
* '''Bike sharing data'''
 +
** https://www.kaggle.com/datasets/edomingo/bicing-stations-dataset-bcn-bike-sharing/data
 +
 +
[[User:Capj05|Capj05]] ([[User talk:Capj05|talk]]) 16:47, 16 December 2024 (CET)
 +
 +
----
 +
: APPROVED, but you deal with some very soft variables like: Willingness to walk to alternative stations, Tolerance for bicycle unavailability. It is very important to have all parameters very well justified. [[User:Tomáš|Tomáš]] ([[User talk:Tomáš|talk]]) 17:38, 20 December 2024 (CET)
 +
 +
 +
= AIDS Spread Simulation by stej34=
 +
 +
=== What will be simulated: ===
 +
The spread of AIDS through a small, isolated human population, focusing on sexual contact as the primary transmission route.
 +
 +
=== Goal of the simulation: ===
 +
The simulation aims to illustrate how behavioral tendencies, such as abstinence, commitment, condom use, and testing frequency, influence the dynamics of AIDS transmission within a population.
 +
 +
=== Who would use the simulation and how it helps them: ===
 +
This simulation can benefit a variety of users:
 +
 +
* '''Public Health Professionals:''' Analyze how changes in public behavior, such as increased testing or condom use, affect the spread of AIDS and inform public health campaigns.
 +
* '''Researchers:''' Study the impact of individual behaviors on disease dynamics and explore hypothetical scenarios to understand possible intervention outcomes.
 +
* '''Educators:''' Use the simulation as an engaging, interactive tool to teach about disease transmission, the importance of testing, and the role of preventive measures.
 +
 +
=== Method and simulation environment: ===
 +
* '''Method:''' Multiagent simulation
 +
* '''Simulation environment:''' NetLogo
 +
 +
=== Variables in the model: ===
 +
 +
* '''Deterministic Variables:'''
 +
  * Average Coupling Tendency: Likelihood of engaging in sexual relationships.
 +
  * Average Commitment: Duration of sexual relationships.
 +
  * Average Condom Use: Probability of practicing safe sex.
 +
  * Average Test Frequency: Frequency of undergoing AIDS testing.
 +
 +
* '''Random Variables:'''
 +
  * Disease Transmission Probability: Based on condom use and infection status of partners.
 +
  * Relationship Formation: Pairing depends on individual coupling tendencies.
 +
  * Individual Testing Behavior: Determines awareness of infection.
 +
 +
=== Data sources: ===
 +
 +
* '''Research Articles:'''
 +
  * [https://www.unaids.org/ UNAIDS: AIDS Epidemic Information]
 +
  * [https://academic.oup.com/jpe/article/17/2/rtae007/7589693 Behavioral and Social Determinants of AIDS Transmission]
 +
  * [https://www.mdpi.com/1424-2818/16/6/317 Modeling Epidemics in Isolated Populations]
 +
 +
[[User:Stej34|Stej34]] ([[User talk:Stej34|talk]]) 10:39, 18 December 2024 (CET)
 +
 +
: It is very complicated to make such simulation valuable. It is not hard to create a model of epidemy, but usually it is so simplified that it is useless.
 +
: I recommend to elaborate it into detail and focus on some particular thing or to choose a different topic. [[User:Tomáš|Tomáš]] ([[User talk:Tomáš|talk]]) 17:41, 20 December 2024 (CET)

Latest revision as of 22:17, 20 December 2024

Please, put here your assignments. Do not forget to sign them. You can use ~~~~ (four tildas) for an automatic signature. Use Show preview in order to check the result before your final sumbition.

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.

Topics on gambling, cards, etc. are not welcome.

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.

Criteria for evaluation of the simulation proposal

The proposal must contain:

  • What you will simulate
  • The goal of the simulation (what you analyze - i.e. not "to simulate balloon factory", but what problem should the simulation solve).
  • Who would actually use such simulation (example of such user) and how would it help him
  • What method and simulation environment you plan to use. Choose only from the development environments that we have used in the course.
  • What variables will be incorporated
  • What variables will be random
  • What exact data you will base values of your variables on
  • (In case of Monte Carlo) What exact data you will base your determination of probability distribution of your random variables on
  • What exact data you will base your formulas in the simulation (simulation behavior) on

If any of the above points are missing from the simulation proposal, the proposal is considered incomplete. Unless the proposal contains all of the above points it will not be evaluated at all (and therefore cannot be approved).

  1. Is it clear from the proposed assignment how the simulation will work?
  2. Does the simulation make sense?
  3. Is the simulation model complex enough to simulate credibly the real-world phenomenon that the simulation tries to simulate?
  4. Is the data used real and relevant for the real-world phenomenon that the simulation tries to simulate?
  5. Is the simulation feasible? (in given time by the course)

If the answer to any of the above points is no, you need to improve your proposal. Don't wait for us to tell you so - you're wasting your time.

Contents

Ant Colony

What will be simulated:

  • Ant colony growth

Goal of the simulation:

  • The simulation aims to demonstrate how the complex, organized behaviors of an ant colony emerge from simple, decentralized rules followed by individual ants.

Who would use the simulation and how it helps them:

  • There is a diverse list of potential users of this simulation.
    • Biologists can use the simulation to study and analyze the behavior of individual ants, their collective actions, and the emergent behavior of the ant colony.
    • Biology educators can use this simulation as an engaging, interactive tool to demonstrate how the complex, organized behaviors of an ant colony emerge from simple, decentralized rules followed by individual ants.
    • Exotic cuisine chefs can use this simulation to predict and optimize ant colony growth. This allows them to manage colonies sustainably and maximize the yield of their unique ingredient.

Method and simulation environment:

  • Method: Multiagent simulation
  • Simulation environment: NetLogo

Variables in the model:

  • Deterministic Variables:
    • Queen's Egg-Laying Rate
    • Egg Development Time
    • Worker Task Allocation
    • Environmental Constants
  • Random Variables:
    • Egg Survival Rate
    • Worker Behavior
    • Worker Lifespan
    • Environmental Threats

Data sources:

  • Observational data
  • Research articles

Spis03 (talk) 14:33, 9 December 2024 (CET)

APPROVED Tomáš (talk) 16:28, 17 December 2024 (CET)


Assignment Proposal (Draft) Title:

  • Simulation of pension reform in the Czech Republic: Analysis of long-term sustainability

What will be simulated:

  • A system dynamics model of the Czech pension system that simulates the long-term financial sustainability under varying demographic, economic, and policy scenarios. The simulation will project future balances of the pension system, incorporating the flows of revenues (social insurance contributions) and expenditures (pension payouts)

Goal of the simulation (What problem should the simulation solve):

  • The main goal is to analyze how different pension reform strategies (e.g., adjusting retirement age, altering contribution rates, changing the indexation formula of pensions) will affect the long-term stability of the Czech pension system. The simulation aims to identify specific policy levers and thresholds that ensure the pension system’s financial equilibrium over a multi-decade horizon, despite changing demographic and economic conditions.

Who would use the simulation and how it helps them:

  • The potential users include not only the Ministry of Finance, the Ministry of Labour and Social Affairs, but also the general public and the media. Although the model does not simulate the pension system in complete detail, it provides a general overview and helps users understand the basic mechanisms and trends that will shape the future of the pension system. In this way, users can:
    • Gain a preliminary orientation and inspiration: By experimenting with simple scenarios (e.g., raising the retirement age or altering contribution rates), users can gain a clearer picture of how different reform steps could influence the stability of the pension system.
    • Provide context for public debate: The model can assist citizens, journalists, and non-profit organizations in better understanding the issues surrounding pension reform. This allows them to critically evaluate political proposals or expert recommendations.
    • Lead to more informed decision-making: While this is not a tool for detailed macroeconomic forecasting, the simulation provides a general insight into potential long-term trends. This can contribute to a broader understanding of the necessity for reforms and their impact on future generations.

Method and simulation environment:

  • Method: System Dynamics
  • Simulation environment: Vensim PLE (freely available for academic use)

Variables in the model (deterministic and random):

  • Core Population Variables:
    • Number of children (new entrants to future workforce)
    • Number of working-age population (workers contributing to the system)
    • Number of pensioners (beneficiaries)
  • Policy Variables:
    • Statutory retirement age
    • Contribution rate to social insurance (percentage of wage)
    • Pension benefit formula and indexation mechanism
  • Economic Variables:
    • Average wage (influences contributions)
    • Inflation rate (influences indexation of pensions and wage growth)
  • Fiscal Variables:
    • Total contributions collected (based on number of workers, contribution rate, and average wage)
    • Total pension expenditure (based on number of pensioners and average pension)
    • Pension system reserve fund (if applicable) and its depletion or accumulation
  • Random Variables:
    • The model will incorporate stochastic elements through probability distributions derived from historical data and OECD/EUROSTAT projections to reflect uncertainty in:
      • Fertility rate (affects future workforce size; random from projected distribution)
      • Mortality rate / Life expectancy changes (stochastic variation around central OECD forecasts)
      • Inflation rate (stochastic variation around central forecast from CNB/OECD data)
      • Retirement rate (number of people retire each year +-)

Data sources (for deterministic baseline and to derive distributions):

  • Czech Statistical Office (ČSÚ) for historical demographic data
  • OECD demographic and economic projections for Czech Republic
  • Eurostat long-term demographic projections for EU countries

Formulas in the simulation (examples):

  • Pension Expenditure: Total Pension Expenditure = Number of Pensioners * Average Pension
  • Average Pension Calculation: Average Pension(t+1) = Average Pension(t) * (1 + InflationIndex)
  • Contribution Revenue: Total Contributions = Number of Workers * Average Wage * Contribution Rate
  • System Balance: Annual Balance = Total Contributions - Total Pension Expenditure
  • Accumulation or depletion of the pension reserve fund is then modeled as a stock: Reserve(t+1) = Reserve(t) + Annual Balance.

Model complexity and data linking:

  • Causal loop diagrams (CLD): Will illustrate feedback loops such as how employment and wage growth influence contributions, and how demographic changes influence the ratio of workers to retirees.
  • Stock and Flow Diagrams: Will detail population stocks (children, workers, retirees), and financial stocks (pension fund reserves), along with flows (entrants to workforce, retirees, death rates, pension contributions, and payouts).

Specific, measurable, and verifiable results:

  • Specificity: The model will project the pension system’s financial status from year X to year X+50 under various reform scenarios, providing exact quantitative outcomes (e.g., fund balance in billions CZK, pension-to-wage ratio).
  • Measurable metrics:
    • Dependency ratio (number of pensioners per 100 workers)
    • Pension system annual balance (CZK) and cumulative reserves over time
    • Average replacement rate (pension/average wage ratio)
    • Sensitivity of sustainability gap to changes in retirement age or contribution rate
  • Verifiability: The initial model run will be calibrated against historical data for the past decade. Adjustments to parameters and comparison with known OECD and ČSÚ forecasts will verify the model’s credibility.

Omaj01 (talk)

APPROVEDOleg.Svatos (talk) 17:57, 6 December 2024 (CET)



Simulation concept – Invasive Plant Species vs. Native Plants vs. Herbivores Jan César (cesj05)

Objectives:

Understand the dynamics of competition between invasive plant species and native plants in a shared environment

Explore the conditions under which either the invasive species dominates, coexists, or fails to establish.

Environment:

Each patch represents a piece of land that can grow either a natrive or invasive plant (or remain empty)

Plants compete for resources on each path

Agents:

Native Plants: Slower growth but more resistant to herbivores or harsh conditions.

Invasive Plants: Faster growth and higher seed dispersal rate but less resistant to herbivores.

Herbivores: Agents that eat plants, with a preference for invasive or native species (modifiable by the user).

Methods

Initialization:

Randomly populate the grid with a mix of invasive and native plants.

Set up resource levels for each patch.

Place herbivores randomly across the grid.


Simulation Steps (Turtles/Agents):

Each plant (agent) checks:

Whether it has resources to grow or reproduce.

If conditions are favorable, it spreads seeds to nearby patches.

Herbivores move and consume plants on the patches they visit.

Competition between plants on shared patches determines which survives.


Interaction Dynamics: Modify the probability of herbivory or the effectiveness of seed dispersal as sliders to explore different scenarios.


The simulation will be done in NetLogo, as for the data, I have chosen these plants:

Kudzu (Pueraria montana)

Growth Rate: Kudzu is renowned for its rapid growth, capable of extending up to 0.3 meters (1 foot) per day, with mature vines reaching lengths of 30 meters (98 feet).


Resource Utilization: As a nitrogen-fixing plant, kudzu thrives in nitrogen-deficient soils, enhancing its competitive advantage in such environments.


Competitive Strategy: Kudzu's aggressive growth allows it to overtop and shade native vegetation, effectively outcompeting other species for sunlight and space.


Purple Coneflower (Echinacea purpurea)

Growth Characteristics: This perennial herb typically grows to heights of 1 to 3 feet (approximately 0.3 to 0.9 meters) and produces a woody rhizome.


Resource Requirements: Purple coneflower prefers sunny sites with low levels of competition and soils rich in magnesium and calcium.


Competitive Ability: While it can coexist with other species, purple coneflower may require management to prevent being outcompeted by more aggressive plants.

This description of chosen plant species will be used to set up their behaviour in NetLogo.

Resources:

For Kudzu (Pueraria montana):

Forest Service, U.S. Department of Agriculture. (n.d.). Pueraria montana var. lobata: Kudzu. Retrieved from https://www.fs.usda.gov/database/feis/plants/vine/puemonl/all.html

National Center for Biotechnology Information. (2024). PMC Article on Kudzu Growth Dynamics. Retrieved from https://pmc.ncbi.nlm.nih.gov/articles/PMC9824185/

Wikipedia contributors. (n.d.). Kudzu in the United States. Retrieved from https://en.wikipedia.org/wiki/Kudzu_in_the_United_States

For Purple Coneflower (Echinacea purpurea):

USDA Natural Resources Conservation Service. (n.d.). Plant guide: Echinacea purpurea. Retrieved from https://plants.usda.gov/DocumentLibrary/plantguide/pdf/pg_ecan2.pdf

Plant Delights Nursery. (n.d.). Purple Coneflower (Echinacea purpurea). Retrieved from https://www.plantdelights.com/blogs/articles/purple-coneflower-echinacea-purpurea-plant

USDA Natural Resources Conservation Service. (n.d.). Echinacea purpurea Fact Sheet. Retrieved from https://plants.usda.gov/DocumentLibrary/factsheet/pdf/fs_ecpu.pdf



If needed, more studies will be used.

This simulation can be used by gardeners trying to maintain their garden. Cesj05 (talk) 17:53, 6 December 2024 (CET)

It is necessary to use real-world data. For simplicity sake, I strongly recommend to pick a particular specie or a couple species where are you able obtain data. Otherwise the task wouldn't be verifiable. Tomáš (talk) 16:33, 17 December 2024 (CET)


Updated - particular species chosen with attributes and resources, I hope it is alright, Mr. Svatoš already told me on class that if I provided some relevant resources, it should be approved without a problem (meaning even without specifically chosen plant species), thank you Cesj05 (talk) 13:23, 20 December 2024 (CET) APPROVED Tomáš (talk) 14:00, 20 December 2024 (CET)

Simulation Concept – Traffic Accident Risk Analysis

Objectives

  • Understand the dynamics of traffic accidents based on road conditions, traffic density, and driver behavior.
  • Explore the conditions under which accidents become frequent, and how they impact overall traffic flow.
  • Test mitigation strategies like improved road quality or stricter speed limits.

Environment

  • Patches: Represent road segments and intersections, each with a defined condition:
    • Good: Low accident probability.
    • Bad: Increased accident probability.
    • Under Construction: High accident probability and slower movement for cars.
  • Road Network: A grid-based layout with straight roads and intersections where traffic can flow.

Agents

  1. Cars (Turtles):
    1. Each car has a speed, a destination, and a probability of making a driving error.
    2. Movement is influenced by traffic density and road conditions.
  2. Accidents:
    1. Simulated as blocked road segments.
    2. Cause delays and force cars to reroute.
  3. Traffic Lights (Optional):
    1. Located at intersections to control flow.
    2. Can be toggled on/off to explore their impact on accidents.

Methods

Initialization

  • Randomly distribute cars across the road network with initial speeds and destinations.
  • Assign random conditions (good, bad, under construction) to road segments based on user input.

Simulation Steps (Turtles/Agents)

  1. Movement:
    1. Cars follow road segments, moving faster on good roads and slower on bad/under-construction ones.
  2. Accident Risk:
    1. Probability of an accident increases with:
      1. Poor road conditions.
      2. High speed.
      3. High traffic density.
  3. Accident Handling:
    1. If an accident occurs, the road segment is temporarily blocked.
    2. Cars reroute to avoid the blocked segment, increasing congestion elsewhere.
  4. Recovery:
    1. Accidents are cleared after a set duration, restoring traffic flow.

Interaction Dynamics

  • User Controls:
    • Traffic density, road condition distribution, speed limits, and driver error probabilities can be adjusted with sliders.
  • Scenarios:
    • Test high traffic density with poor roads versus low traffic density with good roads.
    • Simulate stricter traffic laws by reducing driver errors and imposing speed limits.

Simulation Details

  • Platform: NetLogo.
  • Data Source: Synthetic data will be used to mimic real-world traffic dynamics based on studies and assumptions.
  • Behavior Setup: Modeled on findings from traffic and safety research:
  • Additional studies will be incorporated if needed to refine parameters.

Sim timm03 (talk) 16:11, 7 December 2024 (CET)

APPROVED Dont forget to keep the model testable, meaning all parameters should have a reasonable justification. Tomáš (talk) 14:02, 20 December 2024 (CET)

Assignment Proposal (Draft)

Title

Simulation of Security Efficiency in a Store: Analyzing Optimal Guard Allocation Based on Obstruction and Escape Dynamics

What will be simulated

  • A simulation of a store environment where security guards patrol to prevent thieves from stealing goods and escaping through designated exits. The store layout includes customizable obstacles (regals), guards, and thieves. The simulation focuses on the limited visibility due to obstacles and models the dynamic interaction between guards and thieves, exploring how the required number of guards changes based on the number of thieves.*

Goal of the simulation (What problem should the simulation solve)

  • The simulation aims to determine the optimal number of guards needed to secure a store effectively under varying conditions of thief count. The ultimate goal is to provide recommendations for store security design based on quantitative analysis.*

Who would use the simulation and how it helps them

  • Store Managers and Security Companies*: Helps in designing security layouts and determining the number of security guards needed to maximize efficiency and minimize theft.
  • Students*: Offers insights into visibility-limited environments and agent-based modeling techniques.

Method and simulation environment

  • Method: Agent-based modeling
  • Simulation environment: NetLogo

Variables in the model (deterministic and random)

Deterministic Variables

  • Number of guards
  • Number of thieves
  • Number of regals (obstacles): Fixed positions
  • Store size:
  • Guard and thief placement: Guards are placed on opposite sides of the store to maximize coverage; thieves are placed randomly.

Random Variables

  • Movement paths: Thieves and guards move dynamically based on patrol or escape strategies.
  • Thief behavior: Randomized target selection for obstacles and exits.
  • Guard patrol patterns: Random movement within patrol zones unless a thief is spotted.

Formulas in the simulation (examples)

  • Guard visibility:
 * \( \text{Visible range} = d \), where \( d \) is the number of unobstructed cells (line of sight blocked by obstacles).
  • Thief capture condition:
 * A thief is captured if a guard moves onto the same cell.
  • Escape success:
 * A thief escapes if it reaches an exit before being captured.
  • Capture efficiency:
 * \( \text{Efficiency} = \frac{\text{Captured thieves}}{\text{Total thieves}} \)

Model complexity and data linking

  • Guard and thief dynamics:
 * Guards patrol predefined zones or reactively chase thieves if spotted.  
 * Thieves move toward regals to "steal" and then to exits to escape.
  • Obstacle placement:
 * Regals are fixed in predefined locations that block visibility and movement.
  • Outputs:
 * Capture success rate  
 * Number of escaped thieves  
 * Guard efficiency metrics

Specific, measurable, and verifiable results

  • Specificity:
 * The model provides quantitative insights into the number of guards needed to maintain security across various scenarios.
  • Measurable metrics:
 * Capture rate (% of thieves caught)  
 * Escape rate (% of thieves successfully escaped)  
 * Average patrol effectiveness (distance covered by guards and time to interception).

Key questions the simulation will answer

  1. How does the number of guards required to secure the store change with varying numbers of thieves?
  2. What are the most effective patrol strategies for guards in a fixed environment with limited visibility?
  3. How does the coordination or randomness of thieves’ behavior influence the effectiveness of the store's security?

Holp11 (talk) 21:06, 7 December 2024 (CET)

APPROVED, but: under all circumstances, obtain real data and base the simulation upon them. This simulation is relatively simple to develop, the real data are what could make it valuable. Tomáš (talk) 14:25, 20 December 2024 (CET)

Customers at Traditional and Self-Service Checkouts

Topic

Simulation of the customer check-in process at the checkout, including incoming customers, their checkout selection (including self-service options), queuing, and service. The model reflects different service speeds, customer behavior (e.g., transitioning between checkouts), and satisfaction levels.

Problem

The supermarket lacks rules for opening and closing checkouts, resulting in either excessive staff costs or low customer satisfaction. Data-based rules for checkout operations can optimize efficiency and satisfaction.

Goal

Establish optimal rules for opening and closing checkouts to maintain customer satisfaction above 70%.

Simulation Stakeholders

  • HR Managers: Determine employee requirements per shift.
  • Shift Leaders: Establish rules for opening new checkouts.
  • Financial Manager: Optimize employee costs.

Method

  • Platform: NetLogo
  • Method: Agent-based simulation

Requirements

Reality Abstraction Plan

Customers

  • Number of Items in Purchase: Lognormal distribution (µ=3, σ=0.3).
  • Checkout Type Preference:
   * Items > 20: Preference = 1 (regular checkouts only).
   * Items > 10: Lognormal distribution on scale 1-100 (µ=2.8, σ=0.7).
   * Items ≤ 10: 100 - (Lognormal distribution on scale 1-100, µ=2.8, σ=0.7).
  • Willingness to Switch Checkouts: Lognormal distribution on scale 1-100 (µ=2.9, σ=0.4). Drops to half after switching.
  • Satisfaction: Depends on waiting time, switching, and checkout type.
   * Initial value: Normal distribution (mean=95, std=5).
   * Waiting Time:
       * ≤ 3 min: No change.
       * > 3 min: Decreases logarithmically: \( S(t) = 100 - 10 \cdot \ln(1 + (t - 3)) \).
   * Switching Checkouts:
       * Willingness > 80: No change.
       * Willingness ≤ 80: Decreases by a range (e.g., 1-5 points for willingness ≤ 80 & > 60).
   * Checkout Type: Satisfaction changes based on preference and actual service type (e.g., increases by 5-10 points if preference > 60 and served at self-checkout).
   * Satisfaction cannot be negative.
  • Goal: Leave the supermarket as satisfied as possible.

Checkouts

  • Regular Checkouts (Count: 5):
   * Service Speed:
       * Payment: Normal distribution (mean=1 min, std=0.2).
       * Marking Items: 80% EAN-coded items (mean=0.02 min, std=0.01); 20% non-EAN (mean=0.03 min, std=0.01).
   * Checkout Error: 0.1% probability; solving time = Normal distribution (mean=0.5 min, std=0.1).
  • Self-Service Checkouts (Count: 8):
   * Service Speed:
       * Payment: Normal distribution (mean=1.2 min, std=0.3).
       * Marking Items: 80% EAN-coded items (mean=0.03 min, std=0.01); 20% non-EAN (mean=0.04 min, std=0.01).
   * Checkout Error: 1% probability; solving time = Normal distribution (mean=0.5 min, std=0.1).

Simulation Rules

  • Operating Hours: 7:00-20:00 (1 average day).
  • Customer Arrivals:
   * Peak Hours (7:00-10:00 & 16:00-18:00): Normal distribution (mean=4, std=1).
   * Non-Peak Hours (10:00-16:00 & 18:00-20:00): Normal distribution (mean=2, std=1).
  • Goal of Checkouts: Maintain customer satisfaction above 70% with minimal open regular checkouts.
  • The simulation will not address scenarios outside the checkout area.
  • One customer corresponds to one purchase.


Rysc00 (talk) 13:23, 08 December 2024 (CET)

Please, elaborate it. What will be the real data you will base it on. What supermarket/store.?
BTW: Don't use HTML for editing these documents, Wiki uses Markup. Using HTML makes the document messy.

Update: The mentioned supermarket is supposed to be Tesco in Vodňany, my hometown. The supermarket will not share exact data with me - the values are based on my own experience and observation. Is that a sufficient base for the simulation? Obtaining such data from the supermarket is not realistic, and as to any other sources - research papers on this topic are not from the same socio-geographical background, which influences customer behavior a lot. The simulation would be less realistic if I based it on research papers.

Rysc00 (talk) 22:17, 20 December 2024 (CET)

What you will simulate:

  1. I will simulate the process of artificially snowing a ski slope, including the operation of snow cannons, and the influence of temperature, humidity, and wind on snow production and the maintenance of a snow cover.

The goal of the simulation:

  1. The objective is to optimize the snowmaking process to achieve the desired snow cover height at the lowest possible energy and water costs, while accounting for changing weather conditions.

Who would actually use such simulation and how:

  1. A typical user might be a ski resort manager or the operator of snowmaking equipment. The simulation would help them plan and optimize their snowmaking strategy in advance, reduce operational costs, and ensure quality snow conditions for skiers.

What method and simulation environment:

  1. Multi-agent simulation in NetLogo

What variables will be incorporated:

  1. Deterministic variables: the placement of snow cannons, the energy demands of the snow cannons, and the target snow cover height.
  2. State variables: the current snow depth on the slope, and the current water and energy consumption.

What variables will be random:

  1. Weather conditions (temperature, humidity, wind, and any natural snowfall) will be generated with random fluctuations within the range of observed real-world values.

What exact data you will base values of your variables on:

  1. The values for weather and the performance of snow cannons will be based on literature and technical specifications from manufacturers (average seasonal temperatures, typical humidity ranges, average efficiency of snow cannons).

Lanm14 (talk) 15:00, 08 December 2024 (CET)

APPROVED Tomáš (talk) 14:32, 20 December 2024 (CET)


Lightning Network Channel Dynamics Simulation

The Lightning Network represents a promising solution to Bitcoin's scalability challenges, enabling fast and low-cost transactions. In the Czech Republic, it's gaining practical adoption with merchants like Alza.cz, Rohlik.cz and payment processors like Qerko and GoPay.

The network consists of payment channels, direct connections between two participants. Each channel has a fixed capacity, representing the total funds locked in for transactions. This capacity is shared between the two participants, with each holding a portion of the total on his side of the channel. Payments update the balance distribution within the channel. If two participants don’t have a direct channel, the network routes payments through connected channels, relying on intermediary nodes with enough capacity to complete the transfer.

What will be simulated:

A NetLogo agent-based simulation of Lightning Network payment channels that models:

  • Nodes (merchants, customers, routing nodes) as agents with defined balances and behaviors
  • Payment channels as links between nodes with specific capacities
  • Transaction routing through the network
  • Channel balance changes and payment success/failure dynamics

Goal of the simulation:

To analyze how different network configurations affect payment success rates and channel efficiency, specifically:

  • Identify optimal channel capacity distribution for maximizing successful payments
  • Determine relationship between node connectivity and network reliability
  • Find bottlenecks in payment routing that cause transaction failures

Who would use the simulation and how it helps them:

Primary users:

  1. New merchants considering Lightning Network adoption:
    • Understand required number of payment channels
    • Plan initial channel capacity requirements
    • Estimate liquidity needs
  2. Lightning Network node operators:
    • Optimize channel configurations
    • Understand routing effectiveness
    • Plan capital allocation

Method and simulation environment:

  • Method: Agent-based modeling
  • Environment: NetLogo

Variables incorporated:

Deterministic Variables:

  1. Number of nodes (N):
    • Initial setup: 100-200 nodes
    • Based on small subset of real network for feasibility
    • Can be adjusted via interface slider
  2. Initial channel capacity (C):
    • Range: 0.001 - 0.1 BTC per channel
    • Based on average values from 1ML.com statistics
    • Set at channel creation time
  3. Node types:
    • Merchant: 20% of nodes
    • Customer: 70% of nodes
    • Routing-node: 10% of nodes
    • Proportions based on network analysis papers
  4. Base fee per transaction:
    • Default: 1 satoshi base + 0.001% of amount
    • Based on common Lightning node configurations
  5. Network topology structure:
    • Average connections per node: 3-8
    • Based on observed network patterns
    • Follows power-law distribution

Random Variables:

  1. Transaction amounts:
    • Distribution: Log-normal
    • Mean: 50,000 satoshis
    • Standard deviation: 25,000 satoshis
    • Based on public Lightning Network statistics
  2. Transaction timing:
    • Poisson distribution
    • Mean arrival rate (λ): 0.1 transactions per node per minute
    • Can be adjusted via interface slider
  3. Channel balance fluctuations:
    • Random walk within channel capacity
    • Step size: Normal distribution (μ=0, σ=0.01 × capacity)
    • Updates every simulation tick
  4. Node connection preferences:
    • Probability of connection decreases with distance
    • Weighted by node type and existing connections
    • Uses preferential attachment model
  5. Payment success probability:
    • Base probability: 0.95
    • Modified by:
      • Channel capacity utilization
      • Path length
      • Node type

Data sources for variable values:

  1. Network structure and capacities:
    • Public Lightning Network explorer (1ML.com):
      • Current number of nodes (~17,000)
      • Average channel capacity (~0.03 BTC)
      • Node distribution and connectivity patterns
    • Mempool.space statistics:
      • Total network capacity
      • Channel count
      • Node count
  2. Transaction patterns:
    • Public Lightning Network statistics from Bitcoin Visuals (bitcoinvisuals.com)
    • Academic research papers on Lightning Network analysis:
      • "Lightning Network: a second path towards centralisation of the Bitcoin economy" (Lin et al., 2020)
      • "A Quantitative Analysis of Security, Anonymity and Scalability for the Lightning Network" (Tikhomirov et al., 2020)

Simulation behavior formulas based on:

  1. Payment routing:
    • Lightning Network specifications (BOLTs) from lightning-rfc repository
    • LND implementation documentation
    • Published research on routing behavior
  2. Channel balancing:
    • Lightning Network whitepaper formulas
    • Public node operation best practices
    • Academic analysis of channel dynamics

mikf02 (talk) 19:58, 8 December 2024 (CET)

APPROVED Don't use HTML for writing WIKI!!!

Performance of Solar Power Plant Using Monte Carlo Simulation and ERA5 Data (matj27)

What will you simulate?

The simulation will model the potential energy output of a power plant. Simulation will be based upon meteorological data from the ERA5 reanalysis dataset with panel efficiency variability to determine an energy production estimates over a year in Louny (Roughly N 50°21′00″; E 013°47′00″; ERA5 resolution is cca. 31 km - 0.25° grid (bbox: [[13.75, 50.5],[14.00, 50.5],[14.00, 50.25],[13.75, 50.25],[13.75, 50.5]])).

Goal of the simulation

The goal is to analyze the impact of daily solar radiance variability and panel efficiency fluctuations on the power plant energy output.

Users

Solar power plants companies and solar power plants owners to calculate financial feasibility, ROI etc.

Methods, environment

Methods: Monte Carlo simulation

Environment: Python - to process ERA5 GRIB data, Excel - to run Monte Carlo simulation

Variables incorporated

Solar panels power and efficiency, solar radiance from ERA5.

Historical ERA5 data will define the mean and variance of solar radiance.

Panel efficiency variability will be sourced from manufacturer specifications.

Data for simulation behavior formulas

Formula to estimate the electricity generated in output of a photovoltaic system: E = A * r * H * PR

E = Energy (kWh)

A = Total solar panel Area (m2)

r = solar panel yield or efficiency (%)

H = Annual average solar radiation on tilted panels (based on solar radiance)

PR = Performance ratio, coefficient for losses (range between 0.5 and 0.9, default value = 0.75)

Based on https://photovoltaic-software.com/principle-ressources/how-calculate-solar-energy-power-pv-systems[1]


matj27 (talk) 19:07, 9th December 2024 (CET)

Approved Oleg.Svatos (talk) 15:16, 12 December 2024 (CET)

Simulation of traffic flow efficiency on highway D1 (based od traffic restrictions)

What will be simulated

Simulation of arrival delay based on number of traffic restrictions on highway D1. How many restrictions are "acceptable" so that there is not too much delay compared to driving without any restrictions. The user will be able to set the number of restricted kilometers and the number of restritions.

Goal

Find out how many restrictions are too much and if it's better to have more smaller ones or less bigger ones.

Usefulness

The simulation can show us how much delay is caused by restrictions on the highway, and whether the highway is too restricted or whether restrictions can be increased without significantly reducing travel time. It can also show us whether it is better to have more restrictions in smaller chunks or fewer restrictions over a longer stretch.

Simulation method

Simulation in application NetLogo

Variables

- Number of cars

- Percentage of truks (slower cars)

- Number of restricted kilometres

- Number of restrictions

- Percentage of aggresive drivers

Radnom variables

- Speed of cars

- Lane changing

- Random restriction placement


Source for data

https://dopravniinfo.cz/D1 https://d1.dd.cz/?direction=12

Sedp11 (talk) 16:40, 10 December 2024 (CET) - I had this topis last year but never made it. If its not OK I will make a new one.

APPROVED Tomáš (talk) 14:38, 20 December 2024 (CET)

System Dynamics Simulation of Hybrid Work Models

What will be simulated

The simulation will model workplace dynamics under three work modes—remote, hybrid, and in-office—focusing on the interplay between key factors: productivity, collaboration, employee satisfaction, and cost. The model will explore how these variables interact over time in different work environments.

The goal of the simulation

To analyze the relationships and feedback loops between productivity, collaboration, satisfaction, and cost under various work modes, and provide actionable insights into:

  • How collaboration affects productivity over time.
  • How employee satisfaction changes in response to work mode, workload, and collaboration.
  • The trade-offs between cost-efficiency and employee performance.

Example User and How would it help

  • Example User: HR managers, workplace strategists, or organizational leaders in medium to large enterprises
  • How it helps: The simulation provides data-driven insights into the long-term effects of different work modes, helping organizations create work policies that optimize employee performance and satisfaction while maintaining cost efficiency.

Method and Simulation Environment

  • Method: System dynamics simulation to model causal relationships and feedback loops.
  • Simulation Environment: Vensim PLE

Variables

  • Productivity: Represents the task completion rate over time. Influenced by collaboration, workload, and satisfaction
  • Collaboration: Measures teamwork effectiveness. Remote work has the lowest collaboration, hybrid has moderate, and in-office has the highest levels.
  • Satisfaction: Reflects employee morale and well-being. Satisfaction increases with productivity and effective collaboration but decreases with excessive workload.
  • Cost: Represents daily operational expenses per employee. Fixed based on the work mode.

Data

Based on studies and reports from Statista, workplace surveys and industry averages for operational costs in each work mode.

What exact data you will base your formulas in the simulation (simulation behavior) on

  • Productivity Formula: Productivity = Baseline Productivity × Collaboration Index × Satisfaction Level
  • Collaboration Formula: Collaboration = Baseline Collaboration × (1 − Remote_Work_Proportion)
  • Satisfaction Formula: Satisfaction = Baseline Satisfaction + (0.2 × Productivity) − (0.1 × Workload Index)
  • Cost Formula: Fixed cost values for each work mode.
  • Feedback Loops:
    • Positive Loop: High collaboration → Higher productivity → Higher satisfaction → Improved collaboration.
    • Negative Loop: Excessive workload → Lower satisfaction → Reduced productivity.

Tara04 (talk) 20:15, 11 December 2024 (CET)

Approved Oleg.Svatos (talk) 15:23, 12 December 2024 (CET)

Robotic Vacuum Algorithms Simulation by kulv05

What will be simulated:

In this task I want to simulate a robotic vacuum cleaner that cleans a room, navigate around obstacles and collecting dust and trash.

The goal of the simulation

The goal of the simulation is to compare the effectiveness of different movement algorithms for a robot vacuum, find the one that is the most efficient. I aim to determine which algorithm completes the cleaning task in the least time, consumes the least power, overall efficiency as well. The formulas for comparison: Efficiency_time= Ticks needed to finish cleaning/Dust Collected; Efficiency_power=Power usage/Trash Collected; Efficiency_overall=Trash Collected/(Ticks needed to finish cleaning×Power usage);

Who would actually use such simulation

The results can be theoretically valuable for developers working on autonomous home devices and manufacturers of robotic vacuum cleaners such as iRobot, Xiaomi etc. Customers can also find it useful when choosing a new vacuum.

What method and simulation environment you plan to use

The simulation will be developed using the NetLogo agent-based model

What variables will be incorporated

Agents:

• Vacuum • Trash • Room(The space within which the robot operates, including obstacles like furniture)

Parameters:

• Type of algorithm • Ticks needed to finish cleaning • Power usage • Trash Collected

What variables will be random

Trash placement

Start position

What exact data you will base your formulas in the simulation (simulation behavior) on

The algorithms used for comparison: Random walk(reactive), Zigzag, Spiral, Wall to wall, SLAM(if possible to implement in netlogo), A* (if possible to implement in netlogo)

https://www.diva-portal.org/smash/get/diva2:1213349/FULLTEXT02.pdf [2]

https://ouster.com/insights/blog/introduction-to-slam-simultaneous-localization-and-mapping [3]

https://www.geeksforgeeks.org/a-search-algorithm/ [4]

Evaluation:

Efficiency_time= Ticks needed to finish cleaning/Dust Collected

Efficiency_power=Power usage/Trash Collected

Efficiency_overall=Trash Collected/(Ticks needed to finish cleaning×Power usage) 

Kulv05 (talk) 01:44, 13 December 2024 (CET)
APPROVED Tomáš (talk) 17:30, 20 December 2024 (CET)

~

Simulation Concept – Bee Foraging Behavior

Objectives

  • Understand the dynamics of bee foraging behavior and its efficiency in collecting nectar.
  • Explore the influence of environmental factors like nectar replenishment rates and bee memory retention on foraging success.
  • Simulate how communication methods like the waggle dance influence the collective behavior of bees.

Environment

  • Patches: Represent flowers scattered across a 2D grid, each containing a limited amount of nectar that replenishes over time.
  • Hive: A central location on the grid where bees return after collecting nectar.

Agents

  1. Bees (Turtles):
    1. Search for flowers with nectar and collect it.
    2. Return to the hive to deposit nectar and signal flower locations using the waggle dance.
  2. Flowers (Patches):
    1. Have a specific amount of nectar that can be collected.
    2. Nectar levels decrease as bees forage and replenish over time.

Methods

Initialization

  • Randomly distribute flowers across the grid with initial nectar levels.
  • Initialize a fixed number of bees at the hive.

Simulation Steps (Turtles/Agents)

  1. Foraging:
    1. Bees search randomly or follow waggle dance signals to locate flowers with nectar.
    2. Once nectar is collected, they return to the hive to deposit it.
  2. Waggle Dance Communication:
    1. Bees that successfully find nectar signal its location to other bees in the hive.
    2. Other bees decide whether to follow these signals or continue searching independently.
  3. Nectar Replenishment:
    1. Flowers regenerate nectar at a rate defined by the user.
  4. Memory Retention:
    1. Bees remember flower locations for a limited time, after which they must search anew or rely on waggle dance signals.

Interaction Dynamics

  • User Inputs:
    • Number of bees.
    • Nectar replenishment rate.
    • Bee memory retention (time).
  • Scenarios to Explore:
    • High vs. low nectar replenishment rates.
    • Effect of longer or shorter memory retention.
    • Impact of increased hive communication (more bees following waggle dances).

Simulation Details

Lozd00 (talk) 10:11, 13 December 2024 (CET)

APPROVED Tomáš (talk) 17:32, 20 December 2024 (CET)

Simulation of Urban Bicycle-Sharing System

Problem

Bike-sharing systems often struggle with uneven bicycle distribution across stations, leading to user frustration, inefficient system usage, and increased operational costs for redistribution.

Goal

Develop and analyze optimal strategies for bicycle redistribution that maximize user accessibility and system efficiency while minimizing operational costs.

Simulation Stakeholders

  • City Transportation Planners: Optimize bicycle-sharing system infrastructure
  • Bike-Sharing System Operators: Improve operational efficiency
  • Municipal Mobility Departments: Understand urban mobility patterns

Method and simulation environment

  • Method: Agent-based modeling
  • Simulation environment: NetLogo

Agents

Bicycles

Total fleet size based on real data from successful bike-sharing systems (Barcelona bike sharing)

Individual bicycle characteristics:

  • Battery level
  • Maintenance status
  • Current station location

Stations

  • Geographically distributed across area
  • Capacity limits based on real urban infrastructure
  • Dock availability
  • Location attractiveness (proximity to popular destinations)

Users

Trip Characteristics:

  • Origin and destination points
  • Time of day

User Behavior:

  • Willingness to walk to alternative stations
  • Tolerance for bicycle unavailability

Random Variables

User Arrival Rates

  • Varying by time of day (peak/off-peak hours)
    • Probability distribution: Poisson distribution with parameters from actual bike-sharing system data

Simulation rules

  • system operates 24/7
  • Station emptiness:
    • < 10% empty
    • > 80% full

Data Limitations

  • aggregated data will be used
  • no real city will be used for simulation, it will be set in made up part of city with points of interest and bike sharing stations

Data sources

Capj05 (talk) 16:47, 16 December 2024 (CET)

APPROVED, but you deal with some very soft variables like: Willingness to walk to alternative stations, Tolerance for bicycle unavailability. It is very important to have all parameters very well justified. Tomáš (talk) 17:38, 20 December 2024 (CET)


AIDS Spread Simulation by stej34

What will be simulated:

The spread of AIDS through a small, isolated human population, focusing on sexual contact as the primary transmission route.

Goal of the simulation:

The simulation aims to illustrate how behavioral tendencies, such as abstinence, commitment, condom use, and testing frequency, influence the dynamics of AIDS transmission within a population.

Who would use the simulation and how it helps them:

This simulation can benefit a variety of users:

  • Public Health Professionals: Analyze how changes in public behavior, such as increased testing or condom use, affect the spread of AIDS and inform public health campaigns.
  • Researchers: Study the impact of individual behaviors on disease dynamics and explore hypothetical scenarios to understand possible intervention outcomes.
  • Educators: Use the simulation as an engaging, interactive tool to teach about disease transmission, the importance of testing, and the role of preventive measures.

Method and simulation environment:

  • Method: Multiagent simulation
  • Simulation environment: NetLogo

Variables in the model:

  • Deterministic Variables:
 * Average Coupling Tendency: Likelihood of engaging in sexual relationships.
 * Average Commitment: Duration of sexual relationships.
 * Average Condom Use: Probability of practicing safe sex.
 * Average Test Frequency: Frequency of undergoing AIDS testing.
  • Random Variables:
 * Disease Transmission Probability: Based on condom use and infection status of partners.
 * Relationship Formation: Pairing depends on individual coupling tendencies.
 * Individual Testing Behavior: Determines awareness of infection.

Data sources:

  • Research Articles:
 * UNAIDS: AIDS Epidemic Information
 * Behavioral and Social Determinants of AIDS Transmission
 * Modeling Epidemics in Isolated Populations

Stej34 (talk) 10:39, 18 December 2024 (CET)

It is very complicated to make such simulation valuable. It is not hard to create a model of epidemy, but usually it is so simplified that it is useless.
I recommend to elaborate it into detail and focus on some particular thing or to choose a different topic. Tomáš (talk) 17:41, 20 December 2024 (CET)
Retrieved from "http://www.simulace.info/index.php?title=Assignments_WS_2024/2025&oldid=26139"