Simulace.info - User contributions [en]

SS 2024/2025/cs

2025-06-13T00:07:59Z

Sanv05:

{{DISPLAYTITLE:LS 2024/2029}}

Semestrální práce (simulace) z letního semestru 2024/2025. Sem přidejte odkaz na stránku s Vaší prací.
Nejprve je třeba nechat schválit [[Assignment SS 2024/2025/cs|zadání práce]].

=Vypracovaná témata LS 2024/2025=
* [https://www.simulace.info/index.php/User:Smrv03 Evakuace šelem v pražské ZOO v případě povodně (NetLogo)] - Veronika Smrčková
* [https://www.simulace.info/index.php/User:Kubd06 Chování zákazníků v supermarketu/večerce (Netlogo)] – David Kubánek
* [https://www.simulace.info/index.php/User:Bilk08 Bitva u Azincourtu (Netlogo) ] – Kateřina Bílková
* [https://www.simulace.info/index.php/User:Seka01 Simulace vojenské patroly a střetu s nepřítelem (Netlogo)] - Alexandr Sekera
* [https://www.simulace.info/index.php/User:Sanv05 Kontrola jízdenek v MHD (NetLogo)] - Vladislav Sanin

User:Sanv05

2025-06-13T00:02:43Z

Sanv05:

= Kontrola jízdenek v MHD =

== Definice problému ==
MHD je nedílnou součástí života v Praze. Aktuálním problémem v této sféře je cestování bez platného jízdného dokladu. Jelikož je dopravní podnik mimo jiné financován právě z příjmů z jízdného, daný problém představuje zdroj finančních ztrát. Představená simulace se zabývá optimalizací kontrol platnosti jízdních dokladů v systému pražské MHD. Její cílem je otestovat, jak počet a rozmístění revizorů v síti metra ovlivňují objem udělených pokut a míru zachycení černých pasažérů. Pomocí simulace lze najít vhodné inspekční strategie, které určí, kam a kolik revizorů umístit pro zefektivnění jejich práce. Výsledky simulace mohou pak sloužit jako doporučení pro dopravní podnik k tomu, jakou inspekční strategii zvolit pro optimalizaci kontrol jízdenek.

== Metoda ==
Pro vypracování multiagentní simulace byl použit nástroj NetLogo. Výhodou daného nástroje je velmi intuitivní prostředí, ve kterém uživatel může modelovat chování agentů, vytvářet vizualizace sítě stanic, průběhu a časového vývoje sledovaných parametrů simulace. NetLogo umožňuje rychlé nastavení vstupních parametrů, jako jsou umístění a počty revizorů, a okamžité sledování dopadu změn.

Jako alternativy byly hned na začátku odmítnuty obecné programovací jazyky a knihovny (složité nastavení a podrobné kódování) a deterministické modely (nezachycují náhodu při kontrolách platnosti jízdenky). Nástroje na systémovou dynamiku, např. Vensim, by pak nedokázaly reprezentovat přesné umístění revizorů a jednotlivé agenty s platnou či neplatnou jízdenkou, proto bylo zvoleno NetLogo.

Pro agregaci dat z většího počtu běhů a analýzu výsledků z různých scénářů byl použit Microsoft Excel. Je to známé, rychlé a obecně standardní řešení pro podobné úlohy.

== Model ==
=== Stanice ===
Základem modelu je prostředí, ve kterém bude probíhat simulace. Je to reprezentace centrální části pražského metra, která zahrnuje 3 linky (A, B, C). Vzhledem k výkonnostním a vizuálním omezením bylo rozhodnuto zobrazit pouze 5 stanic každé linky, tedy dohromady 15 stanic:
* Linka '''A''' — Staroměstská, Můstek, Muzeum, Náměstí míru, Jiřího z Poděbrad
* Linka '''B''' — Karlovo náměstí, Národní třída, Můstek, Náměstí republiky, Florenc
* Linka '''C''' — I. P. Pavlova, Muzeum, Hlavní nádraží, Florenc, Vltavská
V rámci modelu v kódu NetLogo jsou pojmenovány symbolicky (A1-A5, B1-B5, C1-C5) pro jednodušší správu rozmístění. Každá stanice je agent ''station'', který má jako jeden z atributů název konkrétní linky, jejíž součástí je. Stanice jedné linky jsou mezi sebou pak vizuálně spojeny, obarveny a zařazeny do jednoho z globálních seznamů ''station-list-X'', kde X je název linky. Tím způsobem je vytvořena linka jako posloupnost stanic, tři takové linky tvoří výsledné prostředí.

[[File:MHD_mapa.png|center]]

=== Revizoři ===
Další agenti jsou revizoři, reprezentované v modelu modrými kruhy vedle stanic. Jsou přiřazeny ke stanici, kde pak zůstávají a kontrolují pasažéry (pokud jsou na dané stanici) podle hodnoty ''inspection-rate''. Pokud je v oblasti stanice více pasažérů, revizor zkontroluje tolik, kolik může podle této proměnné.

=== Pasažéři ===
Nakonec v modelu jsou pasažéři, které jsou před začátkem simulace čekají na náhodných stanicích. Po začátku simulace začínají pohybovat se po lince, ke které jsou přiřazeni, dokud nedorazí do cílové linky nebo nebudou zachyceni revizorem. Jejich atributy jsou:
* ''valid-ticket?'' — boolean hodnota, zda má platnou jízdenku nebo ne, podle ní je také nastavena barva pasažéra: bíla - má, fialová - ne
* ''state'' — stav, v jakém je: ''waiting'' (čeká na stanici) nebo ''traveling'' (v pohybu)
* ''line'' — linka, po které se pohybuje
* ''current-index'' — aktuální nebo poslední navštívená stanice
* ''destination-index'' — cílová stanice

=== Globální proměnné ===
* ''station-list-A/B/C'' — seznamy stanic
* ''inspection-rate'' — míra kontrol za tick
* ''fare-evasion-rate'' — míra jízd bez jízdenky
* ''max-ticks'' — počet ticků pro zastavení simulace
* ''passenger-spawn-rate'' — kolik vznikne pasažérů na stanici při generování pasažerů
* ''num-inspectors'' — počet revizorů, musí odpovídat počtu elementů v ''inspector-assignments''
* ''total-fines'' — počet udělených pokut za běh
* ''total-evaders'' — počet černých pasažérů za běh
* ''inspector-assignments'' — seznam s se stanicemi, kde jsou revizoři, musí odpovídat ''num-inspectors''
* ''total-spawned'' — počet pasažérů za běh

=== Propojení na data ===
Aby model mohl odpovídat realitě (s určitými omezeními), byla získána data pro daný kontext. Například míra cestujících bez platné jízdenky byla odhadnuta dle zdrojů na 8% pro Prahu, pak porovnána s jinými státy pro jistotu a byla ponechána na 8%. Výše pokuty je 1500 Kč dle DPP. Další skutečností je plat revizorů, který činí 63000 Kč (je to včetně bonusů za pokuty, ale bylo počítáno s maximem) — sice v simulaci použit nebyl, ale hodil se pro závěreční analýzu.

Zvolený počet cestujících, kteří denně využívají metro, je odvozen z dat o cestujících v MHD. 338 mil. — počet pasažérů ročně, tedy 926 tis. denně. Nejprve dané číslo bylo samozřejmě zkráceno kvůli omezením počítače a délky simulací, tedy vyděleno 10. Jelikož modelujeme jenom část metra (15/61 stanic, zhruba čtvrtina), můžeme počítat s menším počtem pasažérů, např. také s čtvrtinou. Čtvrtina od 92600 je zhruba 23000. Tak vznikl orientační počet denních cestujících v simulacích, kterého bylo pak dosaženo přes přesnější nastavení parametru ''passenger-spawn-rate''. Jak ukážou výsledky, počty denních cestujících se pohybovaly zpravidla v rozmezí 22000-25000, což odpovídá odhadu. Podobnou logiku má i počet revizorů. Podle nalezených dat obvykle v pracovní dny "v terénu" je kolem 100 revizorů, ale realističtější a vhodnější bylo operovat s menším počtem revizorů, takže je ten počet v simulacích kolem 10, s odchylkou pro konkrétní případy.

=== Časová osa simulace a dopravní špičky ===
Co se týká času simulace, jeden běh reprezentující jeden den trvá 2280 ticků, a to bylo odvozeno následovně. Bylo zjištěno, že metro je v provozu zhruba od 5 do 24, tedy 19 hodin, neboli 1140 minut. Bylo také rozhodnuto, že za tick je vhodné mít nejmenší časovou jednotku, kterou chceme reprezentovat, v daném případě je to odhad délky jedné kontroly, cca 30 sekund. Některé kontroly mohou být skoro okamžité, občas to může trvat déle, odhad je tedy ze zkušeností autora.

V rámci simulace jsou také zohledněny dopravní špičky. Intervaly 300-700 ticků považujeme za ranní špičku a 1500-1900 za odpolední/večerní špičku. Je to realizováno přes spuštění generování pasažérů ještě jednou, což dočasně na dobu špičky zvýší počet cestujících v metru. Po skončení špičky na několik ticků zastavíme obnovení pasažérů, aby se počet cestujících vrátil na základní úroveň. Než se to ale stane, musíme také zajistit vyšší počet kontrol, a je to uděláno pomocí proměnné ''inspection-rate''. Vyšší hodnota této proměnné znamená to, že revizor za jeden tick zkontroluje více cestujících, které se nachází kolem něj na dané stanici. To lze pozorovat na grafech: první je počet cestujících, druhý je počet udělených pokut v odpovídající časy.

[[File:MHD_grafy.png|center]]

=== Průběh simulace ===
Následující 4 body proběhnou při kliknutí na tlačítko '''setup''':

1. '''setup-network''' — nastavení sítě metra, určení souřadnic, sestavení seznamů stanic.

2. '''setup-parameters''' — nastavení globálních proměnných.

3. '''setup-inspectors''' — nastavení revizorů, vytvoří ''num-inspectors'' agentů a rozmístí je podle ''inspector-assignments''.

4. '''generate-passengers''' — generování pasažérů: vygeneruje ''passenger-spawn-rate'' * počet stanic (120), nastaví defaultní hodnoty atributů, náhodně nastaví boolean ''valid-ticket?'' dle ''fare-evasion-rate'' a pokud je to černý pasažér, zvýší ''total-evaders''.

Důležité procedury použité dále:

'''handle-passenger-death''' — procedura zajišťuje vznik nových pasažérů. Agenti-pasažéři se odstraní, když buď dorazí do cílové stanice nebo budou zachyceni revizorem, jsou pak ze simulace odstraněny. Na jejich místo je pak přidán nový pasažér, aby počet cestujících byl zachován. Daná procedura se nevolá během několika ticků po špičkách, aby se model vyrovnal po nárůstu cestujících během špiček.

'''do-walk-step''' — procedura pro pohyb cestujících mezi stanicemi. Každý cestující ve stavu ''traveling'' dělá krok směrem ke své cílové destinaci. Když dorazí do stanice, změní svůj ''current-index''. Pokud je ten index stejný jako cílová stanice, volá se ''handle-passenger-death''. Bylo rozhodnuto pro daný přístup, jelikož v původním návrhu vlaky (další agenti) neměly velký význam pro výsledky, vizuálně vypadaly mnohem hůř a zbytečně komplikovali model.

Dále při spuštění simulace se bude postupovat dle procedury '''go''':

1. Kontrola konce simulace (zda již uběhlo 2280 ticků).

2. Pohyb pomocí ''do-walk-step''.

3. Revizor provádí kontroly dle ''inspection-rate'' na stanici ze seznamu všech pasažérů, kdo tam je.

4. Pokud byl nalezen černý pasažér, zvyšuje ''total-fines'' a volá ''handle-passenger-death''.

5. Pokud se nacházíme ve špičkovém intervalu, zavolá se znovu ''generate-passengers''.

6. Tick.

=== Omezení ===
* Statické umístění revizorů: v modelu není zohledněna situace, když revizor se pohybuje mezi stanicemi a provádí kontroly ve vozech, což je celkem běžné. To by však znamenalo vytvoření vlaků a omezení s tím spojené, jak je uvedeno výše v popisu procedur.
* Odhady dat: přestože nalezená data pokrývají zkoumanou oblast dostatečně široko, nestačí pro hlubší analýzu. Simulace je prováděna na mnohem menších časových intervalech a se zaměřením na jevy, které nejsou dobře popsány.
* Chování při kontrolách: sice jsou kontroly funkční a jsou schopni zachytit podstatu, existuje i prostor na detailnější doladění, které by bylo náročnější a delší na implementaci.
* Fixní celkový počet: simulace nemá perfektně realistickou křivku zátěže metra, pouze znázornění dopravních špiček.

== Výsledky ==
V rámci provedení simulací bylo otestováno 6 různých scénářů, každý s odlišným počtem a/nebo umístěním revizorů. Každý scénář měl 30 opakování pro získání dostatku dat pro měsíc fungování metra, což pak bylo možné dát do souvislosti s náklady podniku na měsíční platy revizorů. Obrázek níže obsahuje všechny scénáře.

[[File:MHD_6_2.png|center]]

Scénáře jsou detailněji popsány dále a následně znázorněny v tabulce.

1. '''1 revizor na každé stanici (15):''' první scénář testoval nejširší pokrytí sítě metra, kde každá stanice byla obsazena jedním revizorem. Ze všech scénářů z pohledu zachycení černých pasažérů je ten scénář nejlepší, protože poskytuje 87% míru zachycení, je to výrazný rozdíl oproti jiným rozmístěním. Ale ve skutečnosti jde nejen o plnou vytíženost revizorů, ale také o zážitek cestujících, které mohou být kontrolovány všude a několikrát. Je to také nejnákladnější přístup, který je částečně kompenzován velkým objemem pokut (největším).

2. '''4 revizoři na každé přestupní stanici (12):''' druhý scénář byl zaměřen na účelnější kontroly, revizoři jsou pouze na přestupních stanicích ve velkých počtech. Míra zachycení je již 68%, spolu s ní se také snížil i objem pokut, ale je to také nejdražší řešení z pohledu "náklady na revizory/příjmy z pokut".

3. '''2 revizoři na každé přestupní stanici (6):''' scénář podobný předchozímu, ale s menší koncentrací revizorů na přestupních stanicích. O něco horší výsledky než předchozí, nemá žádné důležité rysy, které by daný scénář dělaly výjimečným. Míra zachycení 61%. Pokud priorita je v ušetření prostředků na platy revizorům, mezi tímto a předchozím je lepší volit tento scénář, jinak předchozí má přednost.

4. '''1 revizor na středu každé linky (3):''' testuje malý počet revizorů. Ideální scénář, pokud rozpočet na platy revizorům je omezen, je to nejnižší ze všech scénářů. Však je schopen odhalit pouze 50% černých pasažérů kvůli nízké hustotě rozmístění.

5. '''1 revizor na každé konečné stanici (6):''' daný scénář lze považovat za nejhorší. Poskytuje nejnižší míru zachycení v pouhých 42%, objem pokut je také nejnižší, a to při stejných nákladech na plat revizorům jako v scénářích 3 a 6, což je v daném případě poměrně drahé.

6. '''2 revizoři na každé lince s odstupem (6):''' scénář umísťuje revizory na stanicích ve formátu 1-X-3-X-5 (X je revizor), tedy kombinuje široké pokrytí a relativně nižší počet revizorů oproti prvním dvěma scénářům. Je to dobře vyvážený scénář, který poskytuje druhou nejlepší míru zachycení na seznamu (70%) a druhý nejvyšší objem pokut. Přestože není absolutně nejlevnější z pohledu platů revizorů, v kontextu poměru platů k příjmům je to druhé nejlepší řešení.

Následující tabulka obsahuje shrnutí dat.

[[File:MHD_tabulka.png|center]]

== Závěr ==
Na závěr je důležité shrnout výsledky multiagentní simulace kontrol jízdenek v MHD provedené v prostředí NetLogo. Simulace měla za cíl otestovat různé scénáře umístění revizorů v pražském metru pro nalezení optimálních strategií pro dopravní podnik. Daný cíl byl splněn a zároveň odhalil některé zajímavé výsledky, které nebyly autorem očekávány.

Přínos každého scénáře lze hodnotit podle toho, co je prioritou pro podnik. Například, pokud je rozpočet na revizory omezen a klíčové je ušetřit finance, nejvhodnější je scénář 4 s nejmenším počtem revizorů, jak by se dalo očekávat. Daná výhoda je získána na úkor zachycení černých pasažérů, a tedy neplní svůj cíl tak dobře.

Pokud podnik disponuje větším objemem prostředků, a cílem je zvýšit příjem z pokut, absolutně nejlepší z tohoto hlediska je scénář 1 s kontrolou každé stanice, což ale není tak jednoduché na realizaci. Plusem je vysoká míra zachycení černých pasažérů, minusem jsou však velké náklady na revizory a řízení velmi rozsáhlých a striktních kontrol.

Rozhodně není doporučeno monitorovat konečné stanice (scénář 5): je to jak velmi neefektivní z pohledu zachycení cestujících bez jízdenek, tak málo přínosné a v poměru k příjmům drahé.

Nakonec nejvíce vyváženým scénářem, který poskytuje relativně levné řešení s dostatečně vysokou mírou zachycení a objemem pokut, je scénář 6, který umísťuje revizory na stanicích s odstupem (jedna prázdná, jedna obsazena), ne nutně na přestupových stanicích. Daný scénář lehčí na koordinaci a nezvedá bezdůvodně vytíženost revizorů. Přestože není jednoznačným vítězem v jakékoliv kategorii, může sloužit univerzálním doporučením pro dopravní podnik ve správě MHD.

== Kód ==
[[File:SimulaceMHD2_sanv05.nlogo]]

== Reference ==

* Dopravní podnik hl. m. Prahy. (b.r.). ''Výše přirážky a doplatková pokladna.'' Dopravní podnik hl. m. Prahy, akciová společnost. Získáno 10. červen 2025, z https://www.dpp.cz/jizdne/pokuty-revizori/vyse-prirazky
* Jaroševský, F. (2024, prosinec 4). ''Průměrný plat revizora je 63 tisíc. Půlku z toho si musejí nachytat. „Jinak to nejde,“ tvrdí nadřízení.'' METRO.cz. https://www.metro.cz/praha/prumerny-plat-revizora-je-63-tisic-pulku-z-toho-si-museji-nachytat-jinak-to-nejde-tvrdi-nadrizeni.A241203_155006_metro-praha_mjafi
* Newkey-Burden, C. (2025, únor 18). ''Fare dodging: London’s transport blight''. The Week. https://theweek.com/transport/fare-dodging-londons-transport-blight
* Expats.cz (2023, červenec 9). ''Prague public transport inspectors handed out 250,000 fines last year.'' Expats.cz. https://www.expats.cz/czech-news/article/prague-public-transport-inspectors-handed-out-250-000-fines-last-year
* Pražská integrovaná doprava. (b.r.). ''Metro.'' Pražská integrovaná doprava. Získáno 10. červen 2025, z https://pid.cz/metro/
* Ubach, M. (2024, červenec 22). ''Tackling Fare Evasion in Bergamo: A Growing Challenge for ATB and TEB.'' Trainsfare. https://www.trainsfare.eu/tackling-fare-evasion-in-bergamo-a-growing-challenge-for-atb-and-teb/

File:SimulaceMHD2 sanv05.nlogo

2025-06-13T00:01:07Z

Sanv05:

File:MHD tabulka.png

2025-06-12T23:14:37Z

Sanv05: Sanv05 načetl novou verzi File:MHD tabulka.png

File:MHD tabulka.png

2025-06-12T23:11:09Z

Sanv05:

User:Sanv05

2025-06-12T23:04:50Z

Sanv05:

= Kontrola jízdenek v MHD =

== Definice problému ==
MHD je nedílnou součástí života v Praze. Aktuálním problémem v této sféře je cestování bez platného jízdného dokladu. Jelikož je dopravní podnik mimo jiné financován právě z příjmů z jízdného, daný problém představuje zdroj finančních ztrát. Představená simulace se zabývá optimalizací kontrol platnosti jízdních dokladů v systému pražské MHD. Její cílem je otestovat, jak počet a rozmístění revizorů v síti metra ovlivňují objem udělených pokut a míru zachycení černých pasažérů. Pomocí simulace lze najít vhodné inspekční strategie, které určí, kam a kolik revizorů umístit pro zefektivnění jejich práce. Výsledky simulace mohou pak sloužit jako doporučení pro dopravní podnik k tomu, jakou inspekční strategii zvolit pro optimalizaci kontrol jízdenek.

== Metoda ==
Pro vypracování multiagentní simulace byl použit nástroj NetLogo. Výhodou daného nástroje je velmi intuitivní prostředí, ve kterém uživatel může modelovat chování agentů, vytvářet vizualizace sítě stanic, průběhu a časového vývoje sledovaných parametrů simulace. NetLogo umožňuje rychlé nastavení vstupních parametrů, jako jsou umístění a počty revizorů, a okamžité sledování dopadu změn.

Jako alternativy byly hned na začátku odmítnuty obecné programovací jazyky a knihovny (složité nastavení a podrobné kódování) a deterministické modely (nezachycují náhodu při kontrolách platnosti jízdenky). Nástroje na systémovou dynamiku, např. Vensim, by pak nedokázaly reprezentovat přesné umístění revizorů a jednotlivé agenty s platnou či neplatnou jízdenkou, proto bylo zvoleno NetLogo.

Pro agregaci dat z většího počtu běhů a analýzu výsledků z různých scénářů byl použit Microsoft Excel. Je to známé, rychlé a obecně standardní řešení pro podobné úlohy.

== Model ==
=== Stanice ===
Základem modelu je prostředí, ve kterém bude probíhat simulace. Je to reprezentace centrální části pražského metra, která zahrnuje 3 linky (A, B, C). Vzhledem k výkonnostním a vizuálním omezením bylo rozhodnuto zobrazit pouze 5 stanic každé linky, tedy dohromady 15 stanic:
* Linka '''A''' — Staroměstská, Můstek, Muzeum, Náměstí míru, Jiřího z Poděbrad
* Linka '''B''' — Karlovo náměstí, Národní třída, Můstek, Náměstí republiky, Florenc
* Linka '''C''' — I. P. Pavlova, Muzeum, Hlavní nádraží, Florenc, Vltavská
V rámci modelu v kódu NetLogo jsou pojmenovány symbolicky (A1-A5, B1-B5, C1-C5) pro jednodušší správu rozmístění. Každá stanice je agent ''station'', který má jako jeden z atributů název konkrétní linky, jejíž součástí je. Stanice jedné linky jsou mezi sebou pak vizuálně spojeny, obarveny a zařazeny do jednoho z globálních seznamů ''station-list-X'', kde X je název linky. Tím způsobem je vytvořena linka jako posloupnost stanic, tři takové linky tvoří výsledné prostředí.

[[File:MHD_mapa.png|center]]

=== Revizoři ===
Další agenti jsou revizoři, reprezentované v modelu modrými kruhy vedle stanic. Jsou přiřazeny ke stanici, kde pak zůstávají a kontrolují pasažéry (pokud jsou na dané stanici) podle hodnoty ''inspection-rate''. Pokud je v oblasti stanice více pasažérů, revizor zkontroluje tolik, kolik může podle této proměnné.

=== Pasažéři ===
Nakonec v modelu jsou pasažéři, které jsou před začátkem simulace čekají na náhodných stanicích. Po začátku simulace začínají pohybovat se po lince, ke které jsou přiřazeni, dokud nedorazí do cílové linky nebo nebudou zachyceni revizorem. Jejich atributy jsou:
* ''valid-ticket?'' — boolean hodnota, zda má platnou jízdenku nebo ne, podle ní je také nastavena barva pasažéra: bíla - má, fialová - ne
* ''state'' — stav, v jakém je: ''waiting'' (čeká na stanici) nebo ''traveling'' (v pohybu)
* ''line'' — linka, po které se pohybuje
* ''current-index'' — aktuální nebo poslední navštívená stanice
* ''destination-index'' — cílová stanice

=== Globální proměnné ===
* ''station-list-A/B/C'' — seznamy stanic
* ''inspection-rate'' — míra kontrol za tick
* ''fare-evasion-rate'' — míra jízd bez jízdenky
* ''max-ticks'' — počet ticků pro zastavení simulace
* ''passenger-spawn-rate'' — kolik vznikne pasažérů na stanici při generování pasažerů
* ''num-inspectors'' — počet revizorů, musí odpovídat počtu elementů v ''inspector-assignments''
* ''total-fines'' — počet udělených pokut za běh
* ''total-evaders'' — počet černých pasažérů za běh
* ''inspector-assignments'' — seznam s se stanicemi, kde jsou revizoři, musí odpovídat ''num-inspectors''
* ''total-spawned'' — počet pasažérů za běh

=== Propojení na data ===
Aby model mohl odpovídat realitě (s určitými omezeními), byla získána data pro daný kontext. Například míra cestujících bez platné jízdenky byla odhadnuta dle zdrojů na 8% pro Prahu, pak porovnána s jinými státy pro jistotu a byla ponechána na 8%. Výše pokuty je 1500 Kč dle DPP. Další skutečností je plat revizorů, který činí 63000 Kč (je to včetně bonusů za pokuty, ale bylo počítáno s maximem) — sice v simulaci použit nebyl, ale hodil se pro závěreční analýzu.

Zvolený počet cestujících, kteří denně využívají metro, je odvozen z dat o cestujících v MHD. 338 mil. — počet pasažérů ročně, tedy 926 tis. denně. Nejprve dané číslo bylo samozřejmě zkráceno kvůli omezením počítače a délky simulací, tedy vyděleno 10. Jelikož modelujeme jenom část metra (15/61 stanic, zhruba čtvrtina), můžeme počítat s menším počtem pasažérů, např. také s čtvrtinou. Čtvrtina od 92600 je zhruba 23000. Tak vznikl orientační počet denních cestujících v simulacích, kterého bylo pak dosaženo přes přesnější nastavení parametru ''passenger-spawn-rate''. Jak ukážou výsledky, počty denních cestujících se pohybovaly zpravidla v rozmezí 22000-25000, což odpovídá odhadu. Podobnou logiku má i počet revizorů. Podle nalezených dat obvykle v pracovní dny "v terénu" je kolem 100 revizorů, ale realističtější a vhodnější bylo operovat s menším počtem revizorů, takže je ten počet v simulacích kolem 10, s odchylkou pro konkrétní případy.

=== Časová osa simulace a dopravní špičky ===
Co se týká času simulace, jeden běh reprezentující jeden den trvá 2280 ticků, a to bylo odvozeno následovně. Bylo zjištěno, že metro je v provozu zhruba od 5 do 24, tedy 19 hodin, neboli 1140 minut. Bylo také rozhodnuto, že za tick je vhodné mít nejmenší časovou jednotku, kterou chceme reprezentovat, v daném případě je to odhad délky jedné kontroly, cca 30 sekund. Některé kontroly mohou být skoro okamžité, občas to může trvat déle, odhad je tedy ze zkušeností autora.

V rámci simulace jsou také zohledněny dopravní špičky. Intervaly 300-700 ticků považujeme za ranní špičku a 1500-1900 za odpolední/večerní špičku. Je to realizováno přes spuštění generování pasažérů ještě jednou, což dočasně na dobu špičky zvýší počet cestujících v metru. Po skončení špičky na několik ticků zastavíme obnovení pasažérů, aby se počet cestujících vrátil na základní úroveň. Než se to ale stane, musíme také zajistit vyšší počet kontrol, a je to uděláno pomocí proměnné ''inspection-rate''. Vyšší hodnota této proměnné znamená to, že revizor za jeden tick zkontroluje více cestujících, které se nachází kolem něj na dané stanici. To lze pozorovat na grafech: první je počet cestujících, druhý je počet udělených pokut v odpovídající časy.

[[File:MHD_grafy.png|center]]

=== Průběh simulace ===
Následující 4 body proběhnou při kliknutí na tlačítko '''setup''':

1. '''setup-network''' — nastavení sítě metra, určení souřadnic, sestavení seznamů stanic.

2. '''setup-parameters''' — nastavení globálních proměnných.

3. '''setup-inspectors''' — nastavení revizorů, vytvoří ''num-inspectors'' agentů a rozmístí je podle ''inspector-assignments''.

4. '''generate-passengers''' — generování pasažérů: vygeneruje ''passenger-spawn-rate'' * počet stanic (120), nastaví defaultní hodnoty atributů, náhodně nastaví boolean ''valid-ticket?'' dle ''fare-evasion-rate'' a pokud je to černý pasažér, zvýší ''total-evaders''.

Důležité procedury použité dále:

'''handle-passenger-death''' — procedura zajišťuje vznik nových pasažérů. Agenti-pasažéři se odstraní, když buď dorazí do cílové stanice nebo budou zachyceni revizorem, jsou pak ze simulace odstraněny. Na jejich místo je pak přidán nový pasažér, aby počet cestujících byl zachován. Daná procedura se nevolá během několika ticků po špičkách, aby se model vyrovnal po nárůstu cestujících během špiček.

'''do-walk-step''' — procedura pro pohyb cestujících mezi stanicemi. Každý cestující ve stavu ''traveling'' dělá krok směrem ke své cílové destinaci. Když dorazí do stanice, změní svůj ''current-index''. Pokud je ten index stejný jako cílová stanice, volá se ''handle-passenger-death''. Bylo rozhodnuto pro daný přístup, jelikož v původním návrhu vlaky (další agenti) neměly velký význam pro výsledky, vizuálně vypadaly mnohem hůř a zbytečně komplikovali model.

Dále při spuštění simulace se bude postupovat dle procedury '''go''':

1. Kontrola konce simulace (zda již uběhlo 2280 ticků).

2. Pohyb pomocí ''do-walk-step''.

3. Revizor provádí kontroly dle ''inspection-rate'' na stanici ze seznamu všech pasažérů, kdo tam je.

4. Pokud byl nalezen černý pasažér, zvyšuje ''total-fines'' a volá ''handle-passenger-death''.

5. Pokud se nacházíme ve špičkovém intervalu, zavolá se znovu ''generate-passengers''.

6. Tick.

=== Omezení ===
* Statické umístění revizorů: v modelu není zohledněna situace, když revizor se pohybuje mezi stanicemi a provádí kontroly ve vozech, což je celkem běžné. To by však znamenalo vytvoření vlaků a omezení s tím spojené, jak je uvedeno výše v popisu procedur.
* Odhady dat: přestože nalezená data pokrývají zkoumanou oblast dostatečně široko, nestačí pro hlubší analýzu. Simulace je prováděna na mnohem menších časových intervalech a se zaměřením na jevy, které nejsou dobře popsány.
* Chování při kontrolách: sice jsou kontroly funkční a jsou schopni zachytit podstatu, existuje i prostor na detailnější doladění, které by bylo náročnější a delší na implementaci.
* Fixní celkový počet: simulace nemá perfektně realistickou křivku zátěže metra, pouze znázornění dopravních špiček.

== Výsledky ==
V rámci provedení simulací bylo otestováno 6 různých scénářů, každý s odlišným počtem a/nebo umístěním revizorů. Každý scénář měl 30 opakování pro získání dostatku dat pro měsíc fungování metra, což pak bylo možné dát do souvislosti s náklady podniku na měsíční platy revizorů. Obrázek níže obsahuje všechny scénáře.

[[File:MHD_6_2.png|center]]

Scénáře jsou detailněji popsány dále a následně znázorněny v tabulce.

1. '''1 revizor na každé stanici (15):''' první scénář testoval nejširší pokrytí sítě metra, kde každá stanice byla obsazena jedním revizorem. Ze všech scénářů z pohledu udělení zachycení černých pasažérů je ten scénář nejlepší, protože poskytuje 87% míru zachycení, je to výrazný rozdíl oproti jiným rozmístěním. Ale ve skutečnosti jde nejen o plnou vytíženost revizorů, ale také o zážitek cestujících, které mohou být kontrolovány všude a několikrát. Je to také nejnákladnější přístup, který je částečně kompenzován velkým objemem pokut (největším).

2. '''4 revizoři na každé přestupní stanici (12):''' druhý scénář byl zaměřen na účelnější kontroly, revizoři jsou pouze na přestupních stanicích ve velkých počtech. Míra zachycení je již 68%, spolu s ní se také snížil i objem pokut, ale je to také nejdražší řešení z pohledu "náklady na revizory/příjmy z pokut".

3. '''2 revizoři na každé přestupní stanici (6):''' scénář podobný předchozímu, ale s menší koncentrací revizorů na přestupních stanicích. O něco horší výsledky než předchozí, nemá žádné důležité rysy, které by daný scénář dělaly výjimečným. Míra zachycení 61%. Pokud priorita je v ušetření prostředků na platy revizorům, mezi tímto a předchozím je lepší volit tento scénář, jinak předchozí má přednost.

4. '''1 revizor na středu každé linky (3):''' testuje malý počet revizorů. Ideální scénář, pokud rozpočet na platy revizorům je omezen, je to nejnižší ze všech scénářů. Však je schopen odhalit pouze 50% černých pasažérů kvůli nízké hustotě rozmístění.

5. '''1 revizor na každé konečné stanici (6):''' daný scénář lze považovat za nejhorší. Poskytuje nejnižší míru zachycení v pouhých 42%, objem pokut je také nejnižší, a to při stejných nákladech na plat revizorům jako v scénářích 3 a 6, což je v daném případě poměrně drahé.

6. '''2 revizoři na každé lince s odstupem (6):''' scénář umísťuje revizory na stanicích ve formátu 1-X-3-X-5 (X je revizor), tedy kombinuje široké pokrytí a relativně nižší počet revizorů oproti prvním dvěma scénářům. Je to dobře vyvážený scénář, který poskytuje druhou nejlepší míru zachycení na seznamu (70%) a druhý nejvyšší objem pokut. Přestože není absolutně nejlevnější z pohledu platů revizorů, v kontextu poměru platů k příjmům je to druhé nejlepší řešení.

Následující tabulka obsahuje shrnutí dat.

== Závěr ==

== Kód ==

== Reference ==

* Dopravní podnik hl. m. Prahy. (b.r.). ''Výše přirážky a doplatková pokladna.'' Dopravní podnik hl. m. Prahy, akciová společnost. Získáno 10. červen 2025, z https://www.dpp.cz/jizdne/pokuty-revizori/vyse-prirazky
* Jaroševský, F. (2024, prosinec 4). ''Průměrný plat revizora je 63 tisíc. Půlku z toho si musejí nachytat. „Jinak to nejde,“ tvrdí nadřízení.'' METRO.cz. https://www.metro.cz/praha/prumerny-plat-revizora-je-63-tisic-pulku-z-toho-si-museji-nachytat-jinak-to-nejde-tvrdi-nadrizeni.A241203_155006_metro-praha_mjafi
* Newkey-Burden, C. (2025, únor 18). ''Fare dodging: London’s transport blight''. The Week. https://theweek.com/transport/fare-dodging-londons-transport-blight
* Expats.cz (2023, červenec 9). ''Prague public transport inspectors handed out 250,000 fines last year.'' Expats.cz. https://www.expats.cz/czech-news/article/prague-public-transport-inspectors-handed-out-250-000-fines-last-year
* Pražská integrovaná doprava. (b.r.). ''Metro.'' Pražská integrovaná doprava. Získáno 10. červen 2025, z https://pid.cz/metro/
* Ubach, M. (2024, červenec 22). ''Tackling Fare Evasion in Bergamo: A Growing Challenge for ATB and TEB.'' Trainsfare. https://www.trainsfare.eu/tackling-fare-evasion-in-bergamo-a-growing-challenge-for-atb-and-teb/

File:MHD 6 2.png

2025-06-12T22:26:12Z

Sanv05:

File:MHD 6.jpg

2025-06-12T22:23:45Z

Sanv05: 6

== Summary ==
6

User:Sanv05

2025-06-12T22:05:27Z

Sanv05:

= Kontrola jízdenek v MHD =

== Definice problému ==
MHD je nedílnou součástí života v Praze. Aktuálním problémem v této sféře je cestování bez platného jízdného dokladu. Jelikož je dopravní podnik mimo jiné financován právě z příjmů z jízdného, daný problém představuje zdroj finančních ztrát. Představená simulace se zabývá optimalizací kontrol platnosti jízdních dokladů v systému pražské MHD. Její cílem je otestovat, jak počet a rozmístění revizorů v síti metra ovlivňují objem udělených pokut a míru zachycení černých pasažérů. Pomocí simulace lze najít vhodné inspekční strategie, které určí, kam a kolik revizorů umístit pro zefektivnění jejich práce. Výsledky simulace mohou pak sloužit jako doporučení pro dopravní podnik k tomu, jakou inspekční strategii zvolit pro optimalizaci kontrol jízdenek.

== Metoda ==
Pro vypracování multiagentní simulace byl použit nástroj NetLogo. Výhodou daného nástroje je velmi intuitivní prostředí, ve kterém uživatel může modelovat chování agentů, vytvářet vizualizace sítě stanic, průběhu a časového vývoje sledovaných parametrů simulace. NetLogo umožňuje rychlé nastavení vstupních parametrů, jako jsou umístění a počty revizorů, a okamžité sledování dopadu změn.

Jako alternativy byly hned na začátku odmítnuty obecné programovací jazyky a knihovny (složité nastavení a podrobné kódování) a deterministické modely (nezachycují náhodu při kontrolách platnosti jízdenky). Nástroje na systémovou dynamiku, např. Vensim, by pak nedokázaly reprezentovat přesné umístění revizorů a jednotlivé agenty s platnou či neplatnou jízdenkou, proto bylo zvoleno NetLogo.

Pro agregaci dat z většího počtu běhů a analýzu výsledků z různých scénářů byl použit Microsoft Excel. Je to známé, rychlé a obecně standardní řešení pro podobné úlohy.

== Model ==
=== Stanice ===
Základem modelu je prostředí, ve kterém bude probíhat simulace. Je to reprezentace centrální části pražského metra, která zahrnuje 3 linky (A, B, C). Vzhledem k výkonnostním a vizuálním omezením bylo rozhodnuto zobrazit pouze 5 stanic každé linky, tedy dohromady 15 stanic:
* Linka '''A''' — Staroměstská, Můstek, Muzeum, Náměstí míru, Jiřího z Poděbrad
* Linka '''B''' — Karlovo náměstí, Národní třída, Můstek, Náměstí republiky, Florenc
* Linka '''C''' — I. P. Pavlova, Muzeum, Hlavní nádraží, Florenc, Vltavská
V rámci modelu v kódu NetLogo jsou pojmenovány symbolicky (A1-A5, B1-B5, C1-C5) pro jednodušší správu rozmístění. Každá stanice je agent ''station'', který má jako jeden z atributů název konkrétní linky, jejíž součástí je. Stanice jedné linky jsou mezi sebou pak vizuálně spojeny, obarveny a zařazeny do jednoho z globálních seznamů ''station-list-X'', kde X je název linky. Tím způsobem je vytvořena linka jako posloupnost stanic, tři takové linky tvoří výsledné prostředí.

[[File:MHD_mapa.png|center]]

=== Revizoři ===
Další agenti jsou revizoři, reprezentované v modelu modrými kruhy vedle stanic. Jsou přiřazeny ke stanici, kde pak zůstávají a kontrolují pasažéry (pokud jsou na dané stanici) podle hodnoty ''inspection-rate''. Pokud je v oblasti stanice více pasažérů, revizor zkontroluje tolik, kolik může podle této proměnné.

=== Pasažéři ===
Nakonec v modelu jsou pasažéři, které jsou před začátkem simulace čekají na náhodných stanicích. Po začátku simulace začínají pohybovat se po lince, ke které jsou přiřazeni, dokud nedorazí do cílové linky nebo nebudou zachyceni revizorem. Jejich atributy jsou:
* ''valid-ticket?'' — boolean hodnota, zda má platnou jízdenku nebo ne, podle ní je také nastavena barva pasažéra: bíla - má, fialová - ne
* ''state'' — stav, v jakém je: ''waiting'' (čeká na stanici) nebo ''traveling'' (v pohybu)
* ''line'' — linka, po které se pohybuje
* ''current-index'' — aktuální nebo poslední navštívená stanice
* ''destination-index'' — cílová stanice

=== Globální proměnné ===
* ''station-list-A/B/C'' — seznamy stanic
* ''inspection-rate'' — míra kontrol za tick
* ''fare-evasion-rate'' — míra jízd bez jízdenky
* ''max-ticks'' — počet ticků pro zastavení simulace
* ''passenger-spawn-rate'' — kolik vznikne pasažérů na stanici při generování pasažerů
* ''num-inspectors'' — počet revizorů, musí odpovídat počtu elementů v ''inspector-assignments''
* ''total-fines'' — počet udělených pokut za běh
* ''total-evaders'' — počet černých pasažérů za běh
* ''inspector-assignments'' — seznam s se stanicemi, kde jsou revizoři, musí odpovídat ''num-inspectors''
* ''total-spawned'' — počet pasažérů za běh

=== Propojení na data ===
Aby model mohl odpovídat realitě (s určitými omezeními), byla získána data pro daný kontext. Například míra cestujících bez platné jízdenky byla odhadnuta dle zdrojů na 8% pro Prahu, pak porovnána s jinými státy pro jistotu a byla ponechána na 8%. Výše pokuty je 1500 Kč dle DPP. Další skutečností je plat revizorů, který činí 63000 Kč (je to včetně bonusů za pokuty, ale bylo počítáno s maximem) — sice v simulaci použit nebyl, ale hodil se pro závěreční analýzu.

Zvolený počet cestujících, kteří denně využívají metro, je odvozen z dat o cestujících v MHD. 338 mil. — počet pasažérů ročně, tedy 926 tis. denně. Nejprve dané číslo bylo samozřejmě zkráceno kvůli omezením počítače a délky simulací, tedy vyděleno 10. Jelikož modelujeme jenom část metra (15/61 stanic, zhruba čtvrtina), můžeme počítat s menším počtem pasažérů, např. také s čtvrtinou. Čtvrtina od 92600 je zhruba 23000. Tak vznikl orientační počet denních cestujících v simulacích, kterého bylo pak dosaženo přes přesnější nastavení parametru ''passenger-spawn-rate''. Jak ukážou výsledky, počty denních cestujících se pohybovaly zpravidla v rozmezí 22000-25000, což odpovídá odhadu. Podobnou logiku má i počet revizorů. Podle nalezených dat obvykle v pracovní dny "v terénu" je kolem 100 revizorů, ale realističtější a vhodnější bylo operovat s menším počtem revizorů, takže je ten počet v simulacích kolem 10, s odchylkou pro konkrétní případy.

=== Časová osa simulace a dopravní špičky ===
Co se týká času simulace, jeden běh reprezentující jeden den trvá 2280 ticků, a to bylo odvozeno následovně. Bylo zjištěno, že metro je v provozu zhruba od 5 do 24, tedy 19 hodin, neboli 1140 minut. Bylo také rozhodnuto, že za tick je vhodné mít nejmenší časovou jednotku, kterou chceme reprezentovat, v daném případě je to odhad délky jedné kontroly, cca 30 sekund. Některé kontroly mohou být skoro okamžité, občas to může trvat déle, odhad je tedy ze zkušeností autora.

V rámci simulace jsou také zohledněny dopravní špičky. Intervaly 300-700 ticků považujeme za ranní špičku a 1500-1900 za odpolední/večerní špičku. Je to realizováno přes spuštění generování pasažérů ještě jednou, což dočasně na dobu špičky zvýší počet cestujících v metru. Po skončení špičky na několik ticků zastavíme obnovení pasažérů, aby se počet cestujících vrátil na základní úroveň. Než se to ale stane, musíme také zajistit vyšší počet kontrol, a je to uděláno pomocí proměnné ''inspection-rate''. Vyšší hodnota této proměnné znamená to, že revizor za jeden tick zkontroluje více cestujících, které se nachází kolem něj na dané stanici. To lze pozorovat na grafech: první je počet cestujících, druhý je počet udělených pokut v odpovídající časy.

[[File:MHD_grafy.png|center]]

=== Průběh simulace ===
Následující 4 body proběhnou při kliknutí na tlačítko '''setup''':

1. '''setup-network''' — nastavení sítě metra, určení souřadnic, sestavení seznamů stanic.

2. '''setup-parameters''' — nastavení globálních proměnných.

3. '''setup-inspectors''' — nastavení revizorů, vytvoří ''num-inspectors'' agentů a rozmístí je podle ''inspector-assignments''.

4. '''generate-passengers''' — generování pasažérů: vygeneruje ''passenger-spawn-rate'' * počet stanic (120), nastaví defaultní hodnoty atributů, náhodně nastaví boolean ''valid-ticket?'' dle ''fare-evasion-rate'' a pokud je to černý pasažér, zvýší ''total-evaders''.

Důležité procedury použité dále:

'''handle-passenger-death''' — procedura zajišťuje vznik nových pasažérů. Agenti-pasažéři se odstraní, když buď dorazí do cílové stanice nebo budou zachyceni revizorem, jsou pak ze simulace odstraněny. Na jejich místo je pak přidán nový pasažér, aby počet cestujících byl zachován. Daná procedura se nevolá během několika ticků po špičkách, aby se model vyrovnal po nárůstu cestujících během špiček.

'''do-walk-step''' — procedura pro pohyb cestujících mezi stanicemi. Každý cestující ve stavu ''traveling'' dělá krok směrem ke své cílové destinaci. Když dorazí do stanice, změní svůj ''current-index''. Pokud je ten index stejný jako cílová stanice, volá se ''handle-passenger-death''. Bylo rozhodnuto pro daný přístup, jelikož v původním návrhu vlaky (další agenti) neměly velký význam pro výsledky, vizuálně vypadaly mnohem hůř a zbytečně komplikovali model.

Dále při spuštění simulace se bude postupovat dle procedury '''go''':

1. Kontrola konce simulace (zda již uběhlo 2280 ticků).

2. Pohyb pomocí ''do-walk-step''.

3. Revizor provádí kontroly dle ''inspection-rate'' na stanici ze seznamu všech pasažérů, kdo tam je.

4. Pokud byl nalezen černý pasažér, zvyšuje ''total-fines'' a volá ''handle-passenger-death''.

5. Pokud se nacházíme ve špičkovém intervalu, zavolá se znovu ''generate-passengers''.

6. Tick.

=== Omezení ===
* Statické umístění revizorů: v modelu není zohledněna situace, když revizor se pohybuje mezi stanicemi a provádí kontroly ve vozech, což je celkem běžné. To by však znamenalo vytvoření vlaků a omezení s tím spojené, jak je uvedeno výše v popisu procedur.
* Odhady dat: přestože nalezená data pokrývají zkoumanou oblast dostatečně široko, nestačí pro hlubší analýzu. Simulace je prováděna na mnohem menších časových intervalech a se zaměřením na jevy, které nejsou dobře popsány.
* Chování při kontrolách: sice jsou kontroly funkční a jsou schopni zachytit podstatu, existuje i prostor na detailnější doladění, které by bylo náročnější a delší na implementaci.
* Fixní celkový počet: simulace nemá perfektně realistickou křivku zátěže metra, pouze znázornění dopravních špiček.

== Výsledky ==
V rámci provedení simulací bylo otestováno 6 různých scénářů, každý s odlišným počtem a/nebo umístěním revizorů. Každý scénář měl 30 opakování pro získání dostatku dat pro měsíc fungování metra, což pak bylo možné dát do souvislosti s náklady podniku na měsíční platy revizorů.

1. '''1 revizor na každé stanici (15)'''

2. '''4 revizoři na každé přestupní stanici (12)'''

3. '''2 revizoři na každé přestupní stanici (6)'''

4. '''1 revizor na středu každé linky (3)'''

5. '''1 revizor na každé konečné stanici (6)'''

6. '''2 revizoři na každé lince s odstupem (6)'''

== Závěr ==

== Kód ==

== Reference ==

* Dopravní podnik hl. m. Prahy. (b.r.). ''Výše přirážky a doplatková pokladna.'' Dopravní podnik hl. m. Prahy, akciová společnost. Získáno 10. červen 2025, z https://www.dpp.cz/jizdne/pokuty-revizori/vyse-prirazky
* Jaroševský, F. (2024, prosinec 4). ''Průměrný plat revizora je 63 tisíc. Půlku z toho si musejí nachytat. „Jinak to nejde,“ tvrdí nadřízení.'' METRO.cz. https://www.metro.cz/praha/prumerny-plat-revizora-je-63-tisic-pulku-z-toho-si-museji-nachytat-jinak-to-nejde-tvrdi-nadrizeni.A241203_155006_metro-praha_mjafi
* Newkey-Burden, C. (2025, únor 18). ''Fare dodging: London’s transport blight''. The Week. https://theweek.com/transport/fare-dodging-londons-transport-blight
* Expats.cz (2023, červenec 9). ''Prague public transport inspectors handed out 250,000 fines last year.'' Expats.cz. https://www.expats.cz/czech-news/article/prague-public-transport-inspectors-handed-out-250-000-fines-last-year
* Pražská integrovaná doprava. (b.r.). ''Metro.'' Pražská integrovaná doprava. Získáno 10. červen 2025, z https://pid.cz/metro/
* Ubach, M. (2024, červenec 22). ''Tackling Fare Evasion in Bergamo: A Growing Challenge for ATB and TEB.'' Trainsfare. https://www.trainsfare.eu/tackling-fare-evasion-in-bergamo-a-growing-challenge-for-atb-and-teb/

User:Sanv05

2025-06-12T20:19:10Z

Sanv05:

File:MHD grafy.png

2025-06-12T20:17:54Z

Sanv05: mhd grafy

== Summary ==
mhd grafy

User:Sanv05

2025-06-12T20:16:19Z

Sanv05:

File:MHD mapa.png

2025-06-12T20:14:53Z

Sanv05: mapa mhd

== Summary ==
mapa mhd

User:Sanv05

2025-06-12T20:10:00Z

Sanv05:

User:Sanv05

2025-06-12T19:22:15Z

Sanv05:

User:Sanv05

2025-06-12T15:13:50Z

Sanv05:

User:Sanv05

2025-06-12T14:16:42Z

Sanv05:

User:Sanv05

2025-06-10T17:15:59Z

Sanv05:

== Kontrola jízdenek v MHD ==

=== Definice problému ===

=== Metoda ===

=== Model ===

=== Výsledky ===

=== Závěr ===

=== Kód ===

=== Reference ===

* Dopravní podnik hl. m. Prahy. (b.r.). ''Výše přirážky a doplatková pokladna.'' Dopravní podnik hl. m. Prahy, akciová společnost. Získáno 10. červen 2025, z https://www.dpp.cz/jizdne/pokuty-revizori/vyse-prirazky
* Jaroševský, F. (2024, prosinec 4). ''Průměrný plat revizora je 63 tisíc. Půlku z toho si musejí nachytat. „Jinak to nejde,“ tvrdí nadřízení.'' METRO.cz. https://www.metro.cz/praha/prumerny-plat-revizora-je-63-tisic-pulku-z-toho-si-museji-nachytat-jinak-to-nejde-tvrdi-nadrizeni.A241203_155006_metro-praha_mjafi
* Newkey-Burden, C. (2025, únor 18). ''Fare dodging: London’s transport blight''. The Week. https://theweek.com/transport/fare-dodging-londons-transport-blight
* Expats.cz (2023, červenec 9). ''Prague public transport inspectors handed out 250,000 fines last year.'' Expats.cz. https://www.expats.cz/czech-news/article/prague-public-transport-inspectors-handed-out-250-000-fines-last-year
* Pražská integrovaná doprava. (b.r.). ''Metro.'' Pražská integrovaná doprava. Získáno 10. červen 2025, z https://pid.cz/metro/
* Ubach, M. (2024, červenec 22). ''Tackling Fare Evasion in Bergamo: A Growing Challenge for ATB and TEB.'' Trainsfare. https://www.trainsfare.eu/tackling-fare-evasion-in-bergamo-a-growing-challenge-for-atb-and-teb/

User:Sanv05

2025-06-10T13:32:19Z

Sanv05: Created page with "== Kontrola jízdenek v MHD == === Definice problému === === Metoda === === Model === === Výsledky === === Závěr === === Kód === === Reference === * Dopravní pod..."

== Kontrola jízdenek v MHD ==

=== Definice problému ===

=== Metoda ===

=== Model ===

=== Výsledky ===

=== Závěr ===

=== Kód ===

=== Reference ===

* Dopravní podnik hl. m. Prahy. (b.r.). ''Výše přirážky a doplatková pokladna.'' Dopravní podnik hl. m. Prahy, akciová společnost. Získáno 10. červen 2025, z https://www.dpp.cz/jizdne/pokuty-revizori/vyse-prirazky

* Jaroševský, F. (2024, prosinec 4). ''Průměrný plat revizora je 63 tisíc. Půlku z toho si musejí nachytat. „Jinak to nejde,“ tvrdí nadřízení.'' METRO.cz. https://www.metro.cz/praha/prumerny-plat-revizora-je-63-tisic-pulku-z-toho-si-museji-nachytat-jinak-to-nejde-tvrdi-nadrizeni.A241203_155006_metro-praha_mjafi

* Newkey-Burden, C. (2025, únor 18). ''Fare dodging: London’s transport blight''. The Week. https://theweek.com/transport/fare-dodging-londons-transport-blight

* Expats.cz (2023, červenec 9). ''Prague public transport inspectors handed out 250,000 fines last year.'' Expats.cz. https://www.expats.cz/czech-news/article/prague-public-transport-inspectors-handed-out-250-000-fines-last-year

* Pražská integrovaná doprava. (b.r.). ''Metro.'' Pražská integrovaná doprava. https://pid.cz/metro/

* Ubach, M. (2024, červenec 22). ''Tackling Fare Evasion in Bergamo: A Growing Challenge for ATB and TEB.'' Trainsfare. https://www.trainsfare.eu/tackling-fare-evasion-in-bergamo-a-growing-challenge-for-atb-and-teb/

Assignment SS 2024/2025/cs

2025-05-16T09:09:20Z

Sanv05:

{{Ambox
| text = <div>
Please, put here your assignments. Do not forget to sign them. You can use <nowiki>~~~~</nowiki> (four tildas) for an automatic signature. Use Show preview in order to check the result before your final sumbition.
</div>
}}

{{Ambox
| text = <div>
Please, strive to formulate your assignment carefully. We expect an adequate effort to formulate the assignment as it is your semestral paper. Do not forget that your main goal is a research paper. It means your simulation model must generate the results that are specific, measurable and verifiable. Think twice how you will develop your model, which entities you will use, draw a model diagram, consider what you will measure. No sooner than when you have a good idea about the model, submit your assignment. And of course, read [[How to deal with the simulation assignment|How to deal with the simulation assignment]].
</div>
}}

{{Ambox
| text = <div>
Topics on gambling, cards, etc. are not welcome.
</div>
}}

{{Ambox
| type = content
| text = <div>
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.
</div>
}}

{{Ambox
| text = <div>
'''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).'''

# Is it clear from the proposed assignment how the simulation will work?
# Does the simulation make sense?
# Is the simulation model complex enough to simulate credibly the real-world phenomenon that the simulation tries to simulate?
# Is the data used real and relevant for the real-world phenomenon that the simulation tries to simulate?
# 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.'''

</div>
}}

== Simulace výběru optimální lokality pro koupi nemovitosti s ohledem na budoucí rizika ==

=== Popis problému ===
Simulace bude modelovat rozhodovací proces investora při výběru bezpečné lokality pro investici do nemovitosti kdekoliv na světě, s ohledem na budoucí rizika. V rozhodovacím procesu hraje roli celá řada faktorů – od historického vývoje cen nemovitostí, přes kriminalitu a politickou stabilitu až po klimatická rizika, jako jsou záplavy, stoupání mořské hladiny nebo úbytek vody. Cílem je určit, které lokality mají vysoký potenciál růstu hodnoty a zároveň co nejnižší rizika v horizontu příštích lét či dekád. Téma je obvzláště aktuální vzhledem k politickému dění naší doby.

=== Cíl simulace ===
Cílem simulace je analyzovat:
*Dlouhodobou rizikovost jednotlivých lokalit pro investice do nemovitostí
*Vliv globálních trendů (klima, migrace, infrastruktura, ekonomický vývoj) na budoucí výnos
*Identifikaci zón, kde se předpokládá stabilní růst
*Dopad scénářů (např. klimatická krize, politické otřesy) na hodnotu investice
*Zohlednění takových proměnných jako cena nemovitosti, kriminalita ve vybrané lokalitě aj.

=== Použití simulace ===
*Fyzickými osobami
*Soukromými investory a fondy investujícími do rezidenčních i komerčních nemovitostí
*Analytiky bank a pojišťoven při určování pojistných rizik nemovitostí a rizik poskytování finančních prostředků ke koupi oných nemovitostí
*Urbanisty a plánovači udržitelného rozvoje měst
*Pro prediktivní analýzy trhu

=== Použitá metoda a prostředí ===
*Monte Carlo simulace s vícero scénáři budoucího vývoje
*Simulační prostředí: Excel (potenciálně NetLogo, pokud mě během práce napadne jak to pojmout pomocí tohoto nástroje, například by mohl být za agenty považováni investoři s různými preferencemi a tolerancí k riziku)
*Simulace je stavěná na lokalitách (nejspíše to budou města) s atributy přiřazenými z reálných datových zdrojů a i náhodnými proměnnými

=== Proměnné ===
Definované předem:
*location - geografická lokalita 
*property_value - současná průměrná cena nemovitosti
*climate_risk_index - souhrnný index klimatického rizika (záplavy, sucho, mořská hladina, požáry)
*infrastructure_score - skóre infrastruktury a dopravní dostupnosti
*governance_index - kvalita vládnutí a právní ochrany
*historical_growth - průměrný roční růst cen nemovitostí za posledních X let
*další proměnné co mě napadnou a budou dávat smysl

Náhodné:
*political_instability - pravděpodobnost politických nepokojů nebo regulačních změn
*population_flow - změna počtu obyvatel (vliv migrace, urbanizace)
*climate_event_frequency - frekvence extrémních klimatických jevů v následujících X letech
*investment_sentiment - nálada investorů a pravděpodobnost, že investoři danou lokalitu upřednostní
*economic_shock - externí šoky (např. finanční krize) ovlivňující hodnotu
*další proměnné co mě napadnou a budou dávat smysl

=== Data ===
*Cost of Living https://www.numbeo.com/cost-of-living/
*Climate Risk Index 2025 https://www.germanwatch.org/en/cri
*World cities report 2024 https://unhabitat.org/wcr/
*Housing prices https://www.oecd.org/en/data/indicators/housing-prices.html?oecdcontrol-82d381eddd-var3=2025
*Crime https://www.numbeo.com/crime/
*Catastrophe Data Hub https://www.eiopa.europa.eu/tools-and-data/catastrophe-data-hub_en
*další data která během práce a rešerše najdu a budu považovat za relevantní

=== Simulant ===
[[User:Isar00|Isar00]] ([[User talk:Isar00|talk]]) 22:01, 13 May 2025 (CET)
:: Na Monte Carlo to moc nevidím, nedokážu si představit, jak pro uvedené náhodné proměnné budete odvozovat pravděpodobnostní rozdělení. Asi by by to šlo ve Vensimu - co vy na to? [[User:Oleg.Svatos|Oleg.Svatos]] ([[User talk:Oleg.Svatos|talk]]) 07:20, 14 May 2025 (CET)
:: Já se hlavně obávám, že je to úloha sice zajímavá, ale velmi obtížně řešitelná. Resp. k nějakým výsledkům se určitě dojde, ale jejich ověření bude nesmírně problematické. Doporučoval bych přemýšlet o něčem jiném. [[User:Tomáš|Tomáš]] ([[User talk:Tomáš|talk]]) 12:19, 14 May 2025 (CET)

== Simulace: Sebe-deportační program pro nelegální vetřelce v USA ==

=== Popis problému ===
Simulace bude modelovat rozhodovací proces nelegálních migrantů („illegal aliens“) v USA v rámci nového programu sebe-deportace prostřednictvím aplikace CBP Home. Tento program nabízí finanční odměnu ve výši 1 000 USD a bezplatný let „kamkoliv“ výměnou za dobrovolný odchod ze země. Pomocí této iniciativy dle slov prezidenta Trumpa ušetří daňoví poplatníci v USA „miliardy a miliardy“ dolarů.

=== Cíl simulace ===
Cílem simulace je analyzovat program sebe-deportace z hlediska:
*Počtu migrantů, kteří se rozhodnou program využít
*Finančních úspor pro vládu USA ve srovnání s náklady na nucené deportace
*Klíčových faktorů ovlivňujících rozhodnutí migrantů

=== Použití simulace ===
*Ministerstvem vnitřní bezpečnosti USA pro odhad efektivity programu a optimalizaci politiky sebe-deportace
*Týmem Donalda Trumpa pro další predikci ohledně úspor daňových poplatníků
*Výzkumnými institucemi pro analýzu dopadů imigračních politik na chování migrantů

=== Použitá metoda a prostředí ===
*NetLogo
*Každý agent bude reprezentovat jednotlivého vetřelce s vlastními atributy stanovenými pomocí níže uvedených proměnných. Na základě těchto atributů a definovaných pravidel se agenti budou rozhodovat, zda program sebe-deportace využijí. Prostředí simulace bude tvořeno mřížkou, kde jednotlivé buňky mohou reprezentovat různé geografické oblasti s odlišnou úrovní vymáhání práva. Agenti se mohou pohybovat po této mřížce.

=== Proměnné ===
Definované předem:
*enforcement_level - úroveň vymáhání imigračního práva v daném regionu
*incentive_amount - výše finanční pobídky za sebe-deportaci (1000 USD)
*awareness_level - informovanost migranta existenci o programu (s časem roste)
*time_since_policy - doba od spuštění programu

Náhodné:
*decision_to_leave - rozhodnutí migranta odejít (ano/ne) na základě vypočtené pravděpodobnosti (ovlivněné jeho atributy)
*risk_of_enforcement - riziko zadržení a deportace
*trust_in_government - důvěra migranta ve vládní instituce a sliby
*family_pressure - tlak rodiny na rozhodnutí zůstat nebo odejít

=== Data ===
*AMERICAN IMMIGRATION COUNCIL, 2025. U.S. Immigration Statistics. American Immigration Council [online]. [vid. 2025-05-13]. Dostupné z: https://map.americanimmigrationcouncil.org/locations/national/
*BATALOVA, Jeanne Batalova Jeanne, 2025. Frequently Requested Statistics on Immigrants and Immigration in the United States. migrationpolicy.org [online] [vid. 2025-05-13]. Dostupné z: https://www.migrationpolicy.org/article/frequently-requested-statistics-immigrants-and-immigration-united-states
*BELL, Peter, 2024. Public Trust in Government: 1958-2024. Pew Research Center [online]. [vid. 2025-05-13]. Dostupné z: https://www.pewresearch.org/politics/2024/06/24/public-trust-in-government-1958-2024/
*DHS.GOV, 2025. DHS Announces Historic Travel Assistance and Stipend for Voluntary Self-Deportation | Homeland Security [online] [vid. 2025-05-13]. Dostupné z: https://www.dhs.gov/news/2025/05/05/dhs-announces-historic-travel-assistance-and-stipend-voluntary-self-deportation?utm_source=chatgpt.com
*ICE.GOV, 2025. ICE Enforcement and Removal Operations Statistics | ICE [online] [vid. 2025-05-13]. Dostupné z: https://www.ice.gov/statistics
*+další statistická data

=== Simulant ===
[[User:Masd04|Masd04]] ([[User talk:Masd04|talk]]) 15:50, 13 May 2025 (CET)
:: Téma je bezesporu originální a oceňuji satirickou notu, kterou v něm cítím. Ale je velmi obtížně vyhodnotitelné. Pracujete s velmi měkkými veličinami, výsledky by byly nesmírně těžko prokazatelné. Popřemýšlejte o tom prosím ještě, případně navrhněte něco jiného. [[User:Tomáš|Tomáš]] ([[User talk:Tomáš|talk]]) 12:32, 14 May 2025 (CET)

== Simulace: Bakterie na rukou ==

=== Popis problému ===
Bakterie, stejně jako jiné mikroorganismy, jsou přítomny kolem nás a končí pak i na našich rukou. Některé mohou být pro člověka zdrojem infekcí. Je proto důležité dbát na řádnou hygienu a umývat si ruce pečlivě.

=== Cíl simulace ===
Cílem bude simulovat množství bakterií (od virů, prvoků apod. abstrahuji pro zjednodušení) na povorchu lidské ruky (abstrahuji od rozdílu mezi dominantní a nedominantní) za běžného dne a jaký na něj vliv má četnost a kvalita mytí rukou.

=== Použití simulace ===
* Edukativní – názorná ukázka např. dětem
* Simulace účinku mycích prostředků

=== Použitá metoda a prostředí ===
Simulace v NetLogo. Bakterie budou existovat na povrchu ruky (respektive dlaně). S postupem času vznikají události navyšující počet bakterií (např. použití wc – bude záviset na dostupnosti dat). Události mytí rukou jejich počet naopak sníži – míra závisí na použitém přípravku (např. pouze voda, mýdlo, 70% ethanol) a kvalitě (pečlivosti) mytí. Mokré ruce na sebe nachytávají více bakterií.

Je možné, že simulace bude "interaktivní" v tom smyslu, že uživatel simulace bude mít možnost spouštět (nebo nespouštět) jednotlivé události které zvyšují počet bakterií a události mytí rukou. Tuto verzi osobně preferuji (interaktivní materiály zpravidla naučí více), nicméně ve výsledku bude záviset na možnostech NetLoga a mé schopnosti s kódem.

=== Proměnné ===
Definované předem:
* Bakterie – pobývají na povrchu ruky
* Účinnost přípravku – jak účinně (%) přípravek redukuje počet bakterií
* Typ člověka – jak čistotný majitel ruky je –> jak kvalitně si myje ruce a jestli jsou suché (T/F)

Náhodné:
* Rozmístění bakterií.
* Příbytek bakterií (počet v rámci daného rozmezí)

=== Data ===
* https://www.ccmhhealth.com/clean-hands-count/
* https://www.cdc.gov/clean-hands/data-research/facts-stats/index.html
* https://www.idnes.cz/onadnes/zdravi/co-zije-na-vasich-dlanich.A081110_123959_zdravi_bad
* další – najít data s konkrétnímy čísly zabere více času než mám aktuálně k dispozici.
Věřím však, že to bude možné. Případně přizpůsobím nějaké proměnné nalezeným datům (např. pokud mi kvalitní data umožní přidat proměnné nebo nějaké nahradit), aby práce byla podložena daty.

=== Simulant ===
[[User:Jana19|Jana19]] ([[User talk:Jana19|talk]]) 21:57, 12 May 2025 (CET)

: Téma vypadá dobře, moc se mi jen nelíbí, že hlavně proměnné jsou hodně "měkké". Nejhorší v tomto smyslu je ten "typ člověka". Jak to budete hodnotit, kolik lidí kterého typu existuje - kór, když jde o kritérium binární? Zkuste to dopracovat a najít "tvrdší" charakteristiky, ke kterým data snáze najdete. Co třeba typy povrchů? [[User:Tomáš|Tomáš]] ([[User talk:Tomáš|talk]]) 12:39, 14 May 2025 (CET)

RE: Typ člověka není binární kritérium, binární je poze to, zda jsou ruce mokré nebo suché – tedy mokré: True/False. Což ale souvistí s tím typem člověka, který by měl popisovat, jak dobře si ruce myje a suší. Ze sušení pak vzniká ta binární proměnná. To jak kvalitně si myje ruce si představuji jako nějaký koeficient – hodnota z nějakého rozmezí, kterou bych poté vynásobila účinek mycího prostředku aby se vyhodnotil úbytek bakterií.
Konkrétní pobobu toho typu člověka musím ještě promyslet, hlavně podle toho jak najdu data – pravděpodobně to bude odvozené z délky mytí rukou (kolik je potřeba a kolik tomu lidé obvykle dají). Ale jedna z možností, co mě napadla by bylo vytvoření archetypů jako "špindíra" a "poctivec", které by ten koeficient nastavili na určitou honotu. Ale mohla bych tam asi dát i možnost uživateli si jej nastait, jak chce (tedy v nějaké pro uživatele stravitelné podobě).
Myslíte, že bude stačit takto ten koeficient, nebo tam budete chtít i zanést nějakou míru náhody (jako náhodnou odchylku +- xy % při akci mytí rukou)?

== Simulace: Chování zákazníků v supermarketu/večerce ==

=== Popis problému ===
Supermarkety čelí výzvám při optimalizaci rozložení regálů a organizace prostoru, aby maximalizovaly zisk a zkrátily dobu nákupu tak, aby se prostory nepřeplnily. Zákazníci mají různá nákupní chování, přičemž někteří nakupují plánovaně, jiní se rozhodují impulzivně nebo reagují na nabídky slev. Tyto faktory spolu s hustotou zákazníků, pozicemi zboží a frontami mohou mít zásadní vliv na efektivitu nákupního procesu.

=== Cíl simulace ===
Cílem simulace je zjistit, jak správné rozmístění regálů napomůže efektivitě supermarketu/večerky. Toho by mělo být dosaženo zakomponováním různých faktorů, které chod ovlivňují, jako je rozložení zboží, počet zákazníků a jejich chování, slevy, Délku pobytu v obchodě, Zatížení jednotlivých uliček a zón, Pravděpodobnost nákupu akčního zboží, Fronty u pokladen....

Simulace by měla pomoci v návrhu efektivního rozmístění a optimalizaci nákupního procesu.

=== Použití simulace ===
Kdo může simulaci použít?
* Marketingová oddělení
* večerky
* supermarkety
* Designeři obchodních prostorů

=== Použitá metoda a prostředí ===
Simulace bude vytvořena v NetLogo, které umožní modelovat prostor supermarketu, pohyb zákazníků a jejich chování. Každý zákazník, zboží, sleva je považován za agenta, který interaguje s prostředím (supermarketem) a dalšími agenty (ostatními zákazníky). Model bude simulovat různé množství zákazníků, rozmístění zboží, slevy.

=== Proměnné ===
Definované předem:

* Rozložení obchodu: Počet regálů, uliček,...
* Průměrná doba strávená na pokladně
* Kapacita pokladen
* Počet zón v obchodě: Zóny jako ovoce, zelenina, pečivo, nápoje,...
* Typy zboží v prodeji
* Typ slevové akce

Náhodné:
* Typ zákazníka - plánovaný nákup, impulzivní nákup, procházející,...
* Doba rozhodování o nákupu - např. plánovaný 5-10sec, impulzivní - x sec,...
* Rychlost pohybu zákazníka
* Počet zákazníků v obchodě
* Umístění zboží ve slevě - v simulaci bych mohl ozkoušet i druhou verzi kdy bude umístění vždy stejné.

=== Data ===

* Prostředí supermarketu [https://www.zboziaprodej.cz/2023/04/04/jak-ovlivnuje-zakazniky-prostredi-ve-kterem-nakupuji/]
* Grocery layout [https://www.wavegrocery.com/blogpost/use-your-grocery-store-layout-to-boost-sales?]
* Kapacita/rychlost pokladen [https://www.millsshelving.com.au/how-to-create-an-inviting-retail-store-layout/]
* Layout [https://planohero.com/en/blog/grocery-store-layout-strategy/]
* How to Create an Inviting Retail Store Layout [https://www.millsshelving.com.au/how-to-create-an-inviting-retail-store-layout/?]
* How Understanding Your Grocery Store’s Layout Can Save You Money [https://www.goodrx.com/well-being/diet-nutrition/grocery-store-layout?]
* Typy zákazníků [https://strate9y.com/analyza-zakazniku-tajemstvi-uspechu-podnikani/?]
* Rozložení prodejen v Čr

=== Simulant ===
[[User:Kubd06|Kubánek David (kubd06)]] ([[User talk:Kubd06|talk]]) 22:00, 12 May 2025 (CET)

: '''Schváleno'''. Téma dobré, jen si dejte pozor na "měkké" proměnné. Třeba to striktní oddělení impulzivního/normálního nákupu není podle mě realistické a neseženete k tomu data. Raději bych pracovat s nějakou proměnnou délky strávené v prodejně. Tady hodnoty příslušného statistického rozdělení rozhodně seženete lépe. [[User:Tomáš|Tomáš]] ([[User talk:Tomáš|talk]]) 12:43, 14 May 2025 (CET)

== Simulace: Dynamika technického dluhu v softwarovém vývoji ==

=== Popis problému ===
Technický dluh v softwarovém vývoji vzniká, je a taky i bude. Jedním z důvodu vzniku je tlak na rychlost dodání, zvolení suboptimálního řešení nebo zkratky pro usnadnění práce. Tento dluh se hromadí v kódové bázi a systému a chová se podobně jako finanční dluh – s "úroky" v podobě zvýšeného úsilí na budoucí údržbu, opravy chyb ale i implementaci nových funkcí. Akumulovaný dluh tak postupně zpomaluje vývojový tým, snižuje agilitu projektu a zvyšuje celkové dlouhodobé náklady pro celou firmu.

=== Cíl simulace ===
Simulace si dává za úkol namodelovat dynamiku akumulace dluhu a jeho splácení v čase. Jaký ma vliv na produktivitu. Ale hlavně jaké různé strategie řízení dluhu jsou dlouhodobě nejefektivnejší (např. konstatní alokace času na refaktoring vs. reaktivní přístup).

=== Použití simulace ===
* Jako podpora při rozhodování projektových manažerů o prioritách (rychlost vs. kvalita).
* Může pomoci stakeholderům pochopit náklady a přínosy investic do kvality kódu (argumenty pro CIO).
* Pro strategické plánování v IT organizacích týkající se údržby a rozvoje systémů.

=== Použitá metoda a prostředí ===
* Simulace využívá metodu systémové dynamiky (System Dynamics).
* Bude použit program Vensim.

=== Proměnné ===
Definované předem:
* Počáteční úroveň technického dluhu.
* Počáteční rozsah backlogu (nesplněných požadavků).
* Velikost týmu.
* Základní produktivita týmu (bez vlivu dluhu).
* Míra alokace času na refaktoring (strategické rozhodnutí).

Náhodné:
* Tempo příchodu nových požadavků do backlogu.
* Efektivita refaktorovacích snah (malé fluktuace).
* Výskyt neočekávaných problémů vedoucích k tvorbě dluhu (např. kritické chyby).

Popřípadě další.

=== Data ===
* Produkční data budou ťežko získatelné, proto využijeme kombinaci odhadu expertů z praxe a odbornou literaturu.

* GUPTA, Kartik, 2025. Measuring the Impact of Technical Debt on Development Effort in Software Projects. arXiv [online]. [cit. 2025-05-12]. Dostupné z: https://arxiv.org/abs/2502.16277
* YLI-HUUMO, Jesse, Andrey MAGLYAS a Kari SMOLANDER, 2016. How do software development teams manage technical debt? – An empirical study. Dostupné z: doi:https://doi.org/10.1016/j.jss.2016.05.018
* TOM, Edith, Aybüke AURUM a Richard VIDGEN, 2013. An exploration of technical debt. Journal of Systems and Software. 86(6), 1498–1516. Dostupné z: doi:https://doi.org/10.1016/j.jss.2012.12.052
* HOLVITIE, Johannes, Sherlock A. LICORISH, Rodrigo O. SPÍNOLA, Sami HYRYNSALMI, Stephen G. MACDONELL, Thiago S. MENDES, Jim BUCHAN a Ville LEPPÄNEN, 2018. Technical debt and agile software development practices and processes: An industry practitioner survey. Information and Software Technology. 96, 141–160. Dostupné z: doi:https://doi.org/10.1016/j.infsof.2017.11.015

=== Simulant ===
[[User:Hrus07|Hrus07]] ([[User talk:Hrus07|talk]]) 22:19, 12 May 2025 (CET)
:: '''Schváleno''' [[User:Oleg.Svatos|Oleg.Svatos]] ([[User talk:Oleg.Svatos|talk]]) 06:29, 14 May 2025 (CET)

== Simulace: Útoky medvědů ==

=== Popis problému ===
Na Slovensku se vyskytuje velké množství medvědů, kteří ohrožují tamní obyvatele a turisty. Útoky jsou momentálně velmi časté a přibývají. Slovenská vláda schválila návrh na odstřel cca 350 jedinců. Zároveň se jedná o chráněný druh, tudíž počty by neměly být redukovány ve velké míře, ne-li vůbec.

=== Cíl simulace ===
Cílem bude simulovat ideální počet medvědů, aby se minimalizoval počet útoků medvěda a potřeba redukovat počet medvědů.

=== Použití simulace ===
* Např. pro plánování odstřelu medvědů, aby druh nebyl příliš ohrožen.
* Simulace chování medvědů v přírodě.

=== Použitá metoda a prostředí ===
Multiagentní simulace v NetLogo. Agenti budou medvědi, turisti a lovci. V prostředí se populace medvědů bude přirozeně zvyšovat. Turisté mají šanci na útěk. Lovci budou reagovat na incidenty medvědů s turisty.

=== Proměnné ===
Definované předem:
* Medvědi – pohybují se po krajině, hledají potravu a případně útočí na turisty
* Lovci – redukují počty medvědů na základě útoků a ohrožení turistů.
* Turisti – objevují tamní krajinu a lesy. Reagují na přítomnost medvědů.

Náhodné:
* Rozmístění medvědů, lovců a turistů.
* Rozmístění vegetace, lesů.

=== Data ===
* Slovenská vláda schválila odstřel medvědů [https://www.irozhlas.cz/zpravy-svet/nemuzeme-zit-v-zemi-kde-se-lide-boji-chodit-do-lesa-slovenska-vlada-schvalila_2504021255_mst]
* Medvěd hnědý - biotop a teritorium [https://www.selmy.cz/medved/biotop-a-teritorium/]
* Medvěd na Slovensku [https://sita.sk/nasvidiek/kolko-medvedov-zije-na-slovensku-studia-ukazala-cisla-a-najviac-ich-je-na-polane/?utm_source=chatgpt.com]

=== Simulant ===
[[User:Vlcj07|Vlcj07]] ([[User talk:Vlcj07|talk]]) 19:43, 12 May 2025 (CET)

: Dejte si opravdu pozor na zdrojová data a jejic využití. Simulace se dá provést více způsoby, pokud by to bylo příliš zjednodušené, mohlo by se to zvrhnout v banalitu (je to v podstatě varianta Predator-Prey, která byla simulována už nesčetněkrát). Provést to realisticky nebude úplně snadno. '''Schváleno'''. [[User:Tomáš|Tomáš]] ([[User talk:Tomáš|talk]]) 12:48, 14 May 2025 (CET)

== Simulace: Přemnožení divokých prasat ==

=== Popis problému ===
Divoká prasata jsou v České republice přemnožená – na našem území jich je v současnoti 100krát více, než je únosné. Přemnožení je zapříčeněno několika faktory. Prvním je způsob rozmnožování divokých prasat. Bachyně mívají dva vrhy ročně, přičemž v každém vrhu se vyskytuje průměrně 4-12 selat. Při přebytku potravy tak populace divokých prasat prudce roste. Druhý faktor, který zapříčiňuje přemnožení prasat, je absence přirozených predátorů těchto zvířat na našem území. Kontrolu populace pak musejí provádět myslivci, nicméně odtřel je v současné době nedostatečný.

Přemnožená prasata mají negativní dopad na vegetaci svého okolí. Jedná se například o rostlinu bleduli letní, která se v České republice řadí mezi zvláště chráněné druhy rostlin.

=== Cíl simulace ===
Cílem simulace bude simulovat ideální míru odstřelu divokých prasat, aby nedošlo ke zničení vzácné vegetace (jako je například bledule letní). V simulaci bude zobrazena součinnost několika faktorů (růst prasečí populace v závislosti na přítomnosti potravy, množství střelců nutných pro udržení populace na uzdě apod.).

=== Použití simulace ===
Kdo může simulaci použít?
* Myslivci pro informovanější plánování odstřelu prasat.
* Lesní správa, farmářský a zahradnický průmysl apod. – všechna tato odvětví jsou negativně ovlivněná přemnoženou prasečí populací.
* Simulace může problematiku přiblížit i širší veřejnosti, která tak bude lépe schopná seznat její závažnost.

=== Použitá metoda a prostředí ===
Prostředím multiagentní simulace bude NetLogo. Agenti budou divoká prasata, myslivci a vzácná vegetace. Prasata se budou množit rychlostí závislou na množství vegetace. Model bude simulovat různé počty myslivců a různé strategie střelby. Množství vegetace bude závislé na velikosti prasečí populace.

=== Proměnné ===
Definované předem:
* Rychlost množení a „žravost“ divokých prasat.
* Rychlost obnovy vegetace.
* Počet myslivců a strategie a způsob jejich odstřelování prasat.

Náhodné:
* Počáteční populace prasat (v určitém rozmezí).
* Počáteční množství vegetace (opět v určitém rozmezí).
* Rozmístění prasat.
* Rozmístění myslivců.
* Rozmístění vegetace.

=== Data ===
* Prasata devastují vzácnou zeleň. [https://benesovsky.denik.cz/zpravy_region/premnozena-prasata-pustosi-benesovsko-mizi-bledule-i-orchideje-20250318.html]
* Způsob rozmnožování divokých prasat. [https://www.hubeni-skudcu.cz/blog/prase-divoke/]
* Policejní odstřel divokých prasat. [https://www.idnes.cz/liberec/zpravy/odstrel-divocaku-praseci-mor-liberec-jablonec-myslivci-policie.A241212_140610_liberec-zpravy_cink]
* Prase divoké – základní informace. [https://www.kdelovit.cz/cz/lovna-zver/srstnata/prase-divoke]
* Životní cyklus divokých prasat. [https://cit.vfu.cz/pohoda/zivotni_cyklus.pdf]
* Lov divokého prasete. [https://huntasticzech.cz/zvire/prase-divoke/]

=== Simulant ===
[[User:Kalp08|Petr Kalina (kalp08)]] ([[User talk:Kalp08|talk]]) 13:52, 12 May 2025 (CET)

: Jde o variantu klasické úlohy Predator-Prey, která byla řešena už mnohokrát. Chtěl bych, aby to nedopadlo klasicným rámečkem s rozmístěnými prasaty. myslivci a vegetací, takže bych doporučoval ještě rozpracovat detaily. Nicméně '''schváleno'''. [[User:Tomáš|Tomáš]] ([[User talk:Tomáš|talk]]) 12:54, 14 May 2025 (CET)

== Simulace: Šíření dezinformací na sociálních sítích ==

=== Popis problému ===
Simulace modeluje šíření dezinformace mezi uživateli sociální sítě. V dnešním digitálním prostoru jsou informace často sdíleny bez jejich ověřování, což přispívá k rychlému rozšiřování nepravdivých nebo manipulativních zpráv. Sociální sítě jsou hlavním kanálem pro šíření jak pravdivých, tak nepravdivých informací. Model zkoumá, jak rychle a do jaké míry se dezinformace rozšíří napříč sítí uživatelů, kteří jsou mezi sebou propojeni pomocí přátelství nebo sledujících. Ovlivňujícími faktory jsou zejména míra ochoty sdílet, schopnost rozpoznat nepravdivý obsah, struktura sítě (např. počet spojení) a chování jednotlivců. Cílem je porozumět tomu, jaké strategie mohou šíření zpomalit či omezit a jak síťová struktura ovlivňuje zranitelnost vůči dezinformacím.

=== Cíl simulace ===
Cílem simulace je odpovědět na otázku: jak ovlivňuje struktura sociální sítě, chování jednotlivých uživatelů a míra kritického myšlení rychlost a rozsah šíření dezinformací? Simulace umožní identifikovat klíčové parametry, které mohou buď přispět k virálnímu šíření, nebo ho potlačit. Výsledkem může být doporučení k edukaci uživatelů nebo návrh algoritmických opatření pro omezení dosahu problematického obsahu.

=== Použití simulace ===
Simulace má možné využití:
* Jako didaktický nástroj pro výuku mediální a digitální gramotnosti nebo informační bezpečnost
* Pro využití v akademickém výzkumu zabývajícím se šířením obsahu v online prostředí, včetně fake news a konspiračních teorií.

Výsledky mohou posloužit i jako argument pro zavedení preventivních opatření na sociálních platformách.

=== Použitá metoda a prostředí ===
Simulace je vytvořena v prostředí NetLogo. Agenti představují uživatele sociální sítě a jsou propojeni do komunikační struktury (vztahy: „sleduje“, „přátelí se“). Dezinformace se šíří po těchto spojeních. V modelu existují pravidla pro šíření dezinformace a rozhodování agentů. To znamená, že každý agent má určitou pravděpodobnost sdílení, může si informaci ověřit a tím ji zablokovat, nebo ji předat dál.

=== Proměnné ===
'''Definované předem:'''
• počet uživatelů v síti
• typ sociální sítě/síťové struktury (náhodná síť, small-world, scale-free)
• průměrný počet spojení na agenta = síťová hustota
• počet původních šiřitelů dezinformace
• pravděpodobnost sdílení dezinformace (bez ověření)
• pravděpodobnost ověření zprávy a zamezení jejího šíření
'''Náhodné:'''
• rozložení spojení v síti
• výběr původních šiřitelů
• pořadí interakcí mezi agenty (směr šíření, kdo ovlivní koho)
• individuální rozhodnutí každého agenta (na základě pravděpodobností)
• výsledný rozsah šíření (liší se běh od běhu i při stejných nastaveních)

=== Data ===
* Výzkumy behaviorální ekonomie a mediální gramotnosti – např. [https://mediaeducation.ucoz.ru/_ld/0/83_Fedorov-A-2007-.pdf JIRÁK, Jan; WOOLÁK, Radim Woolák Radim. Mediální gramotnost. Praha: Radioservis, 2009.]
* Analýzy šíření fake news – např. Vosoughi, Roy, Aral (2018) – „The spread of true and false news online“, Science 359(6380), 1146–1151. [https://ide.mit.edu/wp-content/uploads/2018/12/2017-IDE-Research-Brief-False-News.pdf „The spread of true and false news online“]
* Odhady pravděpodobností a struktury sítě vycházejí z běžného chování uživatelů na sociálních sítích
* Výzkumné zprávy o algoritmech šíření obsahu na platformách jako Facebook, Instagram, nebo TikTok

=== Simulant ===
[[User:macn04|macn04]] ([[User talk:macn04|talk]]) 14:30, 12 May 2025 (CET)

: Podobná témata se občas objevují, ale většinou narazí na problém, že je nesmírně těžké u tohoto typu problému pracovat s nějakými tvrdými daty. Výsledky by pak zůstaly jen velmi nahodilé. Zkuste popřemýšlet, jestli by byla cesta, jak se tomuto problému vyhnout, alternativně samozřejmě můžete zvážit i jiné téma. [[User:Tomáš|Tomáš]] ([[User talk:Tomáš|talk]]) 08:40, 15 May 2025 (CET)

== Simulace: Evakuace šelem v pražské ZOO v případě povodně ==

=== Popis problému ===
Pražská zoologická zahrada se nachází v záplavovém území a v minulosti byla při povodních (např. v roce 2002 a 2013) vážně zasažena. Evakuace zvířat, zejména velkých a nebezpečných šelem, představuje logisticky i bezpečnostně náročný úkol. Zvířata musí být přepravena v co nejkratším čase, bezpečně a s minimálním stresem, zároveň je nutné chránit zaměstnance a návštěvníky. Simulace se zaměřuje na proces evakuace pavilonu šelem při náhlém zvýšení hladiny Vltavy. Výsledky mohou pomoci vedení ZOO lépe se připravit na mimořádné události.

=== Cíl simulace ===
Simulace se bude věnovat otázce: Jak rychle a efektivně lze evakuovat šelmy z ohroženého pavilonu v případě povodně?
Výsledkem bude návrh optimální evakuační strategie v závislosti na různých faktorech (např. počet ošetřovatelů, kooperace zvířat, čas do zaplavení, atd.). Některá zvířata jsou více nebezpečná jiná jsou klidná.

=== Použití simulace ===
Simulace může sloužit:
*Zaměstnancům ZOO, kteří se chtějí připravit na krizové situace
*Studentům, kteří se učí o ochraně zvířat nebo krizovém řízení
*Veřejnosti, která si chce udělat představu, jak taková situace vypadá a proč je důležitá příprava

=== Použitá metoda a prostředí ===
Multiagentní simulace v NetLogo, kde agenti budou zvířata, zaměstnanci (ošetřovatelé) a povodeň. Zvířata mají různé chování, velikost, agresivitu. Ošetřovatelé jsou zkušení, ale i nováčci a je jich různý počet na směnách. Povodeň může mít různé rychlosti. Prostředím je pavilon šelem v pražské ZOO. V pavilonu jsou jednotlivé expozice podle druhu zvířete. V případě, kdy hrozí evakuace jsou všechna zvířata uvnitř pavilonu.

V případě evakuace přijdou chovatelé a evakuují zvířata. Některá musí uspat, jiná ne. Zvířata přesouvají do klecí nebo boxů a převážejí pryč cestou podle zatopení. U každého zvířete je dohledatelný

=== Proměnné ===
Definované předem:
* Počet zvířat v pavilonu, jejich velikost a druhy
* Počet evakuačních cest
* Rychlost záplav (kolik času je na evakuaci)
* Počet ošetřovatelů a jejich zkušenosti (můžou být zkušení nebo nováčci, nováčci jsou pomalejší a mají vyšší pravděpodobnost minout uspávací šipkou)

Náhodné:
* kooperace zvířete (může být klidné nebo agresivní)
* rozmístění ošetřovatelů
* minutí uspávací šipkou
* rozbitá klec

=== Data ===
* výroční zprávy ZOO Praha [https://www.zoopraha.cz/vse-o-zoo/vyrocni-zpravy]
* mapa ZOO Praha (obrázková) [https://www.zoopraha.cz/navsteva/30-mapa-zoo-praha]
* mapa ZOO Praha [https://g.co/kgs/aXs5ceF]
* přiklad info o zvířeti ZOO Praha [https://www.zoopraha.cz/aktualne/pohledem-reditele/14972-jak-se-v-zoo-praha-chystame-na-povodne]
* převoz tygrů [https://www.jamescargo.com/blog/tiger-transport.php?utm_source=chatgpt.com]
* CITES transport guidelines [https://cites.org/eng/resources/transport/advice.shtml?utm_source=chatgpt.com]

=== Simulant ===
Veronika Smrčková
[[User:smrv03|smrv03]] ([[User talk:smrv03|talk]]) 11:36, 12 May 2025 (CET)

: '''Schváleno.''' [[User:Tomáš|Tomáš]] ([[User talk:Tomáš|talk]]) 08:42, 15 May 2025 (CET)

== Simulace: Strategie hráčů ve hře v kostky dle pravidel hry Farkle ==

=== Popis problému ===
Cílem simulace je analyzovat a porovnat různé herní strategie ve hře Farkle (hazardní kostková hra). Dva hráči si během hry střídavě hází kostkami a snaží se získat co nejvíce bodů pomocí specifických kombinací (např. trojic, postupky, šest stejných hodnot apod.). Hráči však musí v každém tahu rozhodnout, zda pokračovat v házení (s rizikem ztráty aktuálního skóre) nebo se zastavit a body si uložit.

Každý hráč je reprezentován jako „persona“ s předdefinovanou strategií rozhodování – od konzervativního po extrémně rizikového přístupu. Tyto odlišné styly chování významně ovlivňují průběh hry, četnost výher i riziko prohry kvůli přehnané hamižnosti.

=== Cíl simulace ===
Cílem simulace je zjistit, jaké herní strategie (persony) jsou nejefektivnější v dosažení výhry ve hře Farkle. Zároveň zohledňuje spravedlnost (oba hráči mají stejný počet tahů) a umožňuje porovnávat strategie mezi sebou při opakovaném hraní stovek her. Výstupem je srovnání úspěšnosti jednotlivých přístupů a doporučení vhodné herní taktiky.

=== Použití simulace ===
Simulace může sloužit:
* jako model rozhodování v nejistém prostředí,
* jako prostředek pro výuku agentového modelování (např. střední školy, informatika, psychologie rozhodování),
* pro zábavné testování, která strategie by přinesla nejvíc výher v reálné hře Farkle,
* jako výchozí kostra pro složitější modely s učením, adaptivními hráči nebo evoluční optimalizací strategie,
* a v neposlední řadě, jako "engine" na testování person pro mou diplomovou práci.

=== Použitá metoda a prostředí ===
Simulace je implementována v prostředí NetLogo jako dvouagentní tahový model. Hráči se střídají v házení 6 kostek, získávají body za kombinace podle pravidel Farkle (např. trojice, čtveřice, pětice, šestice, postupky) a rozhodují se, zda budou pokračovat v tahu.

Model zahrnuje:
* různé herní strategie („persony“) – definované jako rozhodovací pravidla podle skóre, zbývajících kostek nebo náhodného faktoru,
* počítání statistik (výhry, tahy, FARKLE chyby),
* zajištění férovosti – druhý hráč má vždy možnost dokončit poslední tah, pokud první dosáhne vítězného skóre,
* export výsledků a vykreslení průběhu skóre do grafu (a jiné statistické ukazetele).

=== Proměnné ===
Definované předem:
* Cílové skóre pro výhru (např. 10 000)
* Počet simulovaných her (např. 100 až 1000)
* Herní strategie pro oba hráče:
* conservative – ukládá body při ≥400
* risky – ukládá body při ≥700
* greedy – ukládá body při ≥1000
* cautious – hraje opatrně (≥300 nebo málo kostek)
* random – rozhoduje se náhodně
* risk-averse – hraje opatrně jen pokud vede o >2000 bodů, jinak jako conservative
* point-maximizer – pokračuje, dokud nedostane HOT DICE
* combo-hunter – pokračuje po silných kombinacích (postupky, trojice a víc)

Náhodné:
* Hod šesti kostkami (1–6)
* Kombinace, které hráči získají (např. 3 stejné, postupka 1–6 atd.)
* Výsledek rozhodnutí pokračovat/zastavit u náhodné strategie

Možná rozšíření simulace:
* Evoluční vývoj nových strategií (např. pomocí genetického algoritmu)
* Paměť hráčů – učení na základě předchozích neúspěchů
* Reakce na strategii soupeře (adaptivní persona)

=== Data ===
* [https://farkle.games/official-rules/] - oficiální pravidla hry Farkle
* [http://incompleteideas.net/book/the-book-2nd.html] - popis chování osob v pod tlakem a při riskování (persony)
* [https://mud.co.uk/richard/hcds.htm] - rozdělení person a chování v různých karetních a jiných hrách
* [http://incompleteideas.net/book/the-book-2nd.html] - o strategiích rozhodování, výběru akcí, riziku a odměnách

=== Simulant ===
Jan Hlavnička
[[User:hlaj13|hlaj13]] ([[User talk:hlaj13|talk]]) 13:58, 8 May 2025 (CET)

: Moc nadšený z toho tématu nejsem. Většinou tahle hazardní témata zamítáme hlavně z důvodu, že ten výsledek je obvykle bývá poměrně snadno analyticky převídatelný. Tady aspoň pracujete s porovnáváním těch strategií, budiž. Dejte prosím pozor, ať nedojdete ke zcela banálním výsledkům. '''Schváleno'''. [[User:Tomáš|Tomáš]] ([[User talk:Tomáš|talk]]) 08:52, 15 May 2025 (CET)

== Simulace: Simulace tučňáků hledajících lásku na ledové kře 🐧❤️ ==

=== Popis problému ===
Cílem simulace je modelovat chování tučňáků během námluv na ledové kře. Tučňáci musí najít vhodného partnera pro hnízdění, přičemž čelí různým vnějším vlivům – nestabilnímu prostředí (praskající led), konkurenci ostatních tučňáků a hrozbě predátorů (např. lachtani).

Každý tučňák má specifické nastavení chování – někteří jsou spíše plachého typu, jiní jsou odvážní a aktivně oslovují potenciální partnery. Odlišný přístup k seznamování ovlivňuje jejich šanci na úspěšné spárování a přežití do hnízdní sezóny.

=== Cíl simulace ===
Simulace se zaměří na otázku: Jaký „balící styl“ (strategie chování) vede k nejvyšší šanci na nalezení partnera a založení hnízda, a jak tuto šanci ovlivňuje prostředí a přítomnost rizik? Výsledkem bude doporučení nejefektivnějších „láskových taktik“ v závislosti na kontextu (bezpečné vs. nebezpečné prostředí).

=== Použití simulace ===
Simulace může sloužit:
* jako model sociální interakce v zábavné formě,
* jako edukativní nástroj pro představení agentového modelování (např. na středních školách),
* nebo jako metaforické přiblížení seznamovacích strategií ve složitém prostředí.

=== Použitá metoda a prostředí ===
Simulace bude vytvořena v prostředí NetLogo jako multiagentní model, kde každý agent (tučňák) bude reprezentovat jiný typ chování. Prostředí bude ledová kra se zónami různé stability a výskytu predátorů.

Tučňáci budou interagovat podle jednoduchých pravidel: přiblíží se k partnerovi, pokusí se o námluvy (s pravděpodobností úspěchu ovlivněnou vlastnostmi obou), a pak spolu odcházejí hnízdit (zmizí ze scény). Mohou být také ohroženi prasknutím kry nebo útokem predátora.

=== Proměnné ===
Definované předem:
* Počet tučňáků (např. 50–100)
* Stabilita ledu (pravděpodobnost prasknutí při stání na místě)
* Výskyt predátorů (pravděpodobnost útoku při pohybu)
* Rychlost pohybu a reakce

Typ chování:
* Plachý – čeká, až ho někdo osloví
* Odvážný – aktivně balí ostatní
* Kombinovaný – střídá strategie

Náhodné:
* Rozmístění tučňáků
* Výběr preferovaného partnera (náhodně nebo podle vlastností)
* Výsledek námluv (pravděpodobnost úspěchu podle kompatibility + typu chování)
* Prasknutí ledové kry
* Útok predátora

Možná rozšíření simulace:
* Přidání „charakterových“ rysů (krása peří, zpěv, taneční dovednosti)
* Učení – tučňák se poučí z neúspěchu a změní taktiku
* Sezónnost – časový limit na nalezení partnera (jinak simulace končí smutným singl koncem)

=== Data ===
* [https://www.reuters.com/business/environment/emperor-penguins-suffered-mass-breeding-failures-2023-amid-record-low-sea-ice-2024-04-25/ Stabilita mořského ledu a úspěšnost hnízdění
* [https://www.birdsnz.org.nz/wp-content/uploads/2021/12/Rowe_67_etal_451_459.pdf Úspěšnost hnízdění u tučňáků malých
* [https://www.selwomarina.es/en/blog/por-que-pinguinos-regalan-piedras-hembra?utm_.com Selwo Marina Benalmadena] – Článek věnující se námluvám a párování, kde popisují darování kamínků jako součást námluv
* BBC Earth, National Geographic, Attenboroughovy dokumenty – často dobře vysvětlují typy chování, interakce a přežívání. Např. March of the Penguins

=== Simulant ===
Zuzana Plachá
[[User:plaz03|plaz03]] ([[User talk:plaz03|talk]]) 20:20, 7 May 2025 (CET)

: OK, nezapomeňte chování jednotlivých druhů tučńáků, atd. podložit nějakými zdroji. Pozor také na relativně nízké počty. 50 výskytů nějakého jevu je skoro na hranici fungování statistiky. '''Schváleno'''. [[User:Tomáš|Tomáš]] ([[User talk:Tomáš|talk]]) 08:54, 15 May 2025 (CET)

== Simulace: Simulace vojenské patroly a střetu s nepřítelem ==

=== Popis problému ===
Simulace se zabývá chováním malé vojenské jednotky (patroly), která operuje v nepřátelském teritoriu. Cílem patroly je bezpečný průchod zadanou trasou. V oblasti se ovšem mohou nacházet nepřátelské síly, které mají za úkol patrolu odhalit a zlikvidovat. Průběh mise ovlivňuje několik proměnných – velikost jednotky, dosah vidění, typ terénu, schopnost včasné reakce a počet a rozmístění nepřátel. Výsledky simulace umožní analyzovat účinnost různých taktik a rozhodovacích pravidel, které jednotka může použít při plnění mise. Zároveň mohou sloužit jako podpůrný nástroj při plánování operací nebo jako tréninková pomůcka pro rozhodování armády v rizikových situacích.

=== Cíl simulace ===
Simulace se bude věnovat zodpovězení otázky: jak různé faktory (velikost jednotky, rozmístění nepřátel, strategie pohybu) ovlivňují úspěšnost vojenské patroly při průchodu nebezpečným územím? Cílem je nalézt parametry a strategie, které vedou k nejvyšší pravděpodobnosti úspěšného dokončení mise bez ztrát. Výsledkem bude doporučení efektivních taktických rozhodnutí pro minimalizaci rizika při podobných operacích.

=== Použití simulace ===
Simulaci by mohli využít velitelé malých jednotek nebo vojenská akademie pro testování taktik v simulovaných prostředích. Model by jim dokázal vyhodnotit, jak různé strategie a složení jednotky ovlivňují šanci na úspěšné dokončení mise bez ztrát.

=== Použitá metoda a prostředí ===
Multiagentní simulace v NetLogo. Agenti v modelu budou reprezentovat členy vojenské patroly a nepřátelské jednotky. Prostředí bude představovat mapu oblasti s různými typy terénu - otevřený terén, les, kryt apod.

=== Proměnné ===
Definované předem:
* Počet vojáků v patrole
* Počet nepřátel
* Typ terénu (např. podíl lesů, volného prostoru)
* Trasa patroly (předem definovaná nebo generovaná)
* Dosah vidění vojáků i nepřátel
* Pravidla reakce na kontakt (útěk, útok, přivolání podpory)
Pravděpodobnosti střetu a úspěchu jsou založeny na odhadech inspirovaných vojenskými taktickými příručkami a popisech reálných situací v článcích A-Report.

Náhodné:
* Rozmístění nepřátel v terénu
* Zpozorování nepřítele (pravděpodobnost, že jednotka zahlédne protivníka)
* Výsledek střetu (založen na pravděpodobnosti úspěchu v boji)
* Chování nepřítele (např. zda se ukryje nebo přepadne)

=== Data ===
* [https://mocr.mo.gov.cz/assets/informacni-servis/povinne-informace/1-uredni-deska/zakon-106/odp/priloha-c--1-1_25.pdf Základní řád ozbrojených sil České republiky] – řád armády ČR
* [https://mocr.mo.gov.cz/assets/multimedia-a-knihovna/casopisy/a-report/ar9_2018.pdf Časopis A-Report Útoku se nedalo zabránit] – Úryvek ze článku věnovaný osudové chybě v boji na Balkáně
* [https://mocr.mo.gov.cz/assets/multimedia-a-knihovna/casopisy/a-report/ar10_2019.pdf Časopis A-Report Pod ostrou palbou] – Úryvek ze článku popisující možnost simulací ve vojenském prostředí
* Vlastní odhady založené na realistických parametrech (např. efektivní dostřel, rychlost pohybu v terénu)

=== Simulant ===
Alexandr Sekera
[[User:seka01|seka01]] ([[User talk:seka01|talk]]) 15:33, 7 May 2025 (CET)

: OK, může být. Dejte si pozor na dobré odzdrojování dat, se kterými pracujete. '''Schváleno'''. [[User:Tomáš|Tomáš]] ([[User talk:Tomáš|talk]]) 08:57, 15 May 2025 (CET)

== Simulace: Kontrola jízdenek v MHD ==
=== Popis problému ===
Simulace se zabývá procesem kontrol jízdenek ve veřejné dopravě (např. v systému MHD v Praze). Veřejná doprava je financována částečně z příjmů z jízdného. Cestování "načerno" představuje pro dopravní podnik zdroj ztrát. Proto revizoři od podniku provádějí kontroly platnosti jízdních dokladů. Z toho vyplývá otázka, jak často a jakým způsobem mají být dané kontroly prováděny, aby byly efektivní a ekonomicky dávaly smysl. Výsledky simulace umožní řízení MHD optimalizovat frekvenci kontrol, počet revizorů a tím zvýšit celkovou efektivitu inspekcí.

=== Cíl simulace ===
Simulace se bude věnovat zodpovězení otázky: jak ovlivňuje četnost kontrol objem vybraných pokut ve veřejné dopravě? Výsledkem bude doporučení efektivních inspekčních strategií pro maximalizaci vybraných pokut. Simulace také ukáže, kolik revizorů je potřeba pro dosažení požadované míry kontroly.

=== Použitá metoda a prostředí ===
Multiagentní simulace v Netlogo. Agenti v modelu budou reprezentovat pasažéry a revizory.

=== Proměnné ===
Definované předem:
* Počet cestujících (celkově)
* Počet revizorů
* Výše pokuty (standardní nebo menší za platbu okamžitě)
* Frekvence kontrol (počet provedených kontrol za minutu/hodinu)
* Kapacita vozidla (počet cestujících z celkového čísla, kteří jsou aktuálně v kontrolovaném prostoru)

Náhodné:
* Platnost jízdenky (zda jede pasažér "načerno")
* Zachycení černého pasažéra (zda je neplatnost jízdenky odhalena)
* Zaplacení pokuty (hned či později)

=== Data ===
[https://www.dpp.cz/jizdne/pokuty-revizori/vyse-prirazky DPP - pokuty a revizoři] - výše jednotlivých pokut

[https://www.dpp.cz/vozovy-park DPP - vozový park] - kapacity vozidel

[https://www.expats.cz/czech-news/article/prague-public-transport-inspectors-handed-out-250-000-fines-last-year Prague public transport inspectors handed out 250,000 fines last year] - počty kontrol, pasažérů a revizorů, celková výše pokut, zaplacení pokut

Míra cestování "načerno" pro Prahu není zveřejněna oficiálně. Pro odhad poměru černých pasažérů se lze inspirovat jinými státy ([https://theweek.com/transport/fare-dodging-londons-transport-blight UK], [https://www.trainsfare.eu/tackling-fare-evasion-in-bergamo-a-growing-challenge-for-atb-and-teb/ IT]).

=== Simulant ===
Vladislav Sanin
[[User:Sanv05|Sanv05]] ([[User talk:Sanv05|talk]]) 21:15, 6 May 2025 (CET)

: Není mi úplně jasné, jak to chcete modelovat? Půjde o pasažery přímo ve vozech? Nebo budete mít nějaký model nějaké stanice s rozmístěním revizorů nebo celé sítě MHD? Zkuste to prosím upřesnit, klidně doplňte obrázek. Taková úloha se totiž dá vypracovat řadou způsobů. Některé by byly vyloženě banální, jiné by mohly být zajímavé. [[User:Tomáš|Tomáš]] ([[User talk:Tomáš|talk]]) 09:01, 15 May 2025 (CET)

:: '''RE: UPŘESNĚNÍ'''. Představuju si to tak, že to bude jeden vůz (vyznačený prostor), kam nastoupí noví pasažéři, část ze kterých jede bez jízdenky. Během jízdy mezi zastávkami (tedy dokud nemohou vystoupit) mohou být kontrolovány revizorem, kontrola taky zabere nějaký čas. Na konci jedné jízdy (po uplynutí fixního počtů ticků, které budou reflektovat délku jízdy - tak, aby to souviselo s počtem proveditelných kontrol, tyto informace lze odvodit ze stránek PID) pasažéři vystoupí a noví nastoupí. [[User:Sanv05|Sanv05]] ([[User talk:Sanv05|talk]]) 20:39, 15 May 2025 (CET)

== Simulace: Pavlovovo podmiňování v agentním modelu ==
=== Co budu simulovat ===
Simulace bude modelovat proces klasického (Pavlovova) podmiňování, kdy agent (představující psa) postupně spojuje neutrální podnět (zvonek) s přirozeným podnětem (jídlo). Výsledkem je, že agent začne reagovat podmíněnou reakcí (slinění) i v případě, že se později objeví pouze zvonek bez jídla.

=== Cíl simulace ===
Cílem simulace je analyzovat průběh učení podmíněné reakce a zjistit:
* kolik opakování je potřeba k vytvoření podmíněné reakce,
* jak stabilní tato reakce je v čase,
* jak rychle dochází k vyhasnutí reakce (extinkci) při absenci posílení,
* jak efektivní je opětovné učení (re-learning) po ztrátě reakce.

Obecně jde o pochopení mechanismů formování návyků a chování založeného na stimulaci a posilování.

=== Kdo by takovou simulaci mohl využít a jak by mu pomohla ===
Simulaci mohou využít například:
* psychologové zabývající se behaviorálním učením,
* učitelé při výuce základních principů behaviorismu,
* vývojáři agentních a AI modelů, kteří chtějí simulovat jednoduché učení nebo formování návyků.

Simulace jim umožní vizuálně a experimentálně sledovat proces klasického podmiňování a analyzovat vliv různých parametrů na průběh učení.

=== Použitá metoda a prostředí ===
* '''Metoda''': Agentní simulace využívající jednoduchý model chování se stavovým automatem. Agent mění svůj vnitřní stav v závislosti na podnětech a historii posilování.
* '''Prostředí''': NetLogo

=== Jaké proměnné budou v simulaci ===
* Počet pokusů o podmiňování
* Zpoždění mezi zvonkem a jídlem (časování podnětů)
* Frekvence posilování (např. 100 %, 75 %, 50 % případů s jídlem)
* Síla podmíněné reakce (vnitřní proměnná zvyšující se učením)
* Počet extinkčních pokusů (zvonek bez jídla)

=== Jaké proměnné budou náhodné ===
* Pravděpodobnost, zda po zvonku následuje jídlo (při částečném posilování)
* Malá náhodná odchylka v chování psa (např. reakční doba, úroveň slinění)

=== Na jakých datech budou proměnné založené ===
* Parametry vycházejí z publikovaných výsledků klasických experimentů Pavlova a dalších behaviorálních studií.
* Typické hodnoty časování a pravděpodobností pro různé typy posilování vychází z odborné literatury.
* Síla reakce bude modelována pomocí logistické funkce, která simuluje typickou křivku učení a vyhasínání reakce.
* [https://www.psychologywizard.net/uploads/2/6/6/4/26640833/pavlov_lecture_18.pdf Pavlov – Lecture 18 (Conditioned Reflexes, 1927)]
* [https://en.wikipedia.org/wiki/Classical_conditioning Wikipedia – Classical Conditioning]
* [https://www.simplypsychology.org/pavlov.html Simply Psychology – Pavlov’s Dogs]

=== Na jakých datech jsou založeny vzorce v simulaci (chování modelu) ===
Chování modelu bude založeno na Rescorla-Wagnerově modelu klasického podmiňování, který kvantifikuje změnu síly asociace mezi podmíněným podnětem a nepodmíněným podnětem během jednotlivých pokusů.
* [https://www.vcalc.com/wiki/rescorla-wagner-formula-alpha-and-beta-version vCalc – Rescorla-Wagner model (alpha and beta version)]
* [https://en.wikipedia.org/wiki/Rescorla%E2%80%93Wagner_model Wikipedia – Rescorla–Wagner model]

=== Simulant ===
[[User:Lans06|Lans06]] ([[User talk:Lans06|talk]]) 22:27, 6 May 2025 (CET)

: Myšlenka se mi líbí, ale úplně si na základě toho zadání nedovedu představit tu realizaci. To bude jako jeden agent nebo budete simulovat něco jako neurony toho psa? Zkuste to prosím rozvést, případně doplnit obrázek. [[User:Tomáš|Tomáš]] ([[User talk:Tomáš|talk]]) 09:26, 16 May 2025 (CET)

== Simulace: Bitva u Azincourtu v roce 1415 (Anglie vs Francie během Stoleté války) ==

=== Popis problému ===
V roce 1415 stála Anglie v čele se svým králem Jindřichem V. proti silám Francie, které měly velmi drtivou převahu (Anglie cca 8500 a Francie cca 15 000). I přes tuto nevýhodu dokázala Anglie vyhrát s nepatrnými ztrátami. Dle historických pramenů to bylo především díky strategickému umístění anglického vojska v úzkém prostoru mezi stromy, kde nemohly francouzské jednotky přímo naběhnout a využít drtivou sílu svých počtů bojovníků - musely postavit více řad bojovníků za sebou a nemohly anglické jednotky obklopit.

=== Cíl simulace ===
Simulace se bude věnovat otázce: Měla by Francie šanci vyhrát bitvu, kdyby se bitva odehrávala na širokém prostranství narozdíl od úzkého prostoru? Nebo by stále Anglie dokázala vyhrát, kdyby přišla o výhodu okolí?

=== Použití simulace ===
Simulace může sloužit:
* historikům - náhled do historie, kdyby měla bitva jiný průběh
* Úvaha nad historickou událostí, která ovlivnila Stoletou válku

=== Cíl simulace ===
* dokázat, jak terén může ovlivnit průběh bitvy, pokud je stanovena správná strategie
* změní se průběh bitvy a dokáže Francie vyhrát?
* jak moc účinné je zbraň Long Bow (dlouhý luk) v otevřeném terénu?

=== Použitá metoda a prostředí ===
Multiagentní simulace v NetLogo, kde agenti budou jednotky Anglie (pěšáci, střelci s Long Bow) a Francie (pěšáci, kavalérie, střelci s Long Bow, střelci s kuší).

=== Proměnné v simulaci ===
Definované předem:
* počet a rozložení jednotek anglické armády
* počet a rozložení jednotek francouzské armády

Náhodné
* pohyb jednotek (každá jednotka má své reakce a možnosti pohybu)
* střelba z Long Bow - kolik zvládne vystřelit šípů za určitý čas

=== Data ===
* https://www.stoplusjednicka.cz/bitva-u-azincourtu-stret-ktery-rozhodl-nekonecnou-valku-mezi-anglii-francii
* https://zoom.iprima.cz/historie/bitva-u-azincourtu
* vlastní poznatky z rekonstrukcí bitev

=== Simulant ===
[[User:Bilk08|Bilk08]] ([[User talk:Bilk08|talk]]) 12:00, 12 May 2025 (CET)

: '''Schváleno'''. [[User:Tomáš|Tomáš]] ([[User talk:Tomáš|talk]]) 09:27, 16 May 2025 (CET)

== Simulace: Phishing na hybridním pracovišti ==

=== Popis problému ===
Práce bude zkoumat roli hybridního (onsite & remote) pracoviště na pravděpodobnsot úspěšného phishing útoku.
Remote zaměstnanci méně komunikují, než jejich onsite kolegové, což snižuje pravděpodobnost, že o podezřelém emailu někomu řeknou nebo u stolu jen prohlásí "to je divný" nebo "taky jsi dostal tenhle trenink do zitra?".
Simulace bude uvažovat, že ne každý zaměstnanec má přístup ke kritickým systémům, jen někteří mohou způsobit firmě vážné škody, ale pokud se tak stane, následky jsou velké.

=== Cíl simulace ===
Simulace má za cíl zjistit, jaké budou škody s různými konfiguracemi onsite vs. remote zaměstnanců.

=== Kdo by takovou simulaci mohl využít a jak by mu pomohla ===
Jakákoli korporát/firma s kombinací onsite a remote zaměstnanců (populární po pandemii)

=== Použitá metoda a prostředí ===
*Metoda: Multi-agentní simulace
*Prostředí: NetLogo

=== Jaké proměnné budou v simulaci ===
*Deterministické:
**Socializace (např. oběd)
**Délka sprintu (ke konci sprintu klesá pozornost, roste zbrklost)
**Počet zaměstnanců s kritickými přístupy
**Počet onsite zaměstnanců
**Počet remote zamšstnanců
**Intervaly mezi interními phishing testy IT oddělení

*Náhodné:
**Četnost phishing útoků
**Základní pravděpodobnost naletění na phishing
**Pravděpodobnost naletění po školení (efekt se bude s časem od školení snižovat)
**Pravděpodobnost naletění po úspěšném útoku
**Remote & onsite pravděpodobnost komunikace (při odhalení phishingu)
**Ztráta způsobená úspěšným phishingovým útokem bez kritických přístupů
**Ztráta způsobená úspěšným phishingovým útokem s kritickými přístupy

=== Data ===
*Vědecké články (např. psychologické studie na efekt o interních phishing testech, jak zvyšuje pracovní nápor pravděpodobnost naletění)
*Phishingové statistiky (např. četnost, úspěšnost, severita)

=== Simulant ===
[[User:Lebm05|Lebm05]] ([[User talk:Lebm05|talk]]) 12:59, 12 May 2025 (CET)

: Nápad zajímavý, ale připadá mi to velmi vágní, spousta "měkkých" faktorů. Buďto to zkuste rozpracovat do detailu, aby bylo lépe vidět, jakou cestou byste se vydal nebo zvažte jiné téma. [[User:Tomáš|Tomáš]] ([[User talk:Tomáš|talk]]) 09:32, 16 May 2025 (CET)

== Simulace: Obsazenost akutních lůžek v českých nemocnicích ==

=== Popis problému ===
České nemocnice disponují v průměru 4,6 akutními lůžky na 1 000 obyvatel. Při průměrné ošetřovací době, která teď činí 5,5 dne, dochází k fluktuacím mezi novými přijetími pacientů, obsazeným počtem lůžek a propouštěním pacientů. Při obsazenosti vyšší než 85 %, kvalita péče klesá, prodlužují se čekací doby a zvyšuje se riziko komplikací a nozokomiálních infekcí.

Simulace bude odhadovat vývoj obsazenosti akutních lůžek v čase a vyhodnotí dopad různých intervencí (zkrácení průměrné ošetřovací doby, navýšení kapacity, řízení fronty).

Výsledky simulace ukážou, která opatření nejvíce snižují riziko dlouhodobé obsazenosti nad 85 %, kdy už dochází k prodlužování čekacích dob a nárůstu infekcí; také mohou sloužit jako podpora rozhodování o investicích a rozdělení rozpočtu.

=== Cíl simulace ===
Cílem simulace je zodpovědět na otázku, do jaké míry a jak rychle udržení obsazenosti pod 85 % ovlivní faktory jako:
* Snížení průměrné ošetřovací doby o 10 %
* Navýšení kapacity o 10 %
* Řízená fronta (prioritizace)
Ve všech scénářích budu sledovat průměrnou denní obsazenost lůžek, maximální délku fronty, a čas, za který obsazenost překročí nebo zůstane pod hranicí 85 %.

=== Použití simulace ===
Kdo může simulaci použít?
Simulace umožní vedení zdravotnických zařízení a manažérům identifikovat dlouhodobé rizikové body v lůžkové kapacitě a následně je mohou využít k optimalizaci strategických investic tak, aby udrželi kontinuitu péče a finanční udržitelnost i při demografických změnách či neočekávaných vlnách poptávky. Díky simulaci mohou předem ověřit dopad různých politik (např. zkrácení průměrné ošetřovací doby, rozšíření kapacity, prioritizace příjmu) a na základě toho nastavit robustní krizové plány a alokaci zdrojů.

=== Použitá metoda a prostředí ===
Pro tvorbu simulace využit přístup Systémové dynamiky a nástroj Vensim PLE.

=== Proměnné ===
* Počet obyvatel
* Počet hospitalizovaných pacientů (akutní lůžka)
* Počet nově hospitalizovaných pacientů
* Počet propuštěných pacientů
* Průměrná délka hospitalizace
* Míra propuštění
* Průměrné denní množství nových žádostí o hospitalizaci
* Míra hospitalizace
* Celkový počet akutních lůžek
* Míra navýšení kapacity při obsazenosti větší než 85 %
* Počet volných lůžek
* Obsazenost lůžek

=== Data ===
* Počet obyvatel v ČR. [https://vdb.czso.cz/vdbvo2/faces/cs/index.jsf?page=vystup-objekt&pvo=DEM13&z=T&f=TABULKA&skupId=3829&katalog=33155&pvo=DEM13&evo=v141_!_IK-CR-K_1&c=v3~8__RP2021]
* Zdravotní péče České republiky. [https://csu.gov.cz/zdravotni-pece#:~:text=2016%202017%202018%202019%202020,548%209%20960%209%20996]
* Zdravotnická ročenka České republiky. [https://www.uzis.cz/index.php?pg=aktuality&aid=8560]
* Hospitalizace v nemocnicích ČR. [https://www.uzis.cz/index.php?pg=vystupy--vyznamna-temata--hospitalizace ]
* Pohyb obyvatelstva - rok 2021. [https://csu.gov.cz/rychle-informace/pohyb-obyvatelstva-rok-2021#:~:text=Podle%20výsledků%20sčítání%20lidu%2C%20domů,Štyglerová%2C%20vedoucí%20oddělení%20demografické%20statistiky]

=== Simulant ===
[[User:Kozo01|Olesia Kozlova (kozo01)]] ([[User talk:kozo01|talk]]) 16:07, 12 May 2025 (CET)

:: '''Schváleno'''[[User:Oleg.Svatos|Oleg.Svatos]] ([[User talk:Oleg.Svatos|talk]]) 20:45, 12 May 2025 (CET)

== Simulace: Eutrofizace vodní plochy ==

=== Popis problému ===
Eutrofizace vodních ploch je přírodní jev, který může být výrazně ovlivněn antropogenní činností. Jedná se zejména o jednotlivé chemické pochody, které způsobují nárůst biomasy na hladině vodní plochy. Díky tomuto růstu dochází k postupnému snižování světelných podmínek pod úrovní hladiny, což způsobuje úhyn biomasy a dochází k zvýšení rozkladných procesů, které zapříčiňují úbytek kyslíku v celé vodní nádrži. Následkem toho dochází i k úhynu vodních živočichů závislých na koncentraci kyslíku pod hladinou.

=== Cíl simulace ===
Cílem simulace je namodelovat celý proces eutrofizace, který bude ovlivněn antropogenní činností (např. splachy z polí). Zodpoví jednu z důležitých otázek: Jak antropogenní činnost urychluje eutrofizaci.

=== Použití simulace ===
* Simulace může být využita k akademickému studiu eutrofizace,
* jako podpora při legislativních rozhodnutí,
* může vylepšit strategické plánování ve vodohospodářských organizacích, nebo
* strategické plánování zemědělců.

=== Použitá metoda a prostředí ===
* Simulace využívá program Vensim, který byl vybrán na základě jeho schopnosti namodelovat toky a vazby mezi jednotlivými proměnnými ve sledovaném prostředí.

=== Proměnné ===
* Definované předem:
** úroveň eutrofizace,
** počáteční množství biomasy,
** počáteční množství živočichů,
** počáteční pH vody,
** počáteční obsah kyslíku.

* Náhodné:
** počasí,
** zalévání zemědělských ploch.

Popřípadě další.

=== Data ===
* YANG, Xiao-e, Xiang WU, Hu-lin HAO a Zhen-li HE, 2008. Mechanisms and assessment of water eutrophication. Journal of Zhejiang University. Science. B [online]. 9(3), 197–209. ISSN 1673-1581. Dostupné z: doi:[https://doi.org/10.1631/jzus.B0710626 10.1631/jzus.B0710626]

=== Simulant ===
[[User:bene08|Eliška Benešová (bene08)]] ([[User talk:bene08|talk]]) 16:07, 12 May 2025 (CET)

:: '''Schváleno''' [[User:Oleg.Svatos|Oleg.Svatos]] ([[User talk:Oleg.Svatos|talk]]) 20:50, 12 May 2025 (CET)

== Simulace: Simulace průchodu cestujících pasovou kontrolou na letišti ==

=== Popis problému ===
Letiště v době dopravní špičky čelí problémům s kapacitou pasové kontroly. Nedostatečný počet otevřených přepážek vede k dlouhým frontám a nespokojenosti cestujících. Naopak příliš mnoho otevřených přepážek může znamenat neefektivní využití personálu. Proto je potřeba najít rovnováhu mezi těmito dvěma faktory.

=== Cíl simulace ===
Cílem simulace je analyzovat vliv počtu otevřených přepážek na délku fronty a maximální čekací dobu cestujících. Jedním z hlavních cílů je identifikovat maximální čekací dobu v případech, kdy nejsou otevřeny všechny dostupné přepážky, a navrhnout optimální počet přepážek pro různé scénáře zatížení.

=== Použití simulace ===
Simulaci může využít letištní management, konkrétně vedoucí směny nebo plánovači personálu, kteří rozhodují o počtu aktivních pracovníků v jednotlivých časových intervalech. Pomůže jim lépe plánovat směny a optimalizovat provoz pasové kontroly tak, aby se předešlo zbytečným zpožděním i plýtvání lidskými zdroji.

=== Použitá metoda a prostředí ===
Použiji agentní simulaci v jazyce Rust, s využitím open-source herního enginu Bevy (verze 0.13) jako vizuálního a simulačního prostředí. Každý cestující bude modelován jako agent, který dorazí, čeká ve frontě, a je odbaven u přepážky podle pravidel fronty (FIFO). Přepážky budou reprezentovány jako paralelní servery.

=== Proměnné ===

Deterministické proměnné:

*Počet otevřených přepážek
*Reálný rozvrh příletů letadel
*Počet cestujících vystupujících z každého příletu (interval 5 minut)

Náhodné proměnné:

*Interval mezi příchody cestujících (exponenciální rozdělení)
*Doba odbavení u přepážky (normální rozdělení)
*Rychlost přechodu cestujících od gate k pasové kontrole

Měřené výstupy:

*Průměrná čekací doba
*Maximální čekací doba
*Využití jednotlivých přepážek v %
*Délka fronty v čase

=== Data ===

Průměrná doba odbavení: Na základě interních dat z provozu pasové kontroly letiště.

Intenzita příchozích cestujících: Data získáná z každodenního leteckého provozu mimo sezónu a v sezóně (červen - září)

=== Simulant ===
[[User:Papd01|Papd01]] ([[User talk:Papd01|talk]]) 17:25, 12 May 2025 (CET)

: OK, na tohle by byl ideální Simprocess, který už bohužel není k dispozici. Simulace jako taková je poměrně triviální, určitě doložte zdroje dat. '''Schváleno'''. [[User:Tomáš|Tomáš]] ([[User talk:Tomáš|talk]]) 09:36, 16 May 2025 (CET)

== Simulace: Autobusová linka v městské dopravě ==

=== Popis problému ===
Simulace se zabývá provozem autobusové linky v městské dopravě. Veřejná doprava je klíčová pro fungování měst a efektivní provoz autobusových linek zajišťuje dostupnost a komfort pro cestující. V praxi dochází k problémům, jako je přetížení spojů během špičky, zpoždění, dlouhé čekací doby na zastávkách nebo nevyužité kapacity mimo špičku. Simulace umožní analyzovat, jak různé faktory (například počet autobusů, intervaly mezi spoji, kapacita vozidel nebo rozložení cestujících během dne) ovlivňují kvalitu přepravy a vytížení linky. Výsledky simulace mohou pomoci dopravcům optimalizovat jízdní řády a nasazení vozidel.

=== Cíl simulace ===
Cílem simulace je zjistit, jak různé parametry provozu autobusové linky ovlivňují:
* průměrnou dobu čekání cestujících na zastávce,
* naplněnost autobusů v různých částech trasy a v různých časech,
* identifikaci kritických zastávek s přetížením,
* doporučení pro optimalizaci jízdního řádu a kapacity linky.

=== Použitá metoda a prostředí ===
Multiagentní simulace v NetLogo. Agenty v modelu budou reprezentovat autobusy, cestující a zastávky.

=== Proměnné ===
Definované předem:
* Počet autobusů na lince
* Kapacita jednoho autobusu
* Počet zastávek a jejich rozložení na trase
* Interval mezi odjezdy autobusů
* Délka trasy a čas potřebný k projetí celé linky

Náhodné:
* Počet cestujících přicházejících na jednotlivé zastávky v čase (modeluje špičku/mimo špičku)
* Cílová zastávka každého cestujícího (kde vystupuje)
* Doba nástupu a výstupu cestujících

=== Data ===
* [https://www.dpp.cz/vozovy-park DPP – vozový park] – kapacity autobusů, typy vozidel
* [https://pid.cz/jizdni-rady-podle-linek/ PID – jízdní řády autobusů] – intervaly a rozložení spojů
* [https://www.dpp.cz/spolecnost/o-spolecnosti/dpp-v-datech DPP – statistiky] – počty cestujících, vytížení linek

Pro modelování rozložení cestujících v čase lze vycházet z běžných statistik dopravních podniků nebo využít odhadů podle typu linky (městská, příměstská, školní apod.).

=== Simulant ===
[[User:jelp05|jelp05]] ([[User talk:jelp05|talk]]) 18:35, 12 May 2025 (CET)

: OK, vyberte si prosím jednu zcela konkrétní linku. Budete to mít daleko snazší s daty. '''Schváleno'''. [[User:Tomáš|Tomáš]] ([[User talk:Tomáš|talk]]) 09:38, 16 May 2025 (CET)

== Simulace: Šíření invazních druhů rostlin v krajině ==

=== Popis problému ===
Invazní rostliny představují závažný ekologický problém, který ohrožuje biodiverzitu, mění dynamiku ekosystémů a může způsobovat výrazné ekonomické škody. Přestože existují různé metody jejich potlačení, jejich účinnost se liší podle situace a podmínek v dané oblasti. Vzhledem k tomu, že přímé testování zásahů v reálném prostředí je nákladné a obtížně opakovatelné, bude v této práci navržena simulace, která umožní predikci vývoje a porovnání efektivity různých zásahových strategií.

=== Cíl simulace ===
Simulace bude navržena s cílem modelovat a analyzovat dynamiku šíření vybraných invazních rostlinných druhů v různých typech krajiny. Bude zohledňovat klíčové faktory ovlivňující rozšiřování – jako jsou podmínky prostředí (vlhkost, teplota, typ půdy), biologické vlastnosti rostlin (rychlost růstu, produkce a klíčivost semen) a způsoby šíření (např. pomocí větru, vody nebo lidské činnosti). Součástí modelu bude také testování různých zásahových strategií, jako je mechanická likvidace, aplikace herbicidů nebo jejich kombinace

=== Použití simulace ===
Výsledky simulace poskytnou náhled na chování invazních druhů v čase a prostoru a umožní testovat zásahy bez přímého zásahu do reálného ekosystému. Simulace bude sloužit jako nástroj pro podporu rozhodování v oblasti ochrany přírody, krajinného plánování a managementu invazních druhů. Výstupy bude možné využít například ochranářskými organizacemi nebo správci chráněných území pro návrh efektivních a šetrných zásahových postupů.

=== Použitá metoda a prostředí ===
Prostředí: NetLogo (agentní modelování)

=== Proměnné ===
Deterministické proměnné:
* Biologické vlastnosti rostlin (rychlost růstu, počet a klíčivost semen, vegetační cyklus)
* Podmínky prostředí (vlhkost, teplota, typ půdy)
* Strategické zásahy (mechanické odstraňování, chemická likvidace, kombinace metod)
* Typ krajiny (pole, louka, les, urbanizované prostředí)

Náhodné proměnné:
* Směr a dosah šíření semen
* Počáteční rozmístění rostlin
* Vliv náhodných klimatických odchylek

=== Data ===
Data pro model budou získána z databáze Agentury ochrany přírody a krajiny ČR (https://invaznidruhy.nature.cz), která poskytuje podrobné informace o biologických a ekologických vlastnostech jednotlivých invazních druhů. Další poznatky budou čerpány z odborné literatury a metodických doporučení pro boj s invazními rostlinami.

=== Simulant ===
[[User:kala13|kala13]] ([[User talk:kala13|talk]]) 19:54, 12 May 2025 (CET)

: Máte to popsáno dost obecně. Předpokládám, že budete pracovat s konkrétními druhy, konkrétním prostředím, apod. '''Schváleno'''. [[User:Tomáš|Tomáš]] ([[User talk:Tomáš|talk]]) 09:40, 16 May 2025 (CET)

== Simulace: Optimální nacenění zálohy na vratné kelímky na akcích==

=== Popis problému ===
Organizátoři veřejných akcí jako jsou festivaly, koncerty nebo sportovní události, stále častěji přecházejí z jednorázových plastových kelímků na znovupoužitelné, aby snížili ekologickou stopu. Ovšem problém, který nastává při zavedení vratných kelímků na veřejných akcí, je správné nastavení výše zálohy a počet kelímků tak, aby se systém finančně vyplatil, návštěvníci akce jej přijali a zároveň nedošlo k nadbytečným nákladům. Výsledné náklady jsou ovlivňovány mnoho nejistými faktory – kolik lidí kelímek skutečně vrátí a kteří si jej nechají, kolik se jich ztratí nebo kolik nápojů se prodá.

=== Cíl simulace ===
Simulace má za cíl optimalizovat systém vratných kelímků – jaká je optimální výše zálohy vratného kelímku (nebo taky nulová záloha), která minimalizuje ztráty z nevrácených kelímků, ale zároveň neodradí návštěvníka od konzumace.

=== Použití simulace ===
Výsledky simulace poslouží především organizátorům akcí, kteří tak budou moct optimalizovat náklady, lépe rozhodnout o výši záloh a počtu objednaných kelímků.

=== Použitá metoda a prostředí ===
*Metoda: Monte Carlo simulace
*Simulační prostředí: Microsoft Excel

=== Proměnné ===
Deterministické proměnné:
* Počet návštěvníků akce
*Výrobní cena kelímku
*Cena nápoje
*Záloha
Náhodné proměnné:
*Pravděpodobnost vrácení kelímku
*Míra ztracených/poškozených kelímků

=== Data ===
*Ceník kelímků z nabídky různých dodavatelů (https://happycups.co.uk/, https://www.nicknack.cz/ )
*Statistiky vrácení kelímků z článků, statistiky (např. https://www.reuseable.dk/blog/aarhus-residents-have-returned-750-000-reusable-cups-in-one-year, https://www.nicknack.cz/reference-a-klienti/, https://packagingscotland.com/2024/11/pilot-scheme-sees-huge-percentage-of-reusable-cups-returned/ , https://www.reuseable.dk/blog/over-95-000-reuseable-cups-sold-during-festuge )

=== Simulant ===
[[User:Phpham|Phpham]] ([[User talk:Phpham|talk]]) 22:36, 12 May 2025 (CET)
:: Ve zdrojích nevidím data, ze kterých byste mohla odvodit pravděpodobnostní rozdělení pro uváděné náhodné proměnné. Převzetí průměrných veličin pro MC nestačí. [[User:Oleg.Svatos|Oleg.Svatos]] ([[User talk:Oleg.Svatos|talk]]) 07:14, 14 May 2025 (CET)

== Simulace: Vývoj výroby obnovitelné energie v ČR podle dat z roku 2019-2024 ==

=== Popis problému ===
Výroba elektřiny z obnovitelných zdrojů (OZE) v České republice v roce 2019 dosáhla 8 097 GWh. Největší část tvořila biomasa, následovaná vodními a fotovoltaickými elektrárnami. Tyto poměry významně ovlivňují jak energetickou bilanci, tak environmentální cíle. Cílem simulace je analyzovat, jak by se změnila celková výroba z OZE při různých scénářích – například při nárůstu výkonu solárních elektráren o 20 % nebo poklesu vodní výroby kvůli suchu.

=== Cíl simulace ===
Cílem simulace je zodpovědět otázky:
* Jak se změní celková výroba OZE, pokud vzroste výroba z FVE o 20 %?
* Jak pokles výroby z vodních elektráren o 15 % ovlivní celkový objem obnovitelné energie?
* Jaký by byl nový podíl jednotlivých zdrojů na výrobě při těchto změnách?

=== Použití simulace ===
Simulaci mohou využít energetičtí analytici, pracovníci MPO nebo regionální samosprávy jako nástroj pro plánování rozvoje obnovitelných zdrojů. Umožní jim snadno vyhodnotit, jak změny ve výkonu různých OZE typů ovlivní celkovou výrobu energie a pomůže při nastavování cílů nebo investičních priorit.

=== Použitá metoda a prostředí ===
Simulace bude provedena pomocí systémové dynamiky v prostředí Vensim PLE.

=== Proměnné ===
* Výroba elektřiny z OZE celkem (GWh)
* Výroba z biomasy (GWh)
* Výroba z vody (GWh)
* Výroba z fotovoltaiky (GWh)
* Podíl jednotlivých zdrojů (%)
* Změna výkonu zdrojů (%)
* Nová celková výroba (GWh)

=== Data ===
* Bilance elektrické energie – Český statistický úřad ([https://csu.gov.cz/energetika](https://csu.gov.cz/energetika))
* Obnovitelné zdroje energie – Výsledky statistického zjišťování- dokumenty za roky 2019–2024 – Ministerstvo průmyslu a obchodu ČR ([https://mpo.gov.cz](https://mpo.gov.cz))
* Roční zpráva o provozu elektrizační soustavy ČR – Energetický regulační úřad ([https://eru.gov.cz](https://eru.gov.cz))
* Share of energy consumption from renewable sources in Europe – Evropská agentura pro životní prostředí ([https://www.eea.europa.eu/en/analysis](https://www.eea.europa.eu/en/analysis))

=== Simulant ===
[[User:laso00|Oriana Lastovickova (laso00)]] ([[User talk:laso00|talk]]) 6:22, 13 May 2025 (CET)
:: '''Schváleno''' [[User:Oleg.Svatos|Oleg.Svatos]] ([[User talk:Oleg.Svatos|talk]]) 06:30, 14 May 2025 (CET)

== Simulace: Predikce vítěze turnaje v League of Legends ==

=== Popis problému ===
Mid-Season Invitational (MSI) představuje každoroční stěžejní událost světového e-sportu, kde se střetávají nejlepší týmy League of Legends z jednotlivých regionů. Vzhledem k náhodnosti výsledků, různé síle regionů, aktuální formě týmů a pavoukovému systému turnaje je obtížné určit předem, kdo má nejvyšší šanci na výhru.

=== Cíl simulace ===
Cílem této simulace je odhadnout pravděpodobnosti výhry jednotlivých týmů pomocí náhodně generovaných výsledků zápasů na základě historické výkonnosti a aktuálních power rankings.

=== Použití simulace ===
* E-sportová analýza
* Simulace turnaje
* Sázení :)

=== Použitá metoda a prostředí ===
Použitou metodou je Monte Carlo simulace, která umožňuje modelovat nejistotu výsledků jednotlivých zápasů na základě pravděpodobností odvozených z ELO skóre týmů. Pomocí opakovaného náhodného generování výsledků (např. 1 000 simulací) lze odhadnout pravděpodobnosti výhry každého týmu v celém turnaji.

Simulace je realizována v prostředí Microsoft Excel (v české verzi), který poskytuje všechny potřebné nástroje – generování náhodných čísel, výpočty pravděpodobností, podmíněné funkce i vizualizaci výsledků.

=== Proměnné ===
Definované předem:
* Seznam týmů - 10 týmů
* ELO skóre - měřítko síly
* Turnajová struktura

Náhodné:
* Výsledek zápasu - generována jako náhodný výběr podle pravděpodovnosti výhry týmu A vůči B
* Pravděpodnost výhry - spočtena z rozdílu ELO týmu A a týmu B

=== Data ===
* https://oracleselixir.com/
* https://lolesports.com/en-US/gpr/2025
* https://lol.fandom.com/wiki/League_of_Legends_Esports_Wiki

=== Simulant ===
[[User:Hrui00|Hrui00]] ([[User talk:Hrui00|talk]]) 16:21, 13 May 2025 (CET)
:: Krom toho, že tyto simulace dopadají tragicky, tak u těch náhodných proměnných nevidím, jak tam budete odvozovat pravděpodobnostní rozdělení (z čeho a jak), ze kterého budete pak generovat náhodná čísla. Základní pravděpodobnosti, nebo nějaké jejich poměry nejsou MC. Buďto to nějak upřesněte, nebo zkuste něco jiného (byl bych spíš pro tuto variantu). [[User:Oleg.Svatos|Oleg.Svatos]] ([[User talk:Oleg.Svatos|talk]]) 07:25, 14 May 2025 (CET)

Assignment SS 2024/2025/cs

2025-05-15T19:41:02Z

Sanv05:

{{Ambox
| text = <div>
Please, put here your assignments. Do not forget to sign them. You can use <nowiki>~~~~</nowiki> (four tildas) for an automatic signature. Use Show preview in order to check the result before your final sumbition.
</div>
}}

{{Ambox
| text = <div>
Please, strive to formulate your assignment carefully. We expect an adequate effort to formulate the assignment as it is your semestral paper. Do not forget that your main goal is a research paper. It means your simulation model must generate the results that are specific, measurable and verifiable. Think twice how you will develop your model, which entities you will use, draw a model diagram, consider what you will measure. No sooner than when you have a good idea about the model, submit your assignment. And of course, read [[How to deal with the simulation assignment|How to deal with the simulation assignment]].
</div>
}}

{{Ambox
| text = <div>
Topics on gambling, cards, etc. are not welcome.
</div>
}}

{{Ambox
| type = content
| text = <div>
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.
</div>
}}

{{Ambox
| text = <div>
'''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).'''

# Is it clear from the proposed assignment how the simulation will work?
# Does the simulation make sense?
# Is the simulation model complex enough to simulate credibly the real-world phenomenon that the simulation tries to simulate?
# Is the data used real and relevant for the real-world phenomenon that the simulation tries to simulate?
# 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.'''

</div>
}}

== Simulace výběru optimální lokality pro koupi nemovitosti s ohledem na budoucí rizika ==

=== Popis problému ===
Simulace bude modelovat rozhodovací proces investora při výběru bezpečné lokality pro investici do nemovitosti kdekoliv na světě, s ohledem na budoucí rizika. V rozhodovacím procesu hraje roli celá řada faktorů – od historického vývoje cen nemovitostí, přes kriminalitu a politickou stabilitu až po klimatická rizika, jako jsou záplavy, stoupání mořské hladiny nebo úbytek vody. Cílem je určit, které lokality mají vysoký potenciál růstu hodnoty a zároveň co nejnižší rizika v horizontu příštích lét či dekád. Téma je obvzláště aktuální vzhledem k politickému dění naší doby.

=== Cíl simulace ===
Cílem simulace je analyzovat:
*Dlouhodobou rizikovost jednotlivých lokalit pro investice do nemovitostí
*Vliv globálních trendů (klima, migrace, infrastruktura, ekonomický vývoj) na budoucí výnos
*Identifikaci zón, kde se předpokládá stabilní růst
*Dopad scénářů (např. klimatická krize, politické otřesy) na hodnotu investice
*Zohlednění takových proměnných jako cena nemovitosti, kriminalita ve vybrané lokalitě aj.

=== Použití simulace ===
*Fyzickými osobami
*Soukromými investory a fondy investujícími do rezidenčních i komerčních nemovitostí
*Analytiky bank a pojišťoven při určování pojistných rizik nemovitostí a rizik poskytování finančních prostředků ke koupi oných nemovitostí
*Urbanisty a plánovači udržitelného rozvoje měst
*Pro prediktivní analýzy trhu

=== Použitá metoda a prostředí ===
*Monte Carlo simulace s vícero scénáři budoucího vývoje
*Simulační prostředí: Excel (potenciálně NetLogo, pokud mě během práce napadne jak to pojmout pomocí tohoto nástroje, například by mohl být za agenty považováni investoři s různými preferencemi a tolerancí k riziku)
*Simulace je stavěná na lokalitách (nejspíše to budou města) s atributy přiřazenými z reálných datových zdrojů a i náhodnými proměnnými

=== Proměnné ===
Definované předem:
*location - geografická lokalita 
*property_value - současná průměrná cena nemovitosti
*climate_risk_index - souhrnný index klimatického rizika (záplavy, sucho, mořská hladina, požáry)
*infrastructure_score - skóre infrastruktury a dopravní dostupnosti
*governance_index - kvalita vládnutí a právní ochrany
*historical_growth - průměrný roční růst cen nemovitostí za posledních X let
*další proměnné co mě napadnou a budou dávat smysl

Náhodné:
*political_instability - pravděpodobnost politických nepokojů nebo regulačních změn
*population_flow - změna počtu obyvatel (vliv migrace, urbanizace)
*climate_event_frequency - frekvence extrémních klimatických jevů v následujících X letech
*investment_sentiment - nálada investorů a pravděpodobnost, že investoři danou lokalitu upřednostní
*economic_shock - externí šoky (např. finanční krize) ovlivňující hodnotu
*další proměnné co mě napadnou a budou dávat smysl

=== Data ===
*Cost of Living https://www.numbeo.com/cost-of-living/
*Climate Risk Index 2025 https://www.germanwatch.org/en/cri
*World cities report 2024 https://unhabitat.org/wcr/
*Housing prices https://www.oecd.org/en/data/indicators/housing-prices.html?oecdcontrol-82d381eddd-var3=2025
*Crime https://www.numbeo.com/crime/
*Catastrophe Data Hub https://www.eiopa.europa.eu/tools-and-data/catastrophe-data-hub_en
*další data která během práce a rešerše najdu a budu považovat za relevantní

=== Simulant ===
[[User:Isar00|Isar00]] ([[User talk:Isar00|talk]]) 22:01, 13 May 2025 (CET)
:: Na Monte Carlo to moc nevidím, nedokážu si představit, jak pro uvedené náhodné proměnné budete odvozovat pravděpodobnostní rozdělení. Asi by by to šlo ve Vensimu - co vy na to? [[User:Oleg.Svatos|Oleg.Svatos]] ([[User talk:Oleg.Svatos|talk]]) 07:20, 14 May 2025 (CET)
:: Já se hlavně obávám, že je to úloha sice zajímavá, ale velmi obtížně řešitelná. Resp. k nějakým výsledkům se určitě dojde, ale jejich ověření bude nesmírně problematické. Doporučoval bych přemýšlet o něčem jiném. [[User:Tomáš|Tomáš]] ([[User talk:Tomáš|talk]]) 12:19, 14 May 2025 (CET)

== Simulace: Sebe-deportační program pro nelegální vetřelce v USA ==

=== Popis problému ===
Simulace bude modelovat rozhodovací proces nelegálních migrantů („illegal aliens“) v USA v rámci nového programu sebe-deportace prostřednictvím aplikace CBP Home. Tento program nabízí finanční odměnu ve výši 1 000 USD a bezplatný let „kamkoliv“ výměnou za dobrovolný odchod ze země. Pomocí této iniciativy dle slov prezidenta Trumpa ušetří daňoví poplatníci v USA „miliardy a miliardy“ dolarů.

=== Cíl simulace ===
Cílem simulace je analyzovat program sebe-deportace z hlediska:
*Počtu migrantů, kteří se rozhodnou program využít
*Finančních úspor pro vládu USA ve srovnání s náklady na nucené deportace
*Klíčových faktorů ovlivňujících rozhodnutí migrantů

=== Použití simulace ===
*Ministerstvem vnitřní bezpečnosti USA pro odhad efektivity programu a optimalizaci politiky sebe-deportace
*Týmem Donalda Trumpa pro další predikci ohledně úspor daňových poplatníků
*Výzkumnými institucemi pro analýzu dopadů imigračních politik na chování migrantů

=== Použitá metoda a prostředí ===
*NetLogo
*Každý agent bude reprezentovat jednotlivého vetřelce s vlastními atributy stanovenými pomocí níže uvedených proměnných. Na základě těchto atributů a definovaných pravidel se agenti budou rozhodovat, zda program sebe-deportace využijí. Prostředí simulace bude tvořeno mřížkou, kde jednotlivé buňky mohou reprezentovat různé geografické oblasti s odlišnou úrovní vymáhání práva. Agenti se mohou pohybovat po této mřížce.

=== Proměnné ===
Definované předem:
*enforcement_level - úroveň vymáhání imigračního práva v daném regionu
*incentive_amount - výše finanční pobídky za sebe-deportaci (1000 USD)
*awareness_level - informovanost migranta existenci o programu (s časem roste)
*time_since_policy - doba od spuštění programu

Náhodné:
*decision_to_leave - rozhodnutí migranta odejít (ano/ne) na základě vypočtené pravděpodobnosti (ovlivněné jeho atributy)
*risk_of_enforcement - riziko zadržení a deportace
*trust_in_government - důvěra migranta ve vládní instituce a sliby
*family_pressure - tlak rodiny na rozhodnutí zůstat nebo odejít

=== Data ===
*AMERICAN IMMIGRATION COUNCIL, 2025. U.S. Immigration Statistics. American Immigration Council [online]. [vid. 2025-05-13]. Dostupné z: https://map.americanimmigrationcouncil.org/locations/national/
*BATALOVA, Jeanne Batalova Jeanne, 2025. Frequently Requested Statistics on Immigrants and Immigration in the United States. migrationpolicy.org [online] [vid. 2025-05-13]. Dostupné z: https://www.migrationpolicy.org/article/frequently-requested-statistics-immigrants-and-immigration-united-states
*BELL, Peter, 2024. Public Trust in Government: 1958-2024. Pew Research Center [online]. [vid. 2025-05-13]. Dostupné z: https://www.pewresearch.org/politics/2024/06/24/public-trust-in-government-1958-2024/
*DHS.GOV, 2025. DHS Announces Historic Travel Assistance and Stipend for Voluntary Self-Deportation | Homeland Security [online] [vid. 2025-05-13]. Dostupné z: https://www.dhs.gov/news/2025/05/05/dhs-announces-historic-travel-assistance-and-stipend-voluntary-self-deportation?utm_source=chatgpt.com
*ICE.GOV, 2025. ICE Enforcement and Removal Operations Statistics | ICE [online] [vid. 2025-05-13]. Dostupné z: https://www.ice.gov/statistics
*+další statistická data

=== Simulant ===
[[User:Masd04|Masd04]] ([[User talk:Masd04|talk]]) 15:50, 13 May 2025 (CET)
:: Téma je bezesporu originální a oceňuji satirickou notu, kterou v něm cítím. Ale je velmi obtížně vyhodnotitelné. Pracujete s velmi měkkými veličinami, výsledky by byly nesmírně těžko prokazatelné. Popřemýšlejte o tom prosím ještě, případně navrhněte něco jiného. [[User:Tomáš|Tomáš]] ([[User talk:Tomáš|talk]]) 12:32, 14 May 2025 (CET)

== Simulace: Bakterie na rukou ==

=== Popis problému ===
Bakterie, stejně jako jiné mikroorganismy, jsou přítomny kolem nás a končí pak i na našich rukou. Některé mohou být pro člověka zdrojem infekcí. Je proto důležité dbát na řádnou hygienu a umývat si ruce pečlivě.

=== Cíl simulace ===
Cílem bude simulovat množství bakterií (od virů, prvoků apod. abstrahuji pro zjednodušení) na povorchu lidské ruky (abstrahuji od rozdílu mezi dominantní a nedominantní) za běžného dne a jaký na něj vliv má četnost a kvalita mytí rukou.

=== Použití simulace ===
* Edukativní – názorná ukázka např. dětem
* Simulace účinku mycích prostředků

=== Použitá metoda a prostředí ===
Simulace v NetLogo. Bakterie budou existovat na povrchu ruky (respektive dlaně). S postupem času vznikají události navyšující počet bakterií (např. použití wc – bude záviset na dostupnosti dat). Události mytí rukou jejich počet naopak sníži – míra závisí na použitém přípravku (např. pouze voda, mýdlo, 70% ethanol) a kvalitě (pečlivosti) mytí. Mokré ruce na sebe nachytávají více bakterií.

Je možné, že simulace bude "interaktivní" v tom smyslu, že uživatel simulace bude mít možnost spouštět (nebo nespouštět) jednotlivé události které zvyšují počet bakterií a události mytí rukou. Tuto verzi osobně preferuji (interaktivní materiály zpravidla naučí více), nicméně ve výsledku bude záviset na možnostech NetLoga a mé schopnosti s kódem.

=== Proměnné ===
Definované předem:
* Bakterie – pobývají na povrchu ruky
* Účinnost přípravku – jak účinně (%) přípravek redukuje počet bakterií
* Typ člověka – jak čistotný majitel ruky je –> jak kvalitně si myje ruce a jestli jsou suché (T/F)

Náhodné:
* Rozmístění bakterií.
* Příbytek bakterií (počet v rámci daného rozmezí)

=== Data ===
* https://www.ccmhhealth.com/clean-hands-count/
* https://www.cdc.gov/clean-hands/data-research/facts-stats/index.html
* https://www.idnes.cz/onadnes/zdravi/co-zije-na-vasich-dlanich.A081110_123959_zdravi_bad
* další – najít data s konkrétnímy čísly zabere více času než mám aktuálně k dispozici.
Věřím však, že to bude možné. Případně přizpůsobím nějaké proměnné nalezeným datům (např. pokud mi kvalitní data umožní přidat proměnné nebo nějaké nahradit), aby práce byla podložena daty.

=== Simulant ===
[[User:Jana19|Jana19]] ([[User talk:Jana19|talk]]) 21:57, 12 May 2025 (CET)

: Téma vypadá dobře, moc se mi jen nelíbí, že hlavně proměnné jsou hodně "měkké". Nejhorší v tomto smyslu je ten "typ člověka". Jak to budete hodnotit, kolik lidí kterého typu existuje - kór, když jde o kritérium binární? Zkuste to dopracovat a najít "tvrdší" charakteristiky, ke kterým data snáze najdete. Co třeba typy povrchů? [[User:Tomáš|Tomáš]] ([[User talk:Tomáš|talk]]) 12:39, 14 May 2025 (CET)

RE: Typ člověka není binární kritérium, binární je poze to, zda jsou ruce mokré nebo suché – tedy mokré: True/False. Což ale souvistí s tím typem člověka, který by měl popisovat, jak dobře si ruce myje a suší. Ze sušení pak vzniká ta binární proměnná. To jak kvalitně si myje ruce si představuji jako nějaký koeficient – hodnota z nějakého rozmezí, kterou bych poté vynásobila účinek mycího prostředku aby se vyhodnotil úbytek bakterií.
Konkrétní pobobu toho typu člověka musím ještě promyslet, hlavně podle toho jak najdu data – pravděpodobně to bude odvozené z délky mytí rukou (kolik je potřeba a kolik tomu lidé obvykle dají). Ale jedna z možností, co mě napadla by bylo vytvoření archetypů jako "špindíra" a "poctivec", které by ten koeficient nastavili na určitou honotu. Ale mohla bych tam asi dát i možnost uživateli si jej nastait, jak chce (tedy v nějaké pro uživatele stravitelné podobě).
Myslíte, že bude stačit takto ten koeficient, nebo tam budete chtít i zanést nějakou míru náhody (jako náhodnou odchylku +- xy % při akci mytí rukou)?

== Simulace: Chování zákazníků v supermarketu/večerce ==

=== Popis problému ===
Supermarkety čelí výzvám při optimalizaci rozložení regálů a organizace prostoru, aby maximalizovaly zisk a zkrátily dobu nákupu tak, aby se prostory nepřeplnily. Zákazníci mají různá nákupní chování, přičemž někteří nakupují plánovaně, jiní se rozhodují impulzivně nebo reagují na nabídky slev. Tyto faktory spolu s hustotou zákazníků, pozicemi zboží a frontami mohou mít zásadní vliv na efektivitu nákupního procesu.

=== Cíl simulace ===
Cílem simulace je zjistit, jak správné rozmístění regálů napomůže efektivitě supermarketu/večerky. Toho by mělo být dosaženo zakomponováním různých faktorů, které chod ovlivňují, jako je rozložení zboží, počet zákazníků a jejich chování, slevy, Délku pobytu v obchodě, Zatížení jednotlivých uliček a zón, Pravděpodobnost nákupu akčního zboží, Fronty u pokladen....

Simulace by měla pomoci v návrhu efektivního rozmístění a optimalizaci nákupního procesu.

=== Použití simulace ===
Kdo může simulaci použít?
* Marketingová oddělení
* večerky
* supermarkety
* Designeři obchodních prostorů

=== Použitá metoda a prostředí ===
Simulace bude vytvořena v NetLogo, které umožní modelovat prostor supermarketu, pohyb zákazníků a jejich chování. Každý zákazník, zboží, sleva je považován za agenta, který interaguje s prostředím (supermarketem) a dalšími agenty (ostatními zákazníky). Model bude simulovat různé množství zákazníků, rozmístění zboží, slevy.

=== Proměnné ===
Definované předem:

* Rozložení obchodu: Počet regálů, uliček,...
* Průměrná doba strávená na pokladně
* Kapacita pokladen
* Počet zón v obchodě: Zóny jako ovoce, zelenina, pečivo, nápoje,...
* Typy zboží v prodeji
* Typ slevové akce

Náhodné:
* Typ zákazníka - plánovaný nákup, impulzivní nákup, procházející,...
* Doba rozhodování o nákupu - např. plánovaný 5-10sec, impulzivní - x sec,...
* Rychlost pohybu zákazníka
* Počet zákazníků v obchodě
* Umístění zboží ve slevě - v simulaci bych mohl ozkoušet i druhou verzi kdy bude umístění vždy stejné.

=== Data ===

* Prostředí supermarketu [https://www.zboziaprodej.cz/2023/04/04/jak-ovlivnuje-zakazniky-prostredi-ve-kterem-nakupuji/]
* Grocery layout [https://www.wavegrocery.com/blogpost/use-your-grocery-store-layout-to-boost-sales?]
* Kapacita/rychlost pokladen [https://www.millsshelving.com.au/how-to-create-an-inviting-retail-store-layout/]
* Layout [https://planohero.com/en/blog/grocery-store-layout-strategy/]
* How to Create an Inviting Retail Store Layout [https://www.millsshelving.com.au/how-to-create-an-inviting-retail-store-layout/?]
* How Understanding Your Grocery Store’s Layout Can Save You Money [https://www.goodrx.com/well-being/diet-nutrition/grocery-store-layout?]
* Typy zákazníků [https://strate9y.com/analyza-zakazniku-tajemstvi-uspechu-podnikani/?]
* Rozložení prodejen v Čr

=== Simulant ===
[[User:Kubd06|Kubánek David (kubd06)]] ([[User talk:Kubd06|talk]]) 22:00, 12 May 2025 (CET)

: '''Schváleno'''. Téma dobré, jen si dejte pozor na "měkké" proměnné. Třeba to striktní oddělení impulzivního/normálního nákupu není podle mě realistické a neseženete k tomu data. Raději bych pracovat s nějakou proměnnou délky strávené v prodejně. Tady hodnoty příslušného statistického rozdělení rozhodně seženete lépe. [[User:Tomáš|Tomáš]] ([[User talk:Tomáš|talk]]) 12:43, 14 May 2025 (CET)

== Simulace: Dynamika technického dluhu v softwarovém vývoji ==

=== Popis problému ===
Technický dluh v softwarovém vývoji vzniká, je a taky i bude. Jedním z důvodu vzniku je tlak na rychlost dodání, zvolení suboptimálního řešení nebo zkratky pro usnadnění práce. Tento dluh se hromadí v kódové bázi a systému a chová se podobně jako finanční dluh – s "úroky" v podobě zvýšeného úsilí na budoucí údržbu, opravy chyb ale i implementaci nových funkcí. Akumulovaný dluh tak postupně zpomaluje vývojový tým, snižuje agilitu projektu a zvyšuje celkové dlouhodobé náklady pro celou firmu.

=== Cíl simulace ===
Simulace si dává za úkol namodelovat dynamiku akumulace dluhu a jeho splácení v čase. Jaký ma vliv na produktivitu. Ale hlavně jaké různé strategie řízení dluhu jsou dlouhodobě nejefektivnejší (např. konstatní alokace času na refaktoring vs. reaktivní přístup).

=== Použití simulace ===
* Jako podpora při rozhodování projektových manažerů o prioritách (rychlost vs. kvalita).
* Může pomoci stakeholderům pochopit náklady a přínosy investic do kvality kódu (argumenty pro CIO).
* Pro strategické plánování v IT organizacích týkající se údržby a rozvoje systémů.

=== Použitá metoda a prostředí ===
* Simulace využívá metodu systémové dynamiky (System Dynamics).
* Bude použit program Vensim.

=== Proměnné ===
Definované předem:
* Počáteční úroveň technického dluhu.
* Počáteční rozsah backlogu (nesplněných požadavků).
* Velikost týmu.
* Základní produktivita týmu (bez vlivu dluhu).
* Míra alokace času na refaktoring (strategické rozhodnutí).

Náhodné:
* Tempo příchodu nových požadavků do backlogu.
* Efektivita refaktorovacích snah (malé fluktuace).
* Výskyt neočekávaných problémů vedoucích k tvorbě dluhu (např. kritické chyby).

Popřípadě další.

=== Data ===
* Produkční data budou ťežko získatelné, proto využijeme kombinaci odhadu expertů z praxe a odbornou literaturu.

* GUPTA, Kartik, 2025. Measuring the Impact of Technical Debt on Development Effort in Software Projects. arXiv [online]. [cit. 2025-05-12]. Dostupné z: https://arxiv.org/abs/2502.16277
* YLI-HUUMO, Jesse, Andrey MAGLYAS a Kari SMOLANDER, 2016. How do software development teams manage technical debt? – An empirical study. Dostupné z: doi:https://doi.org/10.1016/j.jss.2016.05.018
* TOM, Edith, Aybüke AURUM a Richard VIDGEN, 2013. An exploration of technical debt. Journal of Systems and Software. 86(6), 1498–1516. Dostupné z: doi:https://doi.org/10.1016/j.jss.2012.12.052
* HOLVITIE, Johannes, Sherlock A. LICORISH, Rodrigo O. SPÍNOLA, Sami HYRYNSALMI, Stephen G. MACDONELL, Thiago S. MENDES, Jim BUCHAN a Ville LEPPÄNEN, 2018. Technical debt and agile software development practices and processes: An industry practitioner survey. Information and Software Technology. 96, 141–160. Dostupné z: doi:https://doi.org/10.1016/j.infsof.2017.11.015

=== Simulant ===
[[User:Hrus07|Hrus07]] ([[User talk:Hrus07|talk]]) 22:19, 12 May 2025 (CET)
:: '''Schváleno''' [[User:Oleg.Svatos|Oleg.Svatos]] ([[User talk:Oleg.Svatos|talk]]) 06:29, 14 May 2025 (CET)

== Simulace: Útoky medvědů ==

=== Popis problému ===
Na Slovensku se vyskytuje velké množství medvědů, kteří ohrožují tamní obyvatele a turisty. Útoky jsou momentálně velmi časté a přibývají. Slovenská vláda schválila návrh na odstřel cca 350 jedinců. Zároveň se jedná o chráněný druh, tudíž počty by neměly být redukovány ve velké míře, ne-li vůbec.

=== Cíl simulace ===
Cílem bude simulovat ideální počet medvědů, aby se minimalizoval počet útoků medvěda a potřeba redukovat počet medvědů.

=== Použití simulace ===
* Např. pro plánování odstřelu medvědů, aby druh nebyl příliš ohrožen.
* Simulace chování medvědů v přírodě.

=== Použitá metoda a prostředí ===
Multiagentní simulace v NetLogo. Agenti budou medvědi, turisti a lovci. V prostředí se populace medvědů bude přirozeně zvyšovat. Turisté mají šanci na útěk. Lovci budou reagovat na incidenty medvědů s turisty.

=== Proměnné ===
Definované předem:
* Medvědi – pohybují se po krajině, hledají potravu a případně útočí na turisty
* Lovci – redukují počty medvědů na základě útoků a ohrožení turistů.
* Turisti – objevují tamní krajinu a lesy. Reagují na přítomnost medvědů.

Náhodné:
* Rozmístění medvědů, lovců a turistů.
* Rozmístění vegetace, lesů.

=== Data ===
* Slovenská vláda schválila odstřel medvědů [https://www.irozhlas.cz/zpravy-svet/nemuzeme-zit-v-zemi-kde-se-lide-boji-chodit-do-lesa-slovenska-vlada-schvalila_2504021255_mst]
* Medvěd hnědý - biotop a teritorium [https://www.selmy.cz/medved/biotop-a-teritorium/]
* Medvěd na Slovensku [https://sita.sk/nasvidiek/kolko-medvedov-zije-na-slovensku-studia-ukazala-cisla-a-najviac-ich-je-na-polane/?utm_source=chatgpt.com]

=== Simulant ===
[[User:Vlcj07|Vlcj07]] ([[User talk:Vlcj07|talk]]) 19:43, 12 May 2025 (CET)

: Dejte si opravdu pozor na zdrojová data a jejic využití. Simulace se dá provést více způsoby, pokud by to bylo příliš zjednodušené, mohlo by se to zvrhnout v banalitu (je to v podstatě varianta Predator-Prey, která byla simulována už nesčetněkrát). Provést to realisticky nebude úplně snadno. '''Schváleno'''. [[User:Tomáš|Tomáš]] ([[User talk:Tomáš|talk]]) 12:48, 14 May 2025 (CET)

== Simulace: Přemnožení divokých prasat ==

=== Popis problému ===
Divoká prasata jsou v České republice přemnožená – na našem území jich je v současnoti 100krát více, než je únosné. Přemnožení je zapříčeněno několika faktory. Prvním je způsob rozmnožování divokých prasat. Bachyně mívají dva vrhy ročně, přičemž v každém vrhu se vyskytuje průměrně 4-12 selat. Při přebytku potravy tak populace divokých prasat prudce roste. Druhý faktor, který zapříčiňuje přemnožení prasat, je absence přirozených predátorů těchto zvířat na našem území. Kontrolu populace pak musejí provádět myslivci, nicméně odtřel je v současné době nedostatečný.

Přemnožená prasata mají negativní dopad na vegetaci svého okolí. Jedná se například o rostlinu bleduli letní, která se v České republice řadí mezi zvláště chráněné druhy rostlin.

=== Cíl simulace ===
Cílem simulace bude simulovat ideální míru odstřelu divokých prasat, aby nedošlo ke zničení vzácné vegetace (jako je například bledule letní). V simulaci bude zobrazena součinnost několika faktorů (růst prasečí populace v závislosti na přítomnosti potravy, množství střelců nutných pro udržení populace na uzdě apod.).

=== Použití simulace ===
Kdo může simulaci použít?
* Myslivci pro informovanější plánování odstřelu prasat.
* Lesní správa, farmářský a zahradnický průmysl apod. – všechna tato odvětví jsou negativně ovlivněná přemnoženou prasečí populací.
* Simulace může problematiku přiblížit i širší veřejnosti, která tak bude lépe schopná seznat její závažnost.

=== Použitá metoda a prostředí ===
Prostředím multiagentní simulace bude NetLogo. Agenti budou divoká prasata, myslivci a vzácná vegetace. Prasata se budou množit rychlostí závislou na množství vegetace. Model bude simulovat různé počty myslivců a různé strategie střelby. Množství vegetace bude závislé na velikosti prasečí populace.

=== Proměnné ===
Definované předem:
* Rychlost množení a „žravost“ divokých prasat.
* Rychlost obnovy vegetace.
* Počet myslivců a strategie a způsob jejich odstřelování prasat.

Náhodné:
* Počáteční populace prasat (v určitém rozmezí).
* Počáteční množství vegetace (opět v určitém rozmezí).
* Rozmístění prasat.
* Rozmístění myslivců.
* Rozmístění vegetace.

=== Data ===
* Prasata devastují vzácnou zeleň. [https://benesovsky.denik.cz/zpravy_region/premnozena-prasata-pustosi-benesovsko-mizi-bledule-i-orchideje-20250318.html]
* Způsob rozmnožování divokých prasat. [https://www.hubeni-skudcu.cz/blog/prase-divoke/]
* Policejní odstřel divokých prasat. [https://www.idnes.cz/liberec/zpravy/odstrel-divocaku-praseci-mor-liberec-jablonec-myslivci-policie.A241212_140610_liberec-zpravy_cink]
* Prase divoké – základní informace. [https://www.kdelovit.cz/cz/lovna-zver/srstnata/prase-divoke]
* Životní cyklus divokých prasat. [https://cit.vfu.cz/pohoda/zivotni_cyklus.pdf]
* Lov divokého prasete. [https://huntasticzech.cz/zvire/prase-divoke/]

=== Simulant ===
[[User:Kalp08|Petr Kalina (kalp08)]] ([[User talk:Kalp08|talk]]) 13:52, 12 May 2025 (CET)

: Jde o variantu klasické úlohy Predator-Prey, která byla řešena už mnohokrát. Chtěl bych, aby to nedopadlo klasicným rámečkem s rozmístěnými prasaty. myslivci a vegetací, takže bych doporučoval ještě rozpracovat detaily. Nicméně '''schváleno'''. [[User:Tomáš|Tomáš]] ([[User talk:Tomáš|talk]]) 12:54, 14 May 2025 (CET)

== Simulace: Šíření dezinformací na sociálních sítích ==

=== Popis problému ===
Simulace modeluje šíření dezinformace mezi uživateli sociální sítě. V dnešním digitálním prostoru jsou informace často sdíleny bez jejich ověřování, což přispívá k rychlému rozšiřování nepravdivých nebo manipulativních zpráv. Sociální sítě jsou hlavním kanálem pro šíření jak pravdivých, tak nepravdivých informací. Model zkoumá, jak rychle a do jaké míry se dezinformace rozšíří napříč sítí uživatelů, kteří jsou mezi sebou propojeni pomocí přátelství nebo sledujících. Ovlivňujícími faktory jsou zejména míra ochoty sdílet, schopnost rozpoznat nepravdivý obsah, struktura sítě (např. počet spojení) a chování jednotlivců. Cílem je porozumět tomu, jaké strategie mohou šíření zpomalit či omezit a jak síťová struktura ovlivňuje zranitelnost vůči dezinformacím.

=== Cíl simulace ===
Cílem simulace je odpovědět na otázku: jak ovlivňuje struktura sociální sítě, chování jednotlivých uživatelů a míra kritického myšlení rychlost a rozsah šíření dezinformací? Simulace umožní identifikovat klíčové parametry, které mohou buď přispět k virálnímu šíření, nebo ho potlačit. Výsledkem může být doporučení k edukaci uživatelů nebo návrh algoritmických opatření pro omezení dosahu problematického obsahu.

=== Použití simulace ===
Simulace má možné využití:
* Jako didaktický nástroj pro výuku mediální a digitální gramotnosti nebo informační bezpečnost
* Pro využití v akademickém výzkumu zabývajícím se šířením obsahu v online prostředí, včetně fake news a konspiračních teorií.

Výsledky mohou posloužit i jako argument pro zavedení preventivních opatření na sociálních platformách.

=== Použitá metoda a prostředí ===
Simulace je vytvořena v prostředí NetLogo. Agenti představují uživatele sociální sítě a jsou propojeni do komunikační struktury (vztahy: „sleduje“, „přátelí se“). Dezinformace se šíří po těchto spojeních. V modelu existují pravidla pro šíření dezinformace a rozhodování agentů. To znamená, že každý agent má určitou pravděpodobnost sdílení, může si informaci ověřit a tím ji zablokovat, nebo ji předat dál.

=== Proměnné ===
'''Definované předem:'''
• počet uživatelů v síti
• typ sociální sítě/síťové struktury (náhodná síť, small-world, scale-free)
• průměrný počet spojení na agenta = síťová hustota
• počet původních šiřitelů dezinformace
• pravděpodobnost sdílení dezinformace (bez ověření)
• pravděpodobnost ověření zprávy a zamezení jejího šíření
'''Náhodné:'''
• rozložení spojení v síti
• výběr původních šiřitelů
• pořadí interakcí mezi agenty (směr šíření, kdo ovlivní koho)
• individuální rozhodnutí každého agenta (na základě pravděpodobností)
• výsledný rozsah šíření (liší se běh od běhu i při stejných nastaveních)

=== Data ===
* Výzkumy behaviorální ekonomie a mediální gramotnosti – např. [https://mediaeducation.ucoz.ru/_ld/0/83_Fedorov-A-2007-.pdf JIRÁK, Jan; WOOLÁK, Radim Woolák Radim. Mediální gramotnost. Praha: Radioservis, 2009.]
* Analýzy šíření fake news – např. Vosoughi, Roy, Aral (2018) – „The spread of true and false news online“, Science 359(6380), 1146–1151. [https://ide.mit.edu/wp-content/uploads/2018/12/2017-IDE-Research-Brief-False-News.pdf „The spread of true and false news online“]
* Odhady pravděpodobností a struktury sítě vycházejí z běžného chování uživatelů na sociálních sítích
* Výzkumné zprávy o algoritmech šíření obsahu na platformách jako Facebook, Instagram, nebo TikTok

=== Simulant ===
[[User:macn04|macn04]] ([[User talk:macn04|talk]]) 14:30, 12 May 2025 (CET)

: Podobná témata se občas objevují, ale většinou narazí na problém, že je nesmírně těžké u tohoto typu problému pracovat s nějakými tvrdými daty. Výsledky by pak zůstaly jen velmi nahodilé. Zkuste popřemýšlet, jestli by byla cesta, jak se tomuto problému vyhnout, alternativně samozřejmě můžete zvážit i jiné téma. [[User:Tomáš|Tomáš]] ([[User talk:Tomáš|talk]]) 08:40, 15 May 2025 (CET)

== Simulace: Evakuace šelem v pražské ZOO v případě povodně ==

=== Popis problému ===
Pražská zoologická zahrada se nachází v záplavovém území a v minulosti byla při povodních (např. v roce 2002 a 2013) vážně zasažena. Evakuace zvířat, zejména velkých a nebezpečných šelem, představuje logisticky i bezpečnostně náročný úkol. Zvířata musí být přepravena v co nejkratším čase, bezpečně a s minimálním stresem, zároveň je nutné chránit zaměstnance a návštěvníky. Simulace se zaměřuje na proces evakuace pavilonu šelem při náhlém zvýšení hladiny Vltavy. Výsledky mohou pomoci vedení ZOO lépe se připravit na mimořádné události.

=== Cíl simulace ===
Simulace se bude věnovat otázce: Jak rychle a efektivně lze evakuovat šelmy z ohroženého pavilonu v případě povodně?
Výsledkem bude návrh optimální evakuační strategie v závislosti na různých faktorech (např. počet ošetřovatelů, kooperace zvířat, čas do zaplavení, atd.). Některá zvířata jsou více nebezpečná jiná jsou klidná.

=== Použití simulace ===
Simulace může sloužit:
*Zaměstnancům ZOO, kteří se chtějí připravit na krizové situace
*Studentům, kteří se učí o ochraně zvířat nebo krizovém řízení
*Veřejnosti, která si chce udělat představu, jak taková situace vypadá a proč je důležitá příprava

=== Použitá metoda a prostředí ===
Multiagentní simulace v NetLogo, kde agenti budou zvířata, zaměstnanci (ošetřovatelé) a povodeň. Zvířata mají různé chování, velikost, agresivitu. Ošetřovatelé jsou zkušení, ale i nováčci a je jich různý počet na směnách. Povodeň může mít různé rychlosti. Prostředím je pavilon šelem v pražské ZOO. V pavilonu jsou jednotlivé expozice podle druhu zvířete. V případě, kdy hrozí evakuace jsou všechna zvířata uvnitř pavilonu.

V případě evakuace přijdou chovatelé a evakuují zvířata. Některá musí uspat, jiná ne. Zvířata přesouvají do klecí nebo boxů a převážejí pryč cestou podle zatopení. U každého zvířete je dohledatelný

=== Proměnné ===
Definované předem:
* Počet zvířat v pavilonu, jejich velikost a druhy
* Počet evakuačních cest
* Rychlost záplav (kolik času je na evakuaci)
* Počet ošetřovatelů a jejich zkušenosti (můžou být zkušení nebo nováčci, nováčci jsou pomalejší a mají vyšší pravděpodobnost minout uspávací šipkou)

Náhodné:
* kooperace zvířete (může být klidné nebo agresivní)
* rozmístění ošetřovatelů
* minutí uspávací šipkou
* rozbitá klec

=== Data ===
* výroční zprávy ZOO Praha [https://www.zoopraha.cz/vse-o-zoo/vyrocni-zpravy]
* mapa ZOO Praha (obrázková) [https://www.zoopraha.cz/navsteva/30-mapa-zoo-praha]
* mapa ZOO Praha [https://g.co/kgs/aXs5ceF]
* přiklad info o zvířeti ZOO Praha [https://www.zoopraha.cz/aktualne/pohledem-reditele/14972-jak-se-v-zoo-praha-chystame-na-povodne]
* převoz tygrů [https://www.jamescargo.com/blog/tiger-transport.php?utm_source=chatgpt.com]
* CITES transport guidelines [https://cites.org/eng/resources/transport/advice.shtml?utm_source=chatgpt.com]

=== Simulant ===
Veronika Smrčková
[[User:smrv03|smrv03]] ([[User talk:smrv03|talk]]) 11:36, 12 May 2025 (CET)

: '''Schváleno.''' [[User:Tomáš|Tomáš]] ([[User talk:Tomáš|talk]]) 08:42, 15 May 2025 (CET)

== Simulace: Strategie hráčů ve hře v kostky dle pravidel hry Farkle ==

=== Popis problému ===
Cílem simulace je analyzovat a porovnat různé herní strategie ve hře Farkle (hazardní kostková hra). Dva hráči si během hry střídavě hází kostkami a snaží se získat co nejvíce bodů pomocí specifických kombinací (např. trojic, postupky, šest stejných hodnot apod.). Hráči však musí v každém tahu rozhodnout, zda pokračovat v házení (s rizikem ztráty aktuálního skóre) nebo se zastavit a body si uložit.

Každý hráč je reprezentován jako „persona“ s předdefinovanou strategií rozhodování – od konzervativního po extrémně rizikového přístupu. Tyto odlišné styly chování významně ovlivňují průběh hry, četnost výher i riziko prohry kvůli přehnané hamižnosti.

=== Cíl simulace ===
Cílem simulace je zjistit, jaké herní strategie (persony) jsou nejefektivnější v dosažení výhry ve hře Farkle. Zároveň zohledňuje spravedlnost (oba hráči mají stejný počet tahů) a umožňuje porovnávat strategie mezi sebou při opakovaném hraní stovek her. Výstupem je srovnání úspěšnosti jednotlivých přístupů a doporučení vhodné herní taktiky.

=== Použití simulace ===
Simulace může sloužit:
* jako model rozhodování v nejistém prostředí,
* jako prostředek pro výuku agentového modelování (např. střední školy, informatika, psychologie rozhodování),
* pro zábavné testování, která strategie by přinesla nejvíc výher v reálné hře Farkle,
* jako výchozí kostra pro složitější modely s učením, adaptivními hráči nebo evoluční optimalizací strategie,
* a v neposlední řadě, jako "engine" na testování person pro mou diplomovou práci.

=== Použitá metoda a prostředí ===
Simulace je implementována v prostředí NetLogo jako dvouagentní tahový model. Hráči se střídají v házení 6 kostek, získávají body za kombinace podle pravidel Farkle (např. trojice, čtveřice, pětice, šestice, postupky) a rozhodují se, zda budou pokračovat v tahu.

Model zahrnuje:
* různé herní strategie („persony“) – definované jako rozhodovací pravidla podle skóre, zbývajících kostek nebo náhodného faktoru,
* počítání statistik (výhry, tahy, FARKLE chyby),
* zajištění férovosti – druhý hráč má vždy možnost dokončit poslední tah, pokud první dosáhne vítězného skóre,
* export výsledků a vykreslení průběhu skóre do grafu (a jiné statistické ukazetele).

=== Proměnné ===
Definované předem:
* Cílové skóre pro výhru (např. 10 000)
* Počet simulovaných her (např. 100 až 1000)
* Herní strategie pro oba hráče:
* conservative – ukládá body při ≥400
* risky – ukládá body při ≥700
* greedy – ukládá body při ≥1000
* cautious – hraje opatrně (≥300 nebo málo kostek)
* random – rozhoduje se náhodně
* risk-averse – hraje opatrně jen pokud vede o >2000 bodů, jinak jako conservative
* point-maximizer – pokračuje, dokud nedostane HOT DICE
* combo-hunter – pokračuje po silných kombinacích (postupky, trojice a víc)

Náhodné:
* Hod šesti kostkami (1–6)
* Kombinace, které hráči získají (např. 3 stejné, postupka 1–6 atd.)
* Výsledek rozhodnutí pokračovat/zastavit u náhodné strategie

Možná rozšíření simulace:
* Evoluční vývoj nových strategií (např. pomocí genetického algoritmu)
* Paměť hráčů – učení na základě předchozích neúspěchů
* Reakce na strategii soupeře (adaptivní persona)

=== Data ===
* [https://farkle.games/official-rules/] - oficiální pravidla hry Farkle
* [http://incompleteideas.net/book/the-book-2nd.html] - popis chování osob v pod tlakem a při riskování (persony)
* [https://mud.co.uk/richard/hcds.htm] - rozdělení person a chování v různých karetních a jiných hrách
* [http://incompleteideas.net/book/the-book-2nd.html] - o strategiích rozhodování, výběru akcí, riziku a odměnách

=== Simulant ===
Jan Hlavnička
[[User:hlaj13|hlaj13]] ([[User talk:hlaj13|talk]]) 13:58, 8 May 2025 (CET)

: Moc nadšený z toho tématu nejsem. Většinou tahle hazardní témata zamítáme hlavně z důvodu, že ten výsledek je obvykle bývá poměrně snadno analyticky převídatelný. Tady aspoň pracujete s porovnáváním těch strategií, budiž. Dejte prosím pozor, ať nedojdete ke zcela banálním výsledkům. '''Schváleno'''. [[User:Tomáš|Tomáš]] ([[User talk:Tomáš|talk]]) 08:52, 15 May 2025 (CET)

== Simulace: Simulace tučňáků hledajících lásku na ledové kře 🐧❤️ ==

=== Popis problému ===
Cílem simulace je modelovat chování tučňáků během námluv na ledové kře. Tučňáci musí najít vhodného partnera pro hnízdění, přičemž čelí různým vnějším vlivům – nestabilnímu prostředí (praskající led), konkurenci ostatních tučňáků a hrozbě predátorů (např. lachtani).

Každý tučňák má specifické nastavení chování – někteří jsou spíše plachého typu, jiní jsou odvážní a aktivně oslovují potenciální partnery. Odlišný přístup k seznamování ovlivňuje jejich šanci na úspěšné spárování a přežití do hnízdní sezóny.

=== Cíl simulace ===
Simulace se zaměří na otázku: Jaký „balící styl“ (strategie chování) vede k nejvyšší šanci na nalezení partnera a založení hnízda, a jak tuto šanci ovlivňuje prostředí a přítomnost rizik? Výsledkem bude doporučení nejefektivnějších „láskových taktik“ v závislosti na kontextu (bezpečné vs. nebezpečné prostředí).

=== Použití simulace ===
Simulace může sloužit:
* jako model sociální interakce v zábavné formě,
* jako edukativní nástroj pro představení agentového modelování (např. na středních školách),
* nebo jako metaforické přiblížení seznamovacích strategií ve složitém prostředí.

=== Použitá metoda a prostředí ===
Simulace bude vytvořena v prostředí NetLogo jako multiagentní model, kde každý agent (tučňák) bude reprezentovat jiný typ chování. Prostředí bude ledová kra se zónami různé stability a výskytu predátorů.

Tučňáci budou interagovat podle jednoduchých pravidel: přiblíží se k partnerovi, pokusí se o námluvy (s pravděpodobností úspěchu ovlivněnou vlastnostmi obou), a pak spolu odcházejí hnízdit (zmizí ze scény). Mohou být také ohroženi prasknutím kry nebo útokem predátora.

=== Proměnné ===
Definované předem:
* Počet tučňáků (např. 50–100)
* Stabilita ledu (pravděpodobnost prasknutí při stání na místě)
* Výskyt predátorů (pravděpodobnost útoku při pohybu)
* Rychlost pohybu a reakce

Typ chování:
* Plachý – čeká, až ho někdo osloví
* Odvážný – aktivně balí ostatní
* Kombinovaný – střídá strategie

Náhodné:
* Rozmístění tučňáků
* Výběr preferovaného partnera (náhodně nebo podle vlastností)
* Výsledek námluv (pravděpodobnost úspěchu podle kompatibility + typu chování)
* Prasknutí ledové kry
* Útok predátora

Možná rozšíření simulace:
* Přidání „charakterových“ rysů (krása peří, zpěv, taneční dovednosti)
* Učení – tučňák se poučí z neúspěchu a změní taktiku
* Sezónnost – časový limit na nalezení partnera (jinak simulace končí smutným singl koncem)

=== Data ===
* [https://www.reuters.com/business/environment/emperor-penguins-suffered-mass-breeding-failures-2023-amid-record-low-sea-ice-2024-04-25/ Stabilita mořského ledu a úspěšnost hnízdění
* [https://www.birdsnz.org.nz/wp-content/uploads/2021/12/Rowe_67_etal_451_459.pdf Úspěšnost hnízdění u tučňáků malých
* [https://www.selwomarina.es/en/blog/por-que-pinguinos-regalan-piedras-hembra?utm_.com Selwo Marina Benalmadena] – Článek věnující se námluvám a párování, kde popisují darování kamínků jako součást námluv
* BBC Earth, National Geographic, Attenboroughovy dokumenty – často dobře vysvětlují typy chování, interakce a přežívání. Např. March of the Penguins

=== Simulant ===
Zuzana Plachá
[[User:plaz03|plaz03]] ([[User talk:plaz03|talk]]) 20:20, 7 May 2025 (CET)

: OK, nezapomeňte chování jednotlivých druhů tučńáků, atd. podložit nějakými zdroji. Pozor také na relativně nízké počty. 50 výskytů nějakého jevu je skoro na hranici fungování statistiky. '''Schváleno'''. [[User:Tomáš|Tomáš]] ([[User talk:Tomáš|talk]]) 08:54, 15 May 2025 (CET)

== Simulace: Simulace vojenské patroly a střetu s nepřítelem ==

=== Popis problému ===
Simulace se zabývá chováním malé vojenské jednotky (patroly), která operuje v nepřátelském teritoriu. Cílem patroly je bezpečný průchod zadanou trasou. V oblasti se ovšem mohou nacházet nepřátelské síly, které mají za úkol patrolu odhalit a zlikvidovat. Průběh mise ovlivňuje několik proměnných – velikost jednotky, dosah vidění, typ terénu, schopnost včasné reakce a počet a rozmístění nepřátel. Výsledky simulace umožní analyzovat účinnost různých taktik a rozhodovacích pravidel, které jednotka může použít při plnění mise. Zároveň mohou sloužit jako podpůrný nástroj při plánování operací nebo jako tréninková pomůcka pro rozhodování armády v rizikových situacích.

=== Cíl simulace ===
Simulace se bude věnovat zodpovězení otázky: jak různé faktory (velikost jednotky, rozmístění nepřátel, strategie pohybu) ovlivňují úspěšnost vojenské patroly při průchodu nebezpečným územím? Cílem je nalézt parametry a strategie, které vedou k nejvyšší pravděpodobnosti úspěšného dokončení mise bez ztrát. Výsledkem bude doporučení efektivních taktických rozhodnutí pro minimalizaci rizika při podobných operacích.

=== Použití simulace ===
Simulaci by mohli využít velitelé malých jednotek nebo vojenská akademie pro testování taktik v simulovaných prostředích. Model by jim dokázal vyhodnotit, jak různé strategie a složení jednotky ovlivňují šanci na úspěšné dokončení mise bez ztrát.

=== Použitá metoda a prostředí ===
Multiagentní simulace v NetLogo. Agenti v modelu budou reprezentovat členy vojenské patroly a nepřátelské jednotky. Prostředí bude představovat mapu oblasti s různými typy terénu - otevřený terén, les, kryt apod.

=== Proměnné ===
Definované předem:
* Počet vojáků v patrole
* Počet nepřátel
* Typ terénu (např. podíl lesů, volného prostoru)
* Trasa patroly (předem definovaná nebo generovaná)
* Dosah vidění vojáků i nepřátel
* Pravidla reakce na kontakt (útěk, útok, přivolání podpory)
Pravděpodobnosti střetu a úspěchu jsou založeny na odhadech inspirovaných vojenskými taktickými příručkami a popisech reálných situací v článcích A-Report.

Náhodné:
* Rozmístění nepřátel v terénu
* Zpozorování nepřítele (pravděpodobnost, že jednotka zahlédne protivníka)
* Výsledek střetu (založen na pravděpodobnosti úspěchu v boji)
* Chování nepřítele (např. zda se ukryje nebo přepadne)

=== Data ===
* [https://mocr.mo.gov.cz/assets/informacni-servis/povinne-informace/1-uredni-deska/zakon-106/odp/priloha-c--1-1_25.pdf Základní řád ozbrojených sil České republiky] – řád armády ČR
* [https://mocr.mo.gov.cz/assets/multimedia-a-knihovna/casopisy/a-report/ar9_2018.pdf Časopis A-Report Útoku se nedalo zabránit] – Úryvek ze článku věnovaný osudové chybě v boji na Balkáně
* [https://mocr.mo.gov.cz/assets/multimedia-a-knihovna/casopisy/a-report/ar10_2019.pdf Časopis A-Report Pod ostrou palbou] – Úryvek ze článku popisující možnost simulací ve vojenském prostředí
* Vlastní odhady založené na realistických parametrech (např. efektivní dostřel, rychlost pohybu v terénu)

=== Simulant ===
Alexandr Sekera
[[User:seka01|seka01]] ([[User talk:seka01|talk]]) 15:33, 7 May 2025 (CET)

: OK, může být. Dejte si pozor na dobré odzdrojování dat, se kterými pracujete. '''Schváleno'''. [[User:Tomáš|Tomáš]] ([[User talk:Tomáš|talk]]) 08:57, 15 May 2025 (CET)

== Simulace: Kontrola jízdenek v MHD ==
=== Popis problému ===
Simulace se zabývá procesem kontrol jízdenek ve veřejné dopravě (např. v systému MHD v Praze). Veřejná doprava je financována částečně z příjmů z jízdného. Cestování "načerno" představuje pro dopravní podnik zdroj ztrát. Proto revizoři od podniku provádějí kontroly platnosti jízdních dokladů. Z toho vyplývá otázka, jak často a jakým způsobem mají být dané kontroly prováděny, aby byly efektivní a ekonomicky dávaly smysl. Výsledky simulace umožní řízení MHD optimalizovat frekvenci kontrol, počet revizorů a tím zvýšit celkovou efektivitu inspekcí.

=== Cíl simulace ===
Simulace se bude věnovat zodpovězení otázky: jak ovlivňuje četnost kontrol objem vybraných pokut ve veřejné dopravě? Výsledkem bude doporučení efektivních inspekčních strategií pro maximalizaci vybraných pokut. Simulace také ukáže, kolik revizorů je potřeba pro dosažení požadované míry kontroly.

=== Použitá metoda a prostředí ===
Multiagentní simulace v Netlogo. Agenti v modelu budou reprezentovat pasažéry a revizory.

=== Proměnné ===
Definované předem:
* Počet cestujících (celkově)
* Počet revizorů
* Výše pokuty (standardní nebo menší za platbu okamžitě)
* Frekvence kontrol (počet provedených kontrol za minutu/hodinu)
* Kapacita vozidla (počet cestujících z celkového čísla, kteří jsou aktuálně v kontrolovaném prostoru)

Náhodné:
* Platnost jízdenky (zda jede pasažér "načerno")
* Zachycení černého pasažéra (zda je neplatnost jízdenky odhalena)
* Zaplacení pokuty (hned či později)

=== Data ===
[https://www.dpp.cz/jizdne/pokuty-revizori/vyse-prirazky DPP - pokuty a revizoři] - výše jednotlivých pokut

[https://www.dpp.cz/vozovy-park DPP - vozový park] - kapacity vozidel

[https://www.expats.cz/czech-news/article/prague-public-transport-inspectors-handed-out-250-000-fines-last-year Prague public transport inspectors handed out 250,000 fines last year] - počty kontrol, pasažérů a revizorů, celková výše pokut, zaplacení pokut

Míra cestování "načerno" pro Prahu není zveřejněna oficiálně. Pro odhad poměru černých pasažérů se lze inspirovat jinými státy ([https://theweek.com/transport/fare-dodging-londons-transport-blight UK], [https://www.trainsfare.eu/tackling-fare-evasion-in-bergamo-a-growing-challenge-for-atb-and-teb/ IT]).

=== Simulant ===
Vladislav Sanin
[[User:Sanv05|Sanv05]] ([[User talk:Sanv05|talk]]) 21:15, 6 May 2025 (CET)

: Není mi úplně jasné, jak to chcete modelovat? Půjde o pasažery přímo ve vozech? Nebo budete mít nějaký model nějaké stanice s rozmístěním revizorů nebo celé sítě MHD? Zkuste to prosím upřesnit, klidně doplňte obrázek. Taková úloha se totiž dá vypracovat řadou způsobů. Některé by byly vyloženě banální, jiné by mohly být zajímavé. [[User:Tomáš|Tomáš]] ([[User talk:Tomáš|talk]]) 09:01, 15 May 2025 (CET)

:: Představuju si to tak, že to bude jeden vůz (vyznačený prostor), kam nastoupí noví pasažéři, část ze kterých jede bez jízdenky. Během jízdy mezi zastávkami (tedy dokud nemohou vystoupit) mohou být kontrolovány revizorem, kontrola taky zabere nějaký čas. Na konci jedné jízdy (po uplynutí fixního počtů ticků, které budou reflektovat délku jízdy - tak, aby to souviselo s počtem proveditelných kontrol, tyto informace lze odvodit ze stránek PID) pasažéři vystoupí a noví nastoupí. [[User:Sanv05|Sanv05]] ([[User talk:Sanv05|talk]]) 20:39, 15 May 2025 (CET)

== Simulace: Pavlovovo podmiňování v agentním modelu ==
=== Co budu simulovat ===
Simulace bude modelovat proces klasického (Pavlovova) podmiňování, kdy agent (představující psa) postupně spojuje neutrální podnět (zvonek) s přirozeným podnětem (jídlo). Výsledkem je, že agent začne reagovat podmíněnou reakcí (slinění) i v případě, že se později objeví pouze zvonek bez jídla.

=== Cíl simulace ===
Cílem simulace je analyzovat průběh učení podmíněné reakce a zjistit:
* kolik opakování je potřeba k vytvoření podmíněné reakce,
* jak stabilní tato reakce je v čase,
* jak rychle dochází k vyhasnutí reakce (extinkci) při absenci posílení,
* jak efektivní je opětovné učení (re-learning) po ztrátě reakce.

Obecně jde o pochopení mechanismů formování návyků a chování založeného na stimulaci a posilování.

=== Kdo by takovou simulaci mohl využít a jak by mu pomohla ===
Simulaci mohou využít například:
* psychologové zabývající se behaviorálním učením,
* učitelé při výuce základních principů behaviorismu,
* vývojáři agentních a AI modelů, kteří chtějí simulovat jednoduché učení nebo formování návyků.

Simulace jim umožní vizuálně a experimentálně sledovat proces klasického podmiňování a analyzovat vliv různých parametrů na průběh učení.

=== Použitá metoda a prostředí ===
* '''Metoda''': Agentní simulace využívající jednoduchý model chování se stavovým automatem. Agent mění svůj vnitřní stav v závislosti na podnětech a historii posilování.
* '''Prostředí''': NetLogo

=== Jaké proměnné budou v simulaci ===
* Počet pokusů o podmiňování
* Zpoždění mezi zvonkem a jídlem (časování podnětů)
* Frekvence posilování (např. 100 %, 75 %, 50 % případů s jídlem)
* Síla podmíněné reakce (vnitřní proměnná zvyšující se učením)
* Počet extinkčních pokusů (zvonek bez jídla)

=== Jaké proměnné budou náhodné ===
* Pravděpodobnost, zda po zvonku následuje jídlo (při částečném posilování)
* Malá náhodná odchylka v chování psa (např. reakční doba, úroveň slinění)

=== Na jakých datech budou proměnné založené ===
* Parametry vycházejí z publikovaných výsledků klasických experimentů Pavlova a dalších behaviorálních studií.
* Typické hodnoty časování a pravděpodobností pro různé typy posilování vychází z odborné literatury.
* Síla reakce bude modelována pomocí logistické funkce, která simuluje typickou křivku učení a vyhasínání reakce.
* [https://www.psychologywizard.net/uploads/2/6/6/4/26640833/pavlov_lecture_18.pdf Pavlov – Lecture 18 (Conditioned Reflexes, 1927)]
* [https://en.wikipedia.org/wiki/Classical_conditioning Wikipedia – Classical Conditioning]
* [https://www.simplypsychology.org/pavlov.html Simply Psychology – Pavlov’s Dogs]

=== Na jakých datech jsou založeny vzorce v simulaci (chování modelu) ===
Chování modelu bude založeno na Rescorla-Wagnerově modelu klasického podmiňování, který kvantifikuje změnu síly asociace mezi podmíněným podnětem a nepodmíněným podnětem během jednotlivých pokusů.
* [https://www.vcalc.com/wiki/rescorla-wagner-formula-alpha-and-beta-version vCalc – Rescorla-Wagner model (alpha and beta version)]
* [https://en.wikipedia.org/wiki/Rescorla%E2%80%93Wagner_model Wikipedia – Rescorla–Wagner model]

=== Simulant ===
[[User:Lans06|Lans06]] ([[User talk:Lans06|talk]]) 22:27, 6 May 2025 (CET)

== Simulace: Bitva u Azincourtu v roce 1415 (Anglie vs Francie během Stoleté války) ==

=== Popis problému ===
V roce 1415 stála Anglie v čele se svým králem Jindřichem V. proti silám Francie, které měly velmi drtivou převahu (Anglie cca 8500 a Francie cca 15 000). I přes tuto nevýhodu dokázala Anglie vyhrát s nepatrnými ztrátami. Dle historických pramenů to bylo především díky strategickému umístění anglického vojska v úzkém prostoru mezi stromy, kde nemohly francouzské jednotky přímo naběhnout a využít drtivou sílu svých počtů bojovníků - musely postavit více řad bojovníků za sebou a nemohly anglické jednotky obklopit.

=== Cíl simulace ===
Simulace se bude věnovat otázce: Měla by Francie šanci vyhrát bitvu, kdyby se bitva odehrávala na širokém prostranství narozdíl od úzkého prostoru? Nebo by stále Anglie dokázala vyhrát, kdyby přišla o výhodu okolí?

=== Použití simulace ===
Simulace může sloužit:
* historikům - náhled do historie, kdyby měla bitva jiný průběh
* Úvaha nad historickou událostí, která ovlivnila Stoletou válku

=== Cíl simulace ===
* dokázat, jak terén může ovlivnit průběh bitvy, pokud je stanovena správná strategie
* změní se průběh bitvy a dokáže Francie vyhrát?
* jak moc účinné je zbraň Long Bow (dlouhý luk) v otevřeném terénu?

=== Použitá metoda a prostředí ===
Multiagentní simulace v NetLogo, kde agenti budou jednotky Anglie (pěšáci, střelci s Long Bow) a Francie (pěšáci, kavalérie, střelci s Long Bow, střelci s kuší).

=== Proměnné v simulaci ===
Definované předem:
* počet a rozložení jednotek anglické armády
* počet a rozložení jednotek francouzské armády

Náhodné
* pohyb jednotek (každá jednotka má své reakce a možnosti pohybu)
* střelba z Long Bow - kolik zvládne vystřelit šípů za určitý čas

=== Data ===
* https://www.stoplusjednicka.cz/bitva-u-azincourtu-stret-ktery-rozhodl-nekonecnou-valku-mezi-anglii-francii
* https://zoom.iprima.cz/historie/bitva-u-azincourtu
* vlastní poznatky z rekonstrukcí bitev

=== Simulant ===
[[User:Bilk08|Bilk08]] ([[User talk:Bilk08|talk]]) 12:00, 12 May 2025 (CET)

== Simulace: Phishing na hybridním pracovišti ==

=== Popis problému ===
Práce bude zkoumat roli hybridního (onsite & remote) pracoviště na pravděpodobnsot úspěšného phishing útoku.
Remote zaměstnanci méně komunikují, než jejich onsite kolegové, což snižuje pravděpodobnost, že o podezřelém emailu někomu řeknou nebo u stolu jen prohlásí "to je divný" nebo "taky jsi dostal tenhle trenink do zitra?".
Simulace bude uvažovat, že ne každý zaměstnanec má přístup ke kritickým systémům, jen někteří mohou způsobit firmě vážné škody, ale pokud se tak stane, následky jsou velké.

=== Cíl simulace ===
Simulace má za cíl zjistit, jaké budou škody s různými konfiguracemi onsite vs. remote zaměstnanců.

=== Kdo by takovou simulaci mohl využít a jak by mu pomohla ===
Jakákoli korporát/firma s kombinací onsite a remote zaměstnanců (populární po pandemii)

=== Použitá metoda a prostředí ===
*Metoda: Multi-agentní simulace
*Prostředí: NetLogo

=== Jaké proměnné budou v simulaci ===
*Deterministické:
**Socializace (např. oběd)
**Délka sprintu (ke konci sprintu klesá pozornost, roste zbrklost)
**Počet zaměstnanců s kritickými přístupy
**Počet onsite zaměstnanců
**Počet remote zamšstnanců
**Intervaly mezi interními phishing testy IT oddělení

*Náhodné:
**Četnost phishing útoků
**Základní pravděpodobnost naletění na phishing
**Pravděpodobnost naletění po školení (efekt se bude s časem od školení snižovat)
**Pravděpodobnost naletění po úspěšném útoku
**Remote & onsite pravděpodobnost komunikace (při odhalení phishingu)
**Ztráta způsobená úspěšným phishingovým útokem bez kritických přístupů
**Ztráta způsobená úspěšným phishingovým útokem s kritickými přístupy

=== Data ===
*Vědecké články (např. psychologické studie na efekt o interních phishing testech, jak zvyšuje pracovní nápor pravděpodobnost naletění)
*Phishingové statistiky (např. četnost, úspěšnost, severita)

=== Simulant ===
[[User:Lebm05|Lebm05]] ([[User talk:Lebm05|talk]]) 12:59, 12 May 2025 (CET)

== Simulace: Obsazenost akutních lůžek v českých nemocnicích ==

=== Popis problému ===
České nemocnice disponují v průměru 4,6 akutními lůžky na 1 000 obyvatel. Při průměrné ošetřovací době, která teď činí 5,5 dne, dochází k fluktuacím mezi novými přijetími pacientů, obsazeným počtem lůžek a propouštěním pacientů. Při obsazenosti vyšší než 85 %, kvalita péče klesá, prodlužují se čekací doby a zvyšuje se riziko komplikací a nozokomiálních infekcí.

Simulace bude odhadovat vývoj obsazenosti akutních lůžek v čase a vyhodnotí dopad různých intervencí (zkrácení průměrné ošetřovací doby, navýšení kapacity, řízení fronty).

Výsledky simulace ukážou, která opatření nejvíce snižují riziko dlouhodobé obsazenosti nad 85 %, kdy už dochází k prodlužování čekacích dob a nárůstu infekcí; také mohou sloužit jako podpora rozhodování o investicích a rozdělení rozpočtu.

=== Cíl simulace ===
Cílem simulace je zodpovědět na otázku, do jaké míry a jak rychle udržení obsazenosti pod 85 % ovlivní faktory jako:
* Snížení průměrné ošetřovací doby o 10 %
* Navýšení kapacity o 10 %
* Řízená fronta (prioritizace)
Ve všech scénářích budu sledovat průměrnou denní obsazenost lůžek, maximální délku fronty, a čas, za který obsazenost překročí nebo zůstane pod hranicí 85 %.

=== Použití simulace ===
Kdo může simulaci použít?
Simulace umožní vedení zdravotnických zařízení a manažérům identifikovat dlouhodobé rizikové body v lůžkové kapacitě a následně je mohou využít k optimalizaci strategických investic tak, aby udrželi kontinuitu péče a finanční udržitelnost i při demografických změnách či neočekávaných vlnách poptávky. Díky simulaci mohou předem ověřit dopad různých politik (např. zkrácení průměrné ošetřovací doby, rozšíření kapacity, prioritizace příjmu) a na základě toho nastavit robustní krizové plány a alokaci zdrojů.

=== Použitá metoda a prostředí ===
Pro tvorbu simulace využit přístup Systémové dynamiky a nástroj Vensim PLE.

=== Proměnné ===
* Počet obyvatel
* Počet hospitalizovaných pacientů (akutní lůžka)
* Počet nově hospitalizovaných pacientů
* Počet propuštěných pacientů
* Průměrná délka hospitalizace
* Míra propuštění
* Průměrné denní množství nových žádostí o hospitalizaci
* Míra hospitalizace
* Celkový počet akutních lůžek
* Míra navýšení kapacity při obsazenosti větší než 85 %
* Počet volných lůžek
* Obsazenost lůžek

=== Data ===
* Počet obyvatel v ČR. [https://vdb.czso.cz/vdbvo2/faces/cs/index.jsf?page=vystup-objekt&pvo=DEM13&z=T&f=TABULKA&skupId=3829&katalog=33155&pvo=DEM13&evo=v141_!_IK-CR-K_1&c=v3~8__RP2021]
* Zdravotní péče České republiky. [https://csu.gov.cz/zdravotni-pece#:~:text=2016%202017%202018%202019%202020,548%209%20960%209%20996]
* Zdravotnická ročenka České republiky. [https://www.uzis.cz/index.php?pg=aktuality&aid=8560]
* Hospitalizace v nemocnicích ČR. [https://www.uzis.cz/index.php?pg=vystupy--vyznamna-temata--hospitalizace ]
* Pohyb obyvatelstva - rok 2021. [https://csu.gov.cz/rychle-informace/pohyb-obyvatelstva-rok-2021#:~:text=Podle%20výsledků%20sčítání%20lidu%2C%20domů,Štyglerová%2C%20vedoucí%20oddělení%20demografické%20statistiky]

=== Simulant ===
[[User:Kozo01|Olesia Kozlova (kozo01)]] ([[User talk:kozo01|talk]]) 16:07, 12 May 2025 (CET)

:: '''Schváleno'''[[User:Oleg.Svatos|Oleg.Svatos]] ([[User talk:Oleg.Svatos|talk]]) 20:45, 12 May 2025 (CET)

== Simulace: Eutrofizace vodní plochy ==

=== Popis problému ===
Eutrofizace vodních ploch je přírodní jev, který může být výrazně ovlivněn antropogenní činností. Jedná se zejména o jednotlivé chemické pochody, které způsobují nárůst biomasy na hladině vodní plochy. Díky tomuto růstu dochází k postupnému snižování světelných podmínek pod úrovní hladiny, což způsobuje úhyn biomasy a dochází k zvýšení rozkladných procesů, které zapříčiňují úbytek kyslíku v celé vodní nádrži. Následkem toho dochází i k úhynu vodních živočichů závislých na koncentraci kyslíku pod hladinou.

=== Cíl simulace ===
Cílem simulace je namodelovat celý proces eutrofizace, který bude ovlivněn antropogenní činností (např. splachy z polí). Zodpoví jednu z důležitých otázek: Jak antropogenní činnost urychluje eutrofizaci.

=== Použití simulace ===
* Simulace může být využita k akademickému studiu eutrofizace,
* jako podpora při legislativních rozhodnutí,
* může vylepšit strategické plánování ve vodohospodářských organizacích, nebo
* strategické plánování zemědělců.

=== Použitá metoda a prostředí ===
* Simulace využívá program Vensim, který byl vybrán na základě jeho schopnosti namodelovat toky a vazby mezi jednotlivými proměnnými ve sledovaném prostředí.

=== Proměnné ===
* Definované předem:
** úroveň eutrofizace,
** počáteční množství biomasy,
** počáteční množství živočichů,
** počáteční pH vody,
** počáteční obsah kyslíku.

* Náhodné:
** počasí,
** zalévání zemědělských ploch.

Popřípadě další.

=== Data ===
* YANG, Xiao-e, Xiang WU, Hu-lin HAO a Zhen-li HE, 2008. Mechanisms and assessment of water eutrophication. Journal of Zhejiang University. Science. B [online]. 9(3), 197–209. ISSN 1673-1581. Dostupné z: doi:[https://doi.org/10.1631/jzus.B0710626 10.1631/jzus.B0710626]

=== Simulant ===
[[User:bene08|Eliška Benešová (bene08)]] ([[User talk:bene08|talk]]) 16:07, 12 May 2025 (CET)

:: '''Schváleno''' [[User:Oleg.Svatos|Oleg.Svatos]] ([[User talk:Oleg.Svatos|talk]]) 20:50, 12 May 2025 (CET)

== Simulace: Simulace průchodu cestujících pasovou kontrolou na letišti ==

=== Popis problému ===
Letiště v době dopravní špičky čelí problémům s kapacitou pasové kontroly. Nedostatečný počet otevřených přepážek vede k dlouhým frontám a nespokojenosti cestujících. Naopak příliš mnoho otevřených přepážek může znamenat neefektivní využití personálu. Proto je potřeba najít rovnováhu mezi těmito dvěma faktory.

=== Cíl simulace ===
Cílem simulace je analyzovat vliv počtu otevřených přepážek na délku fronty a maximální čekací dobu cestujících. Jedním z hlavních cílů je identifikovat maximální čekací dobu v případech, kdy nejsou otevřeny všechny dostupné přepážky, a navrhnout optimální počet přepážek pro různé scénáře zatížení.

=== Použití simulace ===
Simulaci může využít letištní management, konkrétně vedoucí směny nebo plánovači personálu, kteří rozhodují o počtu aktivních pracovníků v jednotlivých časových intervalech. Pomůže jim lépe plánovat směny a optimalizovat provoz pasové kontroly tak, aby se předešlo zbytečným zpožděním i plýtvání lidskými zdroji.

=== Použitá metoda a prostředí ===
Použiji agentní simulaci v jazyce Rust, s využitím open-source herního enginu Bevy (verze 0.13) jako vizuálního a simulačního prostředí. Každý cestující bude modelován jako agent, který dorazí, čeká ve frontě, a je odbaven u přepážky podle pravidel fronty (FIFO). Přepážky budou reprezentovány jako paralelní servery.

=== Proměnné ===

Deterministické proměnné:

*Počet otevřených přepážek
*Reálný rozvrh příletů letadel
*Počet cestujících vystupujících z každého příletu (interval 5 minut)

Náhodné proměnné:

*Interval mezi příchody cestujících (exponenciální rozdělení)
*Doba odbavení u přepážky (normální rozdělení)
*Rychlost přechodu cestujících od gate k pasové kontrole

Měřené výstupy:

*Průměrná čekací doba
*Maximální čekací doba
*Využití jednotlivých přepážek v %
*Délka fronty v čase

=== Data ===

Průměrná doba odbavení: Na základě interních dat z provozu pasové kontroly letiště.

Intenzita příchozích cestujících: Data získáná z každodenního leteckého provozu mimo sezónu a v sezóně (červen - září)

=== Simulant ===
[[User:Papd01|Papd01]] ([[User talk:Papd01|talk]]) 17:25, 12 May 2025 (CET)

== Simulace: Autobusová linka v městské dopravě ==

=== Popis problému ===
Simulace se zabývá provozem autobusové linky v městské dopravě. Veřejná doprava je klíčová pro fungování měst a efektivní provoz autobusových linek zajišťuje dostupnost a komfort pro cestující. V praxi dochází k problémům, jako je přetížení spojů během špičky, zpoždění, dlouhé čekací doby na zastávkách nebo nevyužité kapacity mimo špičku. Simulace umožní analyzovat, jak různé faktory (například počet autobusů, intervaly mezi spoji, kapacita vozidel nebo rozložení cestujících během dne) ovlivňují kvalitu přepravy a vytížení linky. Výsledky simulace mohou pomoci dopravcům optimalizovat jízdní řády a nasazení vozidel.

=== Cíl simulace ===
Cílem simulace je zjistit, jak různé parametry provozu autobusové linky ovlivňují:
* průměrnou dobu čekání cestujících na zastávce,
* naplněnost autobusů v různých částech trasy a v různých časech,
* identifikaci kritických zastávek s přetížením,
* doporučení pro optimalizaci jízdního řádu a kapacity linky.

=== Použitá metoda a prostředí ===
Multiagentní simulace v NetLogo. Agenty v modelu budou reprezentovat autobusy, cestující a zastávky.

=== Proměnné ===
Definované předem:
* Počet autobusů na lince
* Kapacita jednoho autobusu
* Počet zastávek a jejich rozložení na trase
* Interval mezi odjezdy autobusů
* Délka trasy a čas potřebný k projetí celé linky

Náhodné:
* Počet cestujících přicházejících na jednotlivé zastávky v čase (modeluje špičku/mimo špičku)
* Cílová zastávka každého cestujícího (kde vystupuje)
* Doba nástupu a výstupu cestujících

=== Data ===
* [https://www.dpp.cz/vozovy-park DPP – vozový park] – kapacity autobusů, typy vozidel
* [https://pid.cz/jizdni-rady-podle-linek/ PID – jízdní řády autobusů] – intervaly a rozložení spojů
* [https://www.dpp.cz/spolecnost/o-spolecnosti/dpp-v-datech DPP – statistiky] – počty cestujících, vytížení linek

Pro modelování rozložení cestujících v čase lze vycházet z běžných statistik dopravních podniků nebo využít odhadů podle typu linky (městská, příměstská, školní apod.).

=== Simulant ===
[[User:jelp05|jelp05]] ([[User talk:jelp05|talk]]) 18:35, 12 May 2025 (CET)

== Simulace: Šíření invazních druhů rostlin v krajině ==

=== Popis problému ===
Invazní rostliny představují závažný ekologický problém, který ohrožuje biodiverzitu, mění dynamiku ekosystémů a může způsobovat výrazné ekonomické škody. Přestože existují různé metody jejich potlačení, jejich účinnost se liší podle situace a podmínek v dané oblasti. Vzhledem k tomu, že přímé testování zásahů v reálném prostředí je nákladné a obtížně opakovatelné, bude v této práci navržena simulace, která umožní predikci vývoje a porovnání efektivity různých zásahových strategií.

=== Cíl simulace ===
Simulace bude navržena s cílem modelovat a analyzovat dynamiku šíření vybraných invazních rostlinných druhů v různých typech krajiny. Bude zohledňovat klíčové faktory ovlivňující rozšiřování – jako jsou podmínky prostředí (vlhkost, teplota, typ půdy), biologické vlastnosti rostlin (rychlost růstu, produkce a klíčivost semen) a způsoby šíření (např. pomocí větru, vody nebo lidské činnosti). Součástí modelu bude také testování různých zásahových strategií, jako je mechanická likvidace, aplikace herbicidů nebo jejich kombinace

=== Použití simulace ===
Výsledky simulace poskytnou náhled na chování invazních druhů v čase a prostoru a umožní testovat zásahy bez přímého zásahu do reálného ekosystému. Simulace bude sloužit jako nástroj pro podporu rozhodování v oblasti ochrany přírody, krajinného plánování a managementu invazních druhů. Výstupy bude možné využít například ochranářskými organizacemi nebo správci chráněných území pro návrh efektivních a šetrných zásahových postupů.

=== Použitá metoda a prostředí ===
Prostředí: NetLogo (agentní modelování)

=== Proměnné ===
Deterministické proměnné:
* Biologické vlastnosti rostlin (rychlost růstu, počet a klíčivost semen, vegetační cyklus)
* Podmínky prostředí (vlhkost, teplota, typ půdy)
* Strategické zásahy (mechanické odstraňování, chemická likvidace, kombinace metod)
* Typ krajiny (pole, louka, les, urbanizované prostředí)

Náhodné proměnné:
* Směr a dosah šíření semen
* Počáteční rozmístění rostlin
* Vliv náhodných klimatických odchylek

=== Data ===
Data pro model budou získána z databáze Agentury ochrany přírody a krajiny ČR (https://invaznidruhy.nature.cz), která poskytuje podrobné informace o biologických a ekologických vlastnostech jednotlivých invazních druhů. Další poznatky budou čerpány z odborné literatury a metodických doporučení pro boj s invazními rostlinami.

=== Simulant ===
[[User:kala13|kala13]] ([[User talk:kala13|talk]]) 19:54, 12 May 2025 (CET)

== Simulace: Optimální nacenění zálohy na vratné kelímky na akcích==

=== Popis problému ===
Organizátoři veřejných akcí jako jsou festivaly, koncerty nebo sportovní události, stále častěji přecházejí z jednorázových plastových kelímků na znovupoužitelné, aby snížili ekologickou stopu. Ovšem problém, který nastává při zavedení vratných kelímků na veřejných akcí, je správné nastavení výše zálohy a počet kelímků tak, aby se systém finančně vyplatil, návštěvníci akce jej přijali a zároveň nedošlo k nadbytečným nákladům. Výsledné náklady jsou ovlivňovány mnoho nejistými faktory – kolik lidí kelímek skutečně vrátí a kteří si jej nechají, kolik se jich ztratí nebo kolik nápojů se prodá.

=== Cíl simulace ===
Simulace má za cíl optimalizovat systém vratných kelímků – jaká je optimální výše zálohy vratného kelímku (nebo taky nulová záloha), která minimalizuje ztráty z nevrácených kelímků, ale zároveň neodradí návštěvníka od konzumace.

=== Použití simulace ===
Výsledky simulace poslouží především organizátorům akcí, kteří tak budou moct optimalizovat náklady, lépe rozhodnout o výši záloh a počtu objednaných kelímků.

=== Použitá metoda a prostředí ===
*Metoda: Monte Carlo simulace
*Simulační prostředí: Microsoft Excel

=== Proměnné ===
Deterministické proměnné:
* Počet návštěvníků akce
*Výrobní cena kelímku
*Cena nápoje
*Záloha
Náhodné proměnné:
*Pravděpodobnost vrácení kelímku
*Míra ztracených/poškozených kelímků

=== Data ===
*Ceník kelímků z nabídky různých dodavatelů (https://happycups.co.uk/, https://www.nicknack.cz/ )
*Statistiky vrácení kelímků z článků, statistiky (např. https://www.reuseable.dk/blog/aarhus-residents-have-returned-750-000-reusable-cups-in-one-year, https://www.nicknack.cz/reference-a-klienti/, https://packagingscotland.com/2024/11/pilot-scheme-sees-huge-percentage-of-reusable-cups-returned/ , https://www.reuseable.dk/blog/over-95-000-reuseable-cups-sold-during-festuge )

=== Simulant ===
[[User:Phpham|Phpham]] ([[User talk:Phpham|talk]]) 22:36, 12 May 2025 (CET)
:: Ve zdrojích nevidím data, ze kterých byste mohla odvodit pravděpodobnostní rozdělení pro uváděné náhodné proměnné. Převzetí průměrných veličin pro MC nestačí. [[User:Oleg.Svatos|Oleg.Svatos]] ([[User talk:Oleg.Svatos|talk]]) 07:14, 14 May 2025 (CET)

== Simulace: Vývoj výroby obnovitelné energie v ČR podle dat z roku 2019-2024 ==

=== Popis problému ===
Výroba elektřiny z obnovitelných zdrojů (OZE) v České republice v roce 2019 dosáhla 8 097 GWh. Největší část tvořila biomasa, následovaná vodními a fotovoltaickými elektrárnami. Tyto poměry významně ovlivňují jak energetickou bilanci, tak environmentální cíle. Cílem simulace je analyzovat, jak by se změnila celková výroba z OZE při různých scénářích – například při nárůstu výkonu solárních elektráren o 20 % nebo poklesu vodní výroby kvůli suchu.

=== Cíl simulace ===
Cílem simulace je zodpovědět otázky:
* Jak se změní celková výroba OZE, pokud vzroste výroba z FVE o 20 %?
* Jak pokles výroby z vodních elektráren o 15 % ovlivní celkový objem obnovitelné energie?
* Jaký by byl nový podíl jednotlivých zdrojů na výrobě při těchto změnách?

=== Použití simulace ===
Simulaci mohou využít energetičtí analytici, pracovníci MPO nebo regionální samosprávy jako nástroj pro plánování rozvoje obnovitelných zdrojů. Umožní jim snadno vyhodnotit, jak změny ve výkonu různých OZE typů ovlivní celkovou výrobu energie a pomůže při nastavování cílů nebo investičních priorit.

=== Použitá metoda a prostředí ===
Simulace bude provedena pomocí systémové dynamiky v prostředí Vensim PLE.

=== Proměnné ===
* Výroba elektřiny z OZE celkem (GWh)
* Výroba z biomasy (GWh)
* Výroba z vody (GWh)
* Výroba z fotovoltaiky (GWh)
* Podíl jednotlivých zdrojů (%)
* Změna výkonu zdrojů (%)
* Nová celková výroba (GWh)

=== Data ===
* Bilance elektrické energie – Český statistický úřad ([https://csu.gov.cz/energetika](https://csu.gov.cz/energetika))
* Obnovitelné zdroje energie – Výsledky statistického zjišťování- dokumenty za roky 2019–2024 – Ministerstvo průmyslu a obchodu ČR ([https://mpo.gov.cz](https://mpo.gov.cz))
* Roční zpráva o provozu elektrizační soustavy ČR – Energetický regulační úřad ([https://eru.gov.cz](https://eru.gov.cz))
* Share of energy consumption from renewable sources in Europe – Evropská agentura pro životní prostředí ([https://www.eea.europa.eu/en/analysis](https://www.eea.europa.eu/en/analysis))

=== Simulant ===
[[User:laso00|Oriana Lastovickova (laso00)]] ([[User talk:laso00|talk]]) 6:22, 13 May 2025 (CET)
:: '''Schváleno''' [[User:Oleg.Svatos|Oleg.Svatos]] ([[User talk:Oleg.Svatos|talk]]) 06:30, 14 May 2025 (CET)

== Simulace: Predikce vítěze turnaje v League of Legends ==

=== Popis problému ===
Mid-Season Invitational (MSI) představuje každoroční stěžejní událost světového e-sportu, kde se střetávají nejlepší týmy League of Legends z jednotlivých regionů. Vzhledem k náhodnosti výsledků, různé síle regionů, aktuální formě týmů a pavoukovému systému turnaje je obtížné určit předem, kdo má nejvyšší šanci na výhru.

=== Cíl simulace ===
Cílem této simulace je odhadnout pravděpodobnosti výhry jednotlivých týmů pomocí náhodně generovaných výsledků zápasů na základě historické výkonnosti a aktuálních power rankings.

=== Použití simulace ===
* E-sportová analýza
* Simulace turnaje
* Sázení :)

=== Použitá metoda a prostředí ===
Použitou metodou je Monte Carlo simulace, která umožňuje modelovat nejistotu výsledků jednotlivých zápasů na základě pravděpodobností odvozených z ELO skóre týmů. Pomocí opakovaného náhodného generování výsledků (např. 1 000 simulací) lze odhadnout pravděpodobnosti výhry každého týmu v celém turnaji.

Simulace je realizována v prostředí Microsoft Excel (v české verzi), který poskytuje všechny potřebné nástroje – generování náhodných čísel, výpočty pravděpodobností, podmíněné funkce i vizualizaci výsledků.

=== Proměnné ===
Definované předem:
* Seznam týmů - 10 týmů
* ELO skóre - měřítko síly
* Turnajová struktura

Náhodné:
* Výsledek zápasu - generována jako náhodný výběr podle pravděpodovnosti výhry týmu A vůči B
* Pravděpodnost výhry - spočtena z rozdílu ELO týmu A a týmu B

=== Data ===
* https://oracleselixir.com/
* https://lolesports.com/en-US/gpr/2025
* https://lol.fandom.com/wiki/League_of_Legends_Esports_Wiki

=== Simulant ===
[[User:Hrui00|Hrui00]] ([[User talk:Hrui00|talk]]) 16:21, 13 May 2025 (CET)
:: Krom toho, že tyto simulace dopadají tragicky, tak u těch náhodných proměnných nevidím, jak tam budete odvozovat pravděpodobnostní rozdělení (z čeho a jak), ze kterého budete pak generovat náhodná čísla. Základní pravděpodobnosti, nebo nějaké jejich poměry nejsou MC. Buďto to nějak upřesněte, nebo zkuste něco jiného (byl bych spíš pro tuto variantu). [[User:Oleg.Svatos|Oleg.Svatos]] ([[User talk:Oleg.Svatos|talk]]) 07:25, 14 May 2025 (CET)

Assignment SS 2024/2025/cs

2025-05-06T20:15:18Z

Sanv05: Přidání návrhu simulace - kontrola jízdenek