http://www.simulace.info/api.php?action=feedcontributions&feedformat=atom&user=Tros01Simulace.info - User contributions [en]2026-07-27T16:31:21ZUser contributionsMediaWiki 1.31.1http://www.simulace.info/index.php?title=Populating_the_database&diff=26620Populating the database2025-01-26T22:53:18Z<p>Tros01: /* Discussion */</p>
<hr />
<div>Úvodní odstavec<br />
<br />
=Problem definition=<br />
==Why?==<br />
Lets say that I have a database containing prepared activities and educational content for boy scouts group. Its purpose is to serve as a source of inspiration and eventually of collection of high quality content appropriate for kids during our weekly meetings or other occasions. From which source should be easy to get precisely only the desired results based on defined properties on each activity (eg. time needed for preparation, minimal number of players, etc.)<br />
<br />
BUT actually its currently more like a proof of concept and not a really operational tool. So accordingly there aren't yet any real records to speak about.<br />
This very early stage of development is exactly the reason why I think it is reasonable to think about how will the database be populated with data. As this will be crucial for its future usability and success. Therefore, the simulation should focus on modeling this data population process.<br />
==What?==<br />
To be precise, the simulation will be concerned with user behavior and related volume of stored records.<br />
<br />
It is important to say that user interface for reading is only the default web gui of the database itself (Neo4j), so the users will have to use the Cypher query language. So after they go through such a way to access the records, there better be some decent amount of useful ones in the database. This is because otherwise their whole effort would be pointless and the user would be discouraged from using the database again.<br />
<br />
Creating the records on the other hand will be easy and accessible as much as possible (user writes to google document in specified folder and with specified structure which enables then loading it programmaticaly into the database). This ease of creation is key to encouraging consistent contributions.<br />
<br />
And here comes the question whether this "natural" way of data population is enough, or rather how long will it take for the database to be able to provide satisfactory results for the user in majority of the cases and as such could be called a useful tool. If the time required would be too long, the users could lose interest of even contributing new content .<br />
Therefore, the simulation will model the rate of content creation and the subsequent impact on database searchability and usability.<br />
<br />
Additionally will be also evaluated the "batch population approach" to see weather it is worth considering to implement. This will involve creating a model of user behavior and content creation, simulating different scenarios, and analyzing the results.<br />
==Objectives==<br />
This simulation aims to predict the growth of the database, determine the feasibility of the current data population strategy and evaluate the alternative.<br />
<br />
#Predict the time needed to reach a critical mass of data sufficient for effective use.<br />
#Evaluate the effectiveness of the current data population method relatively to alternative.<br />
<br />
=Method=<br />
==Agent-based model==<br />
The core method used for this simulation is agent-based modeling (ABM). This approach was selected because it aligns well with the nature of the problem, which involves multiple individual users (agents) interacting with a shared environment (the database). Specifically, it enabled me to simulate:<br />
<br />
*Individual User Behaviors: Each agent acts independently, deciding whether to search the database, create a new record, or improve existing ones, based on their local information and probabilities.<br />
*Heterogeneity (Limited): While the agents initially are identical, they change during the simulation based on their interactions with the database.<br />
*Emergent System Behavior: The overall growth and usability of the database is not programmed directly, but emerges from the accumulation of individual actions.<br />
<br />
Alternatively the system dynamics or simple math equations could be used but neither of them would be more fitting for this usecase.<br />
While system dynamics could model the overall growth of the database as a system, it would not provide the same level of detail regarding individual user actions. System dynamics works well when dealing with aggregate levels and rates of change but isn't great for capturing how each agent behaviour individually impacts the system.<br />
<br />
Just as the equations could model a simplified database growth equation, but it would be extremely difficult to derive a model which includes agents success/fail feedback, record improvement and cooldown and thus it was not considered as applicable for this problem.<br />
==Julia==<br />
Because the ABM approach was chosen the NetLogo was concidered as environment for implemantation of the simulation, but also was the language Julia as it is also often used for simulations. In the end the Julia was chosen because of its more general usability and therefore more usecases when learned to use.<br />
<br />
The simulation is implemented in Julia using the Distributions, StatsBase, and Logging packages.<br />
Logging is enabled to output data about records, agents and overall progress of simulation to a log file called simulation.log.<br />
<br />
Plots are used for visualization and stored as *.png files.<br />
<br />
=Model=<br />
<br />
==Entities==<br />
;Database (db):<br />
A dictionary storing Record objects, categorized by integers representing different activity categories.<br />
*The keys of the dictionary are integers representing category id.<br />
*Each category is associated with a vector (array) of Record objects.<br />
*Initially, each category has an empty vector, which can be populated by new records.<br />
<br />
;Record:<br />
A struct containing:<br />
*id (Integer): A unique identifier for the record, auto-incrementing with each creation.<br />
*quality (Float64): Represents the perceived quality or usability of the record. <br />
<br />
(Originally it should more closely resamble the real live improvements by being represented by only range 1-10 as the real live records also can not be improved infinitelly, but in the end there was left simplier implemantation that just has a chance to improve the record during every picked to use event by random value withou top limit.)<br />
<br />
;Agent:<br />
A struct representing a user of the database.<br />
*probabilityToSearch (Float64): The agent's current probability of finding a useful record, it is based on past success of the agent when searching the db. This parameter influences agent's decision whether to search the db or not.<br />
*used (Dict{Int, Vector{Int}}): A dictionary that stores which record IDs have been used by agent and in which week the record has been used, so it won't be used by the same agent during a given cooldown period. Keys are record ids and values are vectors containing week integers in which the record has been used.<br />
<br />
==Variables==<br />
;NUM_AGENTS: <br />
: Integer representing the number of agents (users) participating in the simulation. Value is fixed at 3.<br />
: It is because in our group we have three active leaders for the regular meating.<br />
;BATCH_UPLOAD_SIZES:<br />
: Vector of integers representing different sizes of initial record batches uploaded to the database. The values used in simulation are [0, 10, 30, 50].<br />
: I do not expect to have higher hundreds of the records in the db and I am mainly interested in the begining of the process so here chosen values provide enough info. <br />
;initialQualityDist: <br />
: A lognormal distribution (LogNormal(3, 2)) used to generate the initial quality of new records. The mean is set to 3, and the standard deviation is set to 2, meaning the typical quality of created record will be around 3, but there could be some with higher or lower.<br />
:Because I originally intended to have Records quality kept in range from 1-10 I picked the lognormal distribution with parameters that would result in relatively low to mid quality of records created. Thats reflect better the reality because records can not have high quality without feedback from kids after at least few tries of given activity, which can not be accumulated earlier than after some time, so new records should not have higher initialQuality.<br />
;qualityImprovementProb<br />
: Float64 representing the probability that an agent will improve a record's quality after using it. Value is fixed at 0.7 for the sake of simplicity and simulation feasibility.<br />
: This value was was chosen in hope that leaders will tend to return the favor after using the found record. Also its easier than creating new record, but of course it can not be in all cases so 0.7 seems appropriet.<br />
;recordCreationProb<br />
: Float64 representing the probability that an agent creates a new record when they are preparing an activity and decide not to search the database. Value is fixed at 0.3 for the sake of simplicity and simulation feasibility.<br />
: According to logic applied in qualityImprovementProb here I assume that because the agent didnt found a useful record, he wont be that much interested in investing his time to write down the activity so it could be recorded. And much less when realizing how much pain is to create a quality and useful record.<br />
;categories<br />
: Vector of integer representing the category ids of the db records. The vector is generated as range from 1 to 20, [1:20;].<br />
: Originaly I intended to have categories explicitly named for closer resemblance with reality but I failed to find a real contribution for the simulation, because real live categories are much more comple so this simplified idea is not much realistic to begin with therefore i came to conclusion that using just simple intagers to represent the categories will be better choice for this case.<br />
The original idea was something like this. <br />
const TYPES = ["running", "creative", "thinking", "discussion", "history"] # Types of activities<br />
const PLACES = ["room", "forest", "city", "playground"] # Possible places for activities<br />
const CATEGORIES = [(t, p) for t in TYPES for p in PLACES] # Generate all combinations of types and places<br />
:Using intager instead makes for example much easier change the number of categories, which could be interesting to see how its change influences the observed values.<br />
<br />
<br />
Next three variables limits how long will the simulation run, respectively how long needs the system to be usefull without "fail".<br />
;targetSuccessfulness<br />
: Float64 value, which represents minimum success rate, that needs to be reached for the database to be considered "useful" in a long term. Value is 0.75.<br />
;nSuccessfullFromEpisode<br />
: An integer number representing how many successful searches per episode of the simulation have to occur in order for it to be considered "useful". Value is 4.<br />
;episodeLength<br />
: Integer which represents length of a one "episode" within the simulation, which in this case is a sequence of weeks for which the success rate of the db will be tested if it met required conditions. Value is set to 6, this means 6 weeks.<br />
Such a long time period was chosen based on my requirements, but in the end this choice proved somewhat contraproductive for getting a good results.<br />
<br />
==Flow==<br />
'''1.Initialization:'''<br />
<br />
*The database is created with empty vectors of records for each defined category (integer from 1 to 20).<br />
*A defined number of agents are created with default probabilityToSearch.<br />
*Optionally, a number of initial Record objects will be created (based on parameter BATCH_UPLOAD_SIZE), and randomly assigned to a random category within the database.<br />
<br />
'''2.Weekly Cycle (One Tick):'''<br />
<br />
*Each week (tick), each agent attempts to prepare an activity.<br />
*Each agent selects a random category.<br />
*Then each agent decides whether to search the database based on their current probabilityToSearch (It was originally designed to be able to dynamicaly calculate probabilityToSearch of agents independently, but for the same reason the recordCreationProb is global to all agents, also this variable was left the same for all agents).<br />
<br />
;Search Behavior:<br />
<br />
*If the agent decides to search, it looks up all records that matches it selected category.<br />
*If records are found, the agents samples without replacement a predefined number of records for evaluation. Each has different probability based on its quality. The more quality it has, the higher the probability to be chosen. (Weights are calculated like this [rec.quality / sum(r.quality for r in records) for rec in records])<br />
*An agent tries to pick for use randomly one record from those records. <br />
*Before the agent uses any of the found records, there has to be checked if they haven't been used in a defined "cooldown period", which is set to 54 weeks. Each agent keeps track of used records and the weeks where they where used.<br />
*If the record the agent tries to pick is on cooldown, the agent proceeds to trying another one from the sampled ones until it finds a cooled down one or until there are no more samples (usually in the beginning of the simulation when there are yot not created record in the db).<br />
*If the record is used, there is a probability of the agent improving the quality of that used record.<br />
<br />
;Record Creation Behavior:<br />
<br />
*If the agent decides not to search or if the search is unsuccessful, it has a chance of creating a new record (based on parameter recordCreationProb).<br />
*If a new record is created, it's assigned a randomly generated initial quality based on the lognormal distribution, and pushed to db under it's selected category.<br />
*Also there is kept record of total number oc record created so far during the simulation and the order number of each record is assigned to the record during its creation as its id. This way its possible to keep track of which records were used before by the given agent.<br />
<br />
'''3.Evaluation'''<br />
*Further the simulation tracks total search attempts and successes. The success is considered only when a record is successfully used for an activity and not when a record is found or searched for.<br />
*At the end of each week, a weekly success rate is calculated by dividing the amount of successful record usages by the number of attempts that were performed.<br />
*The simulation continues until the database has reached "sufficient" usability.<br />
*A database is considered as "sufficiently useful" when success rates in a defined episode length (6 weeks) are over a defined threshold (75%) for a given minimum number of successful weeks (4 out of 6). In other words, when this condition is met within a 3 month timeframe.<br />
<br />
==Limitations==<br />
<br />
*Simplified Categories: The categories used in the model are represented by integers and lack any explicit meaning. It was intended to use a combination of string as category representation, but the complexity has no effect on the results, therefore integer representation is used to make code simpler.<br />
*Agent Uniformity: Each agent has an identical recordCreationProb which is not realistic, and does not model different level of contributing to the db.<br />
*Fixed Parameters: Many model parameters, such as qualityImprovementProb, recordCreationProb, NUM_AGENTS are fixed values and don't change during simulation, which makes the simulation a bit static.<br />
*Single Activity Per Week: Each agent prepares only one activity per week, which may be an oversimplification of real user behavior.<br />
*Limited Complexity: The simulation lacks a deeper understanding of how records relate to each other or have a more diverse properties than just an "quality".<br />
<br />
=Results=<br />
In the last section of appended code there was realized an attempt to calculate the results simply by adding new function which whould call the main simulation given number of times and recorded the results so the variability caused by randomness could be viewed. Specifically how the required number of weeks and number of created records varied when running the simulation repeatedly.<br />
<br />
Unfortunately there has been some enexpected and probably undesired patterns occuring in the obtained "multi run" results. Most likely a skillissue on my side. Further elaboration follows.<br />
<br />
Also there is a bug/feature with my function which determines when the search process is successfull enough. Because i require certain amount of time to assess the stability of said successfullness, there is a minimal but fixed timeframe in the begining of the simulation. And because of this when the number of weeks required for the system to be recognized as usefull is measured, its value can not begin earlier than after said timeframe, so that is why the smallest number of weeks in the results are 21.<br />
<br />
Also the counter of created records does not count the records created via batch upload so when reading it needs to be kept in mind.<br />
<br />
Also in the github repository with code, there are plots showing how the successrate evolves in time.<br />
==Single run==<br />
This means runing the multi run function for single iteration.<br />
<br />
But it was run manually three times.<br />
;batch 0 <br />
:weeks until "usefullness": 82, 51, 69<br />
:records created in db: 44, 40, 55<br />
<br />
;batch 10<br />
:weeks: 21, 33, 21<br />
:records: 21, 26, 19 <br />
<br />
;batch 30<br />
:weeks: 24, 21, 22<br />
:records: 26, 17, 18<br />
<br />
;batch 50<br />
:weeks: 21, 21, 21<br />
:records: 30, 18, 27<br />
<br />
It appears that the batch upload in the beginning realy speeds up the time required for the database to be considered usefull, but unfortunately the implementation can not ends earlier then after at least small fixed timeframe.<br />
Its obvious that the results are heavily influenced by the randomness in the model.<br />
<br />
It seems that the first small batch upload has the largest influence on the resulting values and larger batches brings only relatively smaller improvements, that suggests to use the batch upload in real life, but its redundant to focus on optimizing the upload process for larger amounts, because they are not needed and only small amount of records (10) is enough to significantly boost the speed of populating.<br />
<br />
Also the amounts of records additionally created after 50 batch upload seems a bit unexpected, because after results seen in smaller batches one would expect a number around 15 or smaller. If it is not another bug in my code, I would guess that its bacause of small sample of results. batch50[22, 27, 19, 22, 70], batch30[39, 25, 14, 24, 26] are the results obtained by additional runs, its still strange how much records is created in case of 50 batch, but also the cause of small sample is still viable explanation.<br />
<br />
==Multi run==<br />
;batch 0<br />
:weeks: [55, 72, 70, 78, 94, 114, 126, 120, 135, 140, 152, 156, 180, 161, 167]<br />
:records: [32, 129, 108, 195, 262, 316, 320, 308, 366, 373, 432, 442, 496, 486, 487]<br />
<br />
;batch 10<br />
:weeks: [35, 99, 99, 189, 249, 291, 298, 413, 413, 426, 452, 433, 471, 520, 564]<br />
:records: [35, 48, 43, 90, 93, 112, 116, 148, 133, 141, 143, 155, 163, 158, 188]<br />
<br />
;batch 30<br />
:weeks: [21, 67, 79, 105, 99, 97, 115, 132, 137, 149, 160, 158, 170, 178, 181]<br />
:records: [13, 170, 200, 227, 272, 254, 336, 316, 406, 423, 442, 415, 464, 496, 521]<br />
<br />
;batch 50<br />
:weeks: [33, 21, 82, 83, 91, 113, 123, 149, 145, 144, 152, 166, 164, 175, 192]<br />
:records: [58, 42, 187, 247, 271, 306, 331, 365, 397, 413, 468, 502, 495, 507, 540]<br />
<br />
Well, those are here just for fun because there is not much value in such results except for showing something does not work as expected.<br />
<br />
=Discussion=<br />
In this simulation I managed to create heavily simplified model of database populating process in our boy scouts group.<br />
<br />
Therefore the resuls appears to be approximately as they should, but they lack on the reliability if they should be used as a base for a decision.<br />
At most I can take a hint about the amount of records to batch upload. That relatively small amount makes a major difference.<br />
<br />
To further improve the model there should be implemented:<br />
*Chance for agents to "not like the record", that would sometimes stoped the agent from picking a record to use. It could try picking another if there would be more, if not the search would fail. This would be a small improvment to a model realisticity.<br />
*Enhance the feature of records quality so it could not be increased infinitely. <br />
*Add monitoring for values of records quality, so I can see better what is the state of the db like.<br />
<br />
Besides improving the model, the simulation would greatly benefit from basing used probabilities on real live "agents", not on fixed value for everyone.<br />
<br />
=Code=<br />
This is my code on github, because I could not upload .jl file and a did not wanted to make zip: [https://raw.githubusercontent.com/simik394/simulace-populatingskautdb/refs/heads/main/simulace-nobatch.jl]<br />
<br />
And the home repo [https://github.com/simik394/simulace-populatingskautdb]<br />
<br />
[[User:Tros01|Tros01]] ([[User talk:Tros01|talk]]) 22:19, 19 January 2025 (CET)</div>Tros01http://www.simulace.info/index.php?title=Populating_the_database&diff=26619Populating the database2025-01-26T22:47:39Z<p>Tros01: /* Single run */</p>
<hr />
<div>Úvodní odstavec<br />
<br />
=Problem definition=<br />
==Why?==<br />
Lets say that I have a database containing prepared activities and educational content for boy scouts group. Its purpose is to serve as a source of inspiration and eventually of collection of high quality content appropriate for kids during our weekly meetings or other occasions. From which source should be easy to get precisely only the desired results based on defined properties on each activity (eg. time needed for preparation, minimal number of players, etc.)<br />
<br />
BUT actually its currently more like a proof of concept and not a really operational tool. So accordingly there aren't yet any real records to speak about.<br />
This very early stage of development is exactly the reason why I think it is reasonable to think about how will the database be populated with data. As this will be crucial for its future usability and success. Therefore, the simulation should focus on modeling this data population process.<br />
==What?==<br />
To be precise, the simulation will be concerned with user behavior and related volume of stored records.<br />
<br />
It is important to say that user interface for reading is only the default web gui of the database itself (Neo4j), so the users will have to use the Cypher query language. So after they go through such a way to access the records, there better be some decent amount of useful ones in the database. This is because otherwise their whole effort would be pointless and the user would be discouraged from using the database again.<br />
<br />
Creating the records on the other hand will be easy and accessible as much as possible (user writes to google document in specified folder and with specified structure which enables then loading it programmaticaly into the database). This ease of creation is key to encouraging consistent contributions.<br />
<br />
And here comes the question whether this "natural" way of data population is enough, or rather how long will it take for the database to be able to provide satisfactory results for the user in majority of the cases and as such could be called a useful tool. If the time required would be too long, the users could lose interest of even contributing new content .<br />
Therefore, the simulation will model the rate of content creation and the subsequent impact on database searchability and usability.<br />
<br />
Additionally will be also evaluated the "batch population approach" to see weather it is worth considering to implement. This will involve creating a model of user behavior and content creation, simulating different scenarios, and analyzing the results.<br />
==Objectives==<br />
This simulation aims to predict the growth of the database, determine the feasibility of the current data population strategy and evaluate the alternative.<br />
<br />
#Predict the time needed to reach a critical mass of data sufficient for effective use.<br />
#Evaluate the effectiveness of the current data population method relatively to alternative.<br />
<br />
=Method=<br />
==Agent-based model==<br />
The core method used for this simulation is agent-based modeling (ABM). This approach was selected because it aligns well with the nature of the problem, which involves multiple individual users (agents) interacting with a shared environment (the database). Specifically, it enabled me to simulate:<br />
<br />
*Individual User Behaviors: Each agent acts independently, deciding whether to search the database, create a new record, or improve existing ones, based on their local information and probabilities.<br />
*Heterogeneity (Limited): While the agents initially are identical, they change during the simulation based on their interactions with the database.<br />
*Emergent System Behavior: The overall growth and usability of the database is not programmed directly, but emerges from the accumulation of individual actions.<br />
<br />
Alternatively the system dynamics or simple math equations could be used but neither of them would be more fitting for this usecase.<br />
While system dynamics could model the overall growth of the database as a system, it would not provide the same level of detail regarding individual user actions. System dynamics works well when dealing with aggregate levels and rates of change but isn't great for capturing how each agent behaviour individually impacts the system.<br />
<br />
Just as the equations could model a simplified database growth equation, but it would be extremely difficult to derive a model which includes agents success/fail feedback, record improvement and cooldown and thus it was not considered as applicable for this problem.<br />
==Julia==<br />
Because the ABM approach was chosen the NetLogo was concidered as environment for implemantation of the simulation, but also was the language Julia as it is also often used for simulations. In the end the Julia was chosen because of its more general usability and therefore more usecases when learned to use.<br />
<br />
The simulation is implemented in Julia using the Distributions, StatsBase, and Logging packages.<br />
Logging is enabled to output data about records, agents and overall progress of simulation to a log file called simulation.log.<br />
<br />
Plots are used for visualization and stored as *.png files.<br />
<br />
=Model=<br />
<br />
==Entities==<br />
;Database (db):<br />
A dictionary storing Record objects, categorized by integers representing different activity categories.<br />
*The keys of the dictionary are integers representing category id.<br />
*Each category is associated with a vector (array) of Record objects.<br />
*Initially, each category has an empty vector, which can be populated by new records.<br />
<br />
;Record:<br />
A struct containing:<br />
*id (Integer): A unique identifier for the record, auto-incrementing with each creation.<br />
*quality (Float64): Represents the perceived quality or usability of the record. <br />
<br />
(Originally it should more closely resamble the real live improvements by being represented by only range 1-10 as the real live records also can not be improved infinitelly, but in the end there was left simplier implemantation that just has a chance to improve the record during every picked to use event by random value withou top limit.)<br />
<br />
;Agent:<br />
A struct representing a user of the database.<br />
*probabilityToSearch (Float64): The agent's current probability of finding a useful record, it is based on past success of the agent when searching the db. This parameter influences agent's decision whether to search the db or not.<br />
*used (Dict{Int, Vector{Int}}): A dictionary that stores which record IDs have been used by agent and in which week the record has been used, so it won't be used by the same agent during a given cooldown period. Keys are record ids and values are vectors containing week integers in which the record has been used.<br />
<br />
==Variables==<br />
;NUM_AGENTS: <br />
: Integer representing the number of agents (users) participating in the simulation. Value is fixed at 3.<br />
: It is because in our group we have three active leaders for the regular meating.<br />
;BATCH_UPLOAD_SIZES:<br />
: Vector of integers representing different sizes of initial record batches uploaded to the database. The values used in simulation are [0, 10, 30, 50].<br />
: I do not expect to have higher hundreds of the records in the db and I am mainly interested in the begining of the process so here chosen values provide enough info. <br />
;initialQualityDist: <br />
: A lognormal distribution (LogNormal(3, 2)) used to generate the initial quality of new records. The mean is set to 3, and the standard deviation is set to 2, meaning the typical quality of created record will be around 3, but there could be some with higher or lower.<br />
:Because I originally intended to have Records quality kept in range from 1-10 I picked the lognormal distribution with parameters that would result in relatively low to mid quality of records created. Thats reflect better the reality because records can not have high quality without feedback from kids after at least few tries of given activity, which can not be accumulated earlier than after some time, so new records should not have higher initialQuality.<br />
;qualityImprovementProb<br />
: Float64 representing the probability that an agent will improve a record's quality after using it. Value is fixed at 0.7 for the sake of simplicity and simulation feasibility.<br />
: This value was was chosen in hope that leaders will tend to return the favor after using the found record. Also its easier than creating new record, but of course it can not be in all cases so 0.7 seems appropriet.<br />
;recordCreationProb<br />
: Float64 representing the probability that an agent creates a new record when they are preparing an activity and decide not to search the database. Value is fixed at 0.3 for the sake of simplicity and simulation feasibility.<br />
: According to logic applied in qualityImprovementProb here I assume that because the agent didnt found a useful record, he wont be that much interested in investing his time to write down the activity so it could be recorded. And much less when realizing how much pain is to create a quality and useful record.<br />
;categories<br />
: Vector of integer representing the category ids of the db records. The vector is generated as range from 1 to 20, [1:20;].<br />
: Originaly I intended to have categories explicitly named for closer resemblance with reality but I failed to find a real contribution for the simulation, because real live categories are much more comple so this simplified idea is not much realistic to begin with therefore i came to conclusion that using just simple intagers to represent the categories will be better choice for this case.<br />
The original idea was something like this. <br />
const TYPES = ["running", "creative", "thinking", "discussion", "history"] # Types of activities<br />
const PLACES = ["room", "forest", "city", "playground"] # Possible places for activities<br />
const CATEGORIES = [(t, p) for t in TYPES for p in PLACES] # Generate all combinations of types and places<br />
:Using intager instead makes for example much easier change the number of categories, which could be interesting to see how its change influences the observed values.<br />
<br />
<br />
Next three variables limits how long will the simulation run, respectively how long needs the system to be usefull without "fail".<br />
;targetSuccessfulness<br />
: Float64 value, which represents minimum success rate, that needs to be reached for the database to be considered "useful" in a long term. Value is 0.75.<br />
;nSuccessfullFromEpisode<br />
: An integer number representing how many successful searches per episode of the simulation have to occur in order for it to be considered "useful". Value is 4.<br />
;episodeLength<br />
: Integer which represents length of a one "episode" within the simulation, which in this case is a sequence of weeks for which the success rate of the db will be tested if it met required conditions. Value is set to 6, this means 6 weeks.<br />
Such a long time period was chosen based on my requirements, but in the end this choice proved somewhat contraproductive for getting a good results.<br />
<br />
==Flow==<br />
'''1.Initialization:'''<br />
<br />
*The database is created with empty vectors of records for each defined category (integer from 1 to 20).<br />
*A defined number of agents are created with default probabilityToSearch.<br />
*Optionally, a number of initial Record objects will be created (based on parameter BATCH_UPLOAD_SIZE), and randomly assigned to a random category within the database.<br />
<br />
'''2.Weekly Cycle (One Tick):'''<br />
<br />
*Each week (tick), each agent attempts to prepare an activity.<br />
*Each agent selects a random category.<br />
*Then each agent decides whether to search the database based on their current probabilityToSearch (It was originally designed to be able to dynamicaly calculate probabilityToSearch of agents independently, but for the same reason the recordCreationProb is global to all agents, also this variable was left the same for all agents).<br />
<br />
;Search Behavior:<br />
<br />
*If the agent decides to search, it looks up all records that matches it selected category.<br />
*If records are found, the agents samples without replacement a predefined number of records for evaluation. Each has different probability based on its quality. The more quality it has, the higher the probability to be chosen. (Weights are calculated like this [rec.quality / sum(r.quality for r in records) for rec in records])<br />
*An agent tries to pick for use randomly one record from those records. <br />
*Before the agent uses any of the found records, there has to be checked if they haven't been used in a defined "cooldown period", which is set to 54 weeks. Each agent keeps track of used records and the weeks where they where used.<br />
*If the record the agent tries to pick is on cooldown, the agent proceeds to trying another one from the sampled ones until it finds a cooled down one or until there are no more samples (usually in the beginning of the simulation when there are yot not created record in the db).<br />
*If the record is used, there is a probability of the agent improving the quality of that used record.<br />
<br />
;Record Creation Behavior:<br />
<br />
*If the agent decides not to search or if the search is unsuccessful, it has a chance of creating a new record (based on parameter recordCreationProb).<br />
*If a new record is created, it's assigned a randomly generated initial quality based on the lognormal distribution, and pushed to db under it's selected category.<br />
*Also there is kept record of total number oc record created so far during the simulation and the order number of each record is assigned to the record during its creation as its id. This way its possible to keep track of which records were used before by the given agent.<br />
<br />
'''3.Evaluation'''<br />
*Further the simulation tracks total search attempts and successes. The success is considered only when a record is successfully used for an activity and not when a record is found or searched for.<br />
*At the end of each week, a weekly success rate is calculated by dividing the amount of successful record usages by the number of attempts that were performed.<br />
*The simulation continues until the database has reached "sufficient" usability.<br />
*A database is considered as "sufficiently useful" when success rates in a defined episode length (6 weeks) are over a defined threshold (75%) for a given minimum number of successful weeks (4 out of 6). In other words, when this condition is met within a 3 month timeframe.<br />
<br />
==Limitations==<br />
<br />
*Simplified Categories: The categories used in the model are represented by integers and lack any explicit meaning. It was intended to use a combination of string as category representation, but the complexity has no effect on the results, therefore integer representation is used to make code simpler.<br />
*Agent Uniformity: Each agent has an identical recordCreationProb which is not realistic, and does not model different level of contributing to the db.<br />
*Fixed Parameters: Many model parameters, such as qualityImprovementProb, recordCreationProb, NUM_AGENTS are fixed values and don't change during simulation, which makes the simulation a bit static.<br />
*Single Activity Per Week: Each agent prepares only one activity per week, which may be an oversimplification of real user behavior.<br />
*Limited Complexity: The simulation lacks a deeper understanding of how records relate to each other or have a more diverse properties than just an "quality".<br />
<br />
=Results=<br />
In the last section of appended code there was realized an attempt to calculate the results simply by adding new function which whould call the main simulation given number of times and recorded the results so the variability caused by randomness could be viewed. Specifically how the required number of weeks and number of created records varied when running the simulation repeatedly.<br />
<br />
Unfortunately there has been some enexpected and probably undesired patterns occuring in the obtained "multi run" results. Most likely a skillissue on my side. Further elaboration follows.<br />
<br />
Also there is a bug/feature with my function which determines when the search process is successfull enough. Because i require certain amount of time to assess the stability of said successfullness, there is a minimal but fixed timeframe in the begining of the simulation. And because of this when the number of weeks required for the system to be recognized as usefull is measured, its value can not begin earlier than after said timeframe, so that is why the smallest number of weeks in the results are 21.<br />
<br />
Also the counter of created records does not count the records created via batch upload so when reading it needs to be kept in mind.<br />
<br />
Also in the github repository with code, there are plots showing how the successrate evolves in time.<br />
==Single run==<br />
This means runing the multi run function for single iteration.<br />
<br />
But it was run manually three times.<br />
;batch 0 <br />
:weeks until "usefullness": 82, 51, 69<br />
:records created in db: 44, 40, 55<br />
<br />
;batch 10<br />
:weeks: 21, 33, 21<br />
:records: 21, 26, 19 <br />
<br />
;batch 30<br />
:weeks: 24, 21, 22<br />
:records: 26, 17, 18<br />
<br />
;batch 50<br />
:weeks: 21, 21, 21<br />
:records: 30, 18, 27<br />
<br />
It appears that the batch upload in the beginning realy speeds up the time required for the database to be considered usefull, but unfortunately the implementation can not ends earlier then after at least small fixed timeframe.<br />
Its obvious that the results are heavily influenced by the randomness in the model.<br />
<br />
It seems that the first small batch upload has the largest influence on the resulting values and larger batches brings only relatively smaller improvements, that suggests to use the batch upload in real life, but its redundant to focus on optimizing the upload process for larger amounts, because they are not needed and only small amount of records (10) is enough to significantly boost the speed of populating.<br />
<br />
Also the amounts of records additionally created after 50 batch upload seems a bit unexpected, because after results seen in smaller batches one would expect a number around 15 or smaller. If it is not another bug in my code, I would guess that its bacause of small sample of results. batch50[22, 27, 19, 22, 70], batch30[39, 25, 14, 24, 26] are the results obtained by additional runs, its still strange how much records is created in case of 50 batch, but also the cause of small sample is still viable explanation.<br />
<br />
==Multi run==<br />
;batch 0<br />
:weeks: [55, 72, 70, 78, 94, 114, 126, 120, 135, 140, 152, 156, 180, 161, 167]<br />
:records: [32, 129, 108, 195, 262, 316, 320, 308, 366, 373, 432, 442, 496, 486, 487]<br />
<br />
;batch 10<br />
:weeks: [35, 99, 99, 189, 249, 291, 298, 413, 413, 426, 452, 433, 471, 520, 564]<br />
:records: [35, 48, 43, 90, 93, 112, 116, 148, 133, 141, 143, 155, 163, 158, 188]<br />
<br />
;batch 30<br />
:weeks: [21, 67, 79, 105, 99, 97, 115, 132, 137, 149, 160, 158, 170, 178, 181]<br />
:records: [13, 170, 200, 227, 272, 254, 336, 316, 406, 423, 442, 415, 464, 496, 521]<br />
<br />
;batch 50<br />
:weeks: [33, 21, 82, 83, 91, 113, 123, 149, 145, 144, 152, 166, 164, 175, 192]<br />
:records: [58, 42, 187, 247, 271, 306, 331, 365, 397, 413, 468, 502, 495, 507, 540]<br />
<br />
Well, those are here just for fun because there is not much value in such results except for showing something does not work as expected.<br />
<br />
=Discussion=<br />
In this simulation I managed to create heavily simplified model of database populating process in our boy scouts group.<br />
<br />
Therefore the resuls appears to be approximately as they should, but they lack on the reliability if they should be used as a base for a decision.<br />
At most I can take a hint about the amount of records to batch upload. That relatively small amount makes a major difference.<br />
<br />
To further improve the model there should be implemented:<br />
*Chance for agents to "not like the record", that would sometimes stoped the agent from picking a record to use. It could try picking another if there would be more, if not the search would fail. This would be a small improvment to a model realisticity.<br />
*Enhance the feature of records quality so it could not be increased infinitely. <br />
*Add monitoring for values of records quality, so I can see better what is the state of the db like.<br />
<br />
=Code=<br />
This is my code on github, because I could not upload .jl file and a did not wanted to make zip: [https://raw.githubusercontent.com/simik394/simulace-populatingskautdb/refs/heads/main/simulace-nobatch.jl]<br />
<br />
And the home repo [https://github.com/simik394/simulace-populatingskautdb]<br />
<br />
[[User:Tros01|Tros01]] ([[User talk:Tros01|talk]]) 22:19, 19 January 2025 (CET)</div>Tros01http://www.simulace.info/index.php?title=Populating_the_database&diff=26618Populating the database2025-01-26T22:34:51Z<p>Tros01: /* Single run */</p>
<hr />
<div>Úvodní odstavec<br />
<br />
=Problem definition=<br />
==Why?==<br />
Lets say that I have a database containing prepared activities and educational content for boy scouts group. Its purpose is to serve as a source of inspiration and eventually of collection of high quality content appropriate for kids during our weekly meetings or other occasions. From which source should be easy to get precisely only the desired results based on defined properties on each activity (eg. time needed for preparation, minimal number of players, etc.)<br />
<br />
BUT actually its currently more like a proof of concept and not a really operational tool. So accordingly there aren't yet any real records to speak about.<br />
This very early stage of development is exactly the reason why I think it is reasonable to think about how will the database be populated with data. As this will be crucial for its future usability and success. Therefore, the simulation should focus on modeling this data population process.<br />
==What?==<br />
To be precise, the simulation will be concerned with user behavior and related volume of stored records.<br />
<br />
It is important to say that user interface for reading is only the default web gui of the database itself (Neo4j), so the users will have to use the Cypher query language. So after they go through such a way to access the records, there better be some decent amount of useful ones in the database. This is because otherwise their whole effort would be pointless and the user would be discouraged from using the database again.<br />
<br />
Creating the records on the other hand will be easy and accessible as much as possible (user writes to google document in specified folder and with specified structure which enables then loading it programmaticaly into the database). This ease of creation is key to encouraging consistent contributions.<br />
<br />
And here comes the question whether this "natural" way of data population is enough, or rather how long will it take for the database to be able to provide satisfactory results for the user in majority of the cases and as such could be called a useful tool. If the time required would be too long, the users could lose interest of even contributing new content .<br />
Therefore, the simulation will model the rate of content creation and the subsequent impact on database searchability and usability.<br />
<br />
Additionally will be also evaluated the "batch population approach" to see weather it is worth considering to implement. This will involve creating a model of user behavior and content creation, simulating different scenarios, and analyzing the results.<br />
==Objectives==<br />
This simulation aims to predict the growth of the database, determine the feasibility of the current data population strategy and evaluate the alternative.<br />
<br />
#Predict the time needed to reach a critical mass of data sufficient for effective use.<br />
#Evaluate the effectiveness of the current data population method relatively to alternative.<br />
<br />
=Method=<br />
==Agent-based model==<br />
The core method used for this simulation is agent-based modeling (ABM). This approach was selected because it aligns well with the nature of the problem, which involves multiple individual users (agents) interacting with a shared environment (the database). Specifically, it enabled me to simulate:<br />
<br />
*Individual User Behaviors: Each agent acts independently, deciding whether to search the database, create a new record, or improve existing ones, based on their local information and probabilities.<br />
*Heterogeneity (Limited): While the agents initially are identical, they change during the simulation based on their interactions with the database.<br />
*Emergent System Behavior: The overall growth and usability of the database is not programmed directly, but emerges from the accumulation of individual actions.<br />
<br />
Alternatively the system dynamics or simple math equations could be used but neither of them would be more fitting for this usecase.<br />
While system dynamics could model the overall growth of the database as a system, it would not provide the same level of detail regarding individual user actions. System dynamics works well when dealing with aggregate levels and rates of change but isn't great for capturing how each agent behaviour individually impacts the system.<br />
<br />
Just as the equations could model a simplified database growth equation, but it would be extremely difficult to derive a model which includes agents success/fail feedback, record improvement and cooldown and thus it was not considered as applicable for this problem.<br />
==Julia==<br />
Because the ABM approach was chosen the NetLogo was concidered as environment for implemantation of the simulation, but also was the language Julia as it is also often used for simulations. In the end the Julia was chosen because of its more general usability and therefore more usecases when learned to use.<br />
<br />
The simulation is implemented in Julia using the Distributions, StatsBase, and Logging packages.<br />
Logging is enabled to output data about records, agents and overall progress of simulation to a log file called simulation.log.<br />
<br />
Plots are used for visualization and stored as *.png files.<br />
<br />
=Model=<br />
<br />
==Entities==<br />
;Database (db):<br />
A dictionary storing Record objects, categorized by integers representing different activity categories.<br />
*The keys of the dictionary are integers representing category id.<br />
*Each category is associated with a vector (array) of Record objects.<br />
*Initially, each category has an empty vector, which can be populated by new records.<br />
<br />
;Record:<br />
A struct containing:<br />
*id (Integer): A unique identifier for the record, auto-incrementing with each creation.<br />
*quality (Float64): Represents the perceived quality or usability of the record. <br />
<br />
(Originally it should more closely resamble the real live improvements by being represented by only range 1-10 as the real live records also can not be improved infinitelly, but in the end there was left simplier implemantation that just has a chance to improve the record during every picked to use event by random value withou top limit.)<br />
<br />
;Agent:<br />
A struct representing a user of the database.<br />
*probabilityToSearch (Float64): The agent's current probability of finding a useful record, it is based on past success of the agent when searching the db. This parameter influences agent's decision whether to search the db or not.<br />
*used (Dict{Int, Vector{Int}}): A dictionary that stores which record IDs have been used by agent and in which week the record has been used, so it won't be used by the same agent during a given cooldown period. Keys are record ids and values are vectors containing week integers in which the record has been used.<br />
<br />
==Variables==<br />
;NUM_AGENTS: <br />
: Integer representing the number of agents (users) participating in the simulation. Value is fixed at 3.<br />
: It is because in our group we have three active leaders for the regular meating.<br />
;BATCH_UPLOAD_SIZES:<br />
: Vector of integers representing different sizes of initial record batches uploaded to the database. The values used in simulation are [0, 10, 30, 50].<br />
: I do not expect to have higher hundreds of the records in the db and I am mainly interested in the begining of the process so here chosen values provide enough info. <br />
;initialQualityDist: <br />
: A lognormal distribution (LogNormal(3, 2)) used to generate the initial quality of new records. The mean is set to 3, and the standard deviation is set to 2, meaning the typical quality of created record will be around 3, but there could be some with higher or lower.<br />
:Because I originally intended to have Records quality kept in range from 1-10 I picked the lognormal distribution with parameters that would result in relatively low to mid quality of records created. Thats reflect better the reality because records can not have high quality without feedback from kids after at least few tries of given activity, which can not be accumulated earlier than after some time, so new records should not have higher initialQuality.<br />
;qualityImprovementProb<br />
: Float64 representing the probability that an agent will improve a record's quality after using it. Value is fixed at 0.7 for the sake of simplicity and simulation feasibility.<br />
: This value was was chosen in hope that leaders will tend to return the favor after using the found record. Also its easier than creating new record, but of course it can not be in all cases so 0.7 seems appropriet.<br />
;recordCreationProb<br />
: Float64 representing the probability that an agent creates a new record when they are preparing an activity and decide not to search the database. Value is fixed at 0.3 for the sake of simplicity and simulation feasibility.<br />
: According to logic applied in qualityImprovementProb here I assume that because the agent didnt found a useful record, he wont be that much interested in investing his time to write down the activity so it could be recorded. And much less when realizing how much pain is to create a quality and useful record.<br />
;categories<br />
: Vector of integer representing the category ids of the db records. The vector is generated as range from 1 to 20, [1:20;].<br />
: Originaly I intended to have categories explicitly named for closer resemblance with reality but I failed to find a real contribution for the simulation, because real live categories are much more comple so this simplified idea is not much realistic to begin with therefore i came to conclusion that using just simple intagers to represent the categories will be better choice for this case.<br />
The original idea was something like this. <br />
const TYPES = ["running", "creative", "thinking", "discussion", "history"] # Types of activities<br />
const PLACES = ["room", "forest", "city", "playground"] # Possible places for activities<br />
const CATEGORIES = [(t, p) for t in TYPES for p in PLACES] # Generate all combinations of types and places<br />
:Using intager instead makes for example much easier change the number of categories, which could be interesting to see how its change influences the observed values.<br />
<br />
<br />
Next three variables limits how long will the simulation run, respectively how long needs the system to be usefull without "fail".<br />
;targetSuccessfulness<br />
: Float64 value, which represents minimum success rate, that needs to be reached for the database to be considered "useful" in a long term. Value is 0.75.<br />
;nSuccessfullFromEpisode<br />
: An integer number representing how many successful searches per episode of the simulation have to occur in order for it to be considered "useful". Value is 4.<br />
;episodeLength<br />
: Integer which represents length of a one "episode" within the simulation, which in this case is a sequence of weeks for which the success rate of the db will be tested if it met required conditions. Value is set to 6, this means 6 weeks.<br />
Such a long time period was chosen based on my requirements, but in the end this choice proved somewhat contraproductive for getting a good results.<br />
<br />
==Flow==<br />
'''1.Initialization:'''<br />
<br />
*The database is created with empty vectors of records for each defined category (integer from 1 to 20).<br />
*A defined number of agents are created with default probabilityToSearch.<br />
*Optionally, a number of initial Record objects will be created (based on parameter BATCH_UPLOAD_SIZE), and randomly assigned to a random category within the database.<br />
<br />
'''2.Weekly Cycle (One Tick):'''<br />
<br />
*Each week (tick), each agent attempts to prepare an activity.<br />
*Each agent selects a random category.<br />
*Then each agent decides whether to search the database based on their current probabilityToSearch (It was originally designed to be able to dynamicaly calculate probabilityToSearch of agents independently, but for the same reason the recordCreationProb is global to all agents, also this variable was left the same for all agents).<br />
<br />
;Search Behavior:<br />
<br />
*If the agent decides to search, it looks up all records that matches it selected category.<br />
*If records are found, the agents samples without replacement a predefined number of records for evaluation. Each has different probability based on its quality. The more quality it has, the higher the probability to be chosen. (Weights are calculated like this [rec.quality / sum(r.quality for r in records) for rec in records])<br />
*An agent tries to pick for use randomly one record from those records. <br />
*Before the agent uses any of the found records, there has to be checked if they haven't been used in a defined "cooldown period", which is set to 54 weeks. Each agent keeps track of used records and the weeks where they where used.<br />
*If the record the agent tries to pick is on cooldown, the agent proceeds to trying another one from the sampled ones until it finds a cooled down one or until there are no more samples (usually in the beginning of the simulation when there are yot not created record in the db).<br />
*If the record is used, there is a probability of the agent improving the quality of that used record.<br />
<br />
;Record Creation Behavior:<br />
<br />
*If the agent decides not to search or if the search is unsuccessful, it has a chance of creating a new record (based on parameter recordCreationProb).<br />
*If a new record is created, it's assigned a randomly generated initial quality based on the lognormal distribution, and pushed to db under it's selected category.<br />
*Also there is kept record of total number oc record created so far during the simulation and the order number of each record is assigned to the record during its creation as its id. This way its possible to keep track of which records were used before by the given agent.<br />
<br />
'''3.Evaluation'''<br />
*Further the simulation tracks total search attempts and successes. The success is considered only when a record is successfully used for an activity and not when a record is found or searched for.<br />
*At the end of each week, a weekly success rate is calculated by dividing the amount of successful record usages by the number of attempts that were performed.<br />
*The simulation continues until the database has reached "sufficient" usability.<br />
*A database is considered as "sufficiently useful" when success rates in a defined episode length (6 weeks) are over a defined threshold (75%) for a given minimum number of successful weeks (4 out of 6). In other words, when this condition is met within a 3 month timeframe.<br />
<br />
==Limitations==<br />
<br />
*Simplified Categories: The categories used in the model are represented by integers and lack any explicit meaning. It was intended to use a combination of string as category representation, but the complexity has no effect on the results, therefore integer representation is used to make code simpler.<br />
*Agent Uniformity: Each agent has an identical recordCreationProb which is not realistic, and does not model different level of contributing to the db.<br />
*Fixed Parameters: Many model parameters, such as qualityImprovementProb, recordCreationProb, NUM_AGENTS are fixed values and don't change during simulation, which makes the simulation a bit static.<br />
*Single Activity Per Week: Each agent prepares only one activity per week, which may be an oversimplification of real user behavior.<br />
*Limited Complexity: The simulation lacks a deeper understanding of how records relate to each other or have a more diverse properties than just an "quality".<br />
<br />
=Results=<br />
In the last section of appended code there was realized an attempt to calculate the results simply by adding new function which whould call the main simulation given number of times and recorded the results so the variability caused by randomness could be viewed. Specifically how the required number of weeks and number of created records varied when running the simulation repeatedly.<br />
<br />
Unfortunately there has been some enexpected and probably undesired patterns occuring in the obtained "multi run" results. Most likely a skillissue on my side. Further elaboration follows.<br />
<br />
Also there is a bug/feature with my function which determines when the search process is successfull enough. Because i require certain amount of time to assess the stability of said successfullness, there is a minimal but fixed timeframe in the begining of the simulation. And because of this when the number of weeks required for the system to be recognized as usefull is measured, its value can not begin earlier than after said timeframe, so that is why the smallest number of weeks in the results are 21.<br />
<br />
Also the counter of created records does not count the records created via batch upload so when reading it needs to be kept in mind.<br />
<br />
Also in the github repository with code, there are plots showing how the successrate evolves in time.<br />
==Single run==<br />
This means runing the multi run function for single iteration.<br />
<br />
But it was run manually three times.<br />
;batch 0 <br />
:weeks until "usefullness": 82, 51, 69<br />
:records created in db: 44, 40, 55<br />
<br />
;batch 10<br />
:weeks: 21, 33, 21<br />
:records: 21, 26, 19 <br />
<br />
;batch 30<br />
:weeks: 24, 21, 22<br />
:records: 26, 17, 18<br />
<br />
;batch 50<br />
:weeks: 21, 21, 21<br />
:records: 30, 18, 27<br />
<br />
It appears that the batch upload in the beginning realy speeds up the time required for the database to be considered usefull, but unfortunately the implementation can not ends earlier then after at least small fixed timeframe.<br />
Its obvious that the results are heavily influenced by the randomness in the model.<br />
<br />
It seems that the first small batch upload has the largest influence on the resulting values and larger batches brings only relatively smaller improvements, that suggests to use the batch upload in real life, but its redundant to focus on optimizing the upload process for larger amounts, because they are not needed and only small amount of records (10) is enough to significantly boost the speed of populating.<br />
<br />
Also the amounts of records additionally created after 50 batch upload seems a bit unexpected, because after results seen in smaller batches one would expect a number around 15 or smaller. If it is not another bug in my code, I would guess that its bacause of small sample of results.<br />
<br />
==Multi run==<br />
;batch 0<br />
:weeks: [55, 72, 70, 78, 94, 114, 126, 120, 135, 140, 152, 156, 180, 161, 167]<br />
:records: [32, 129, 108, 195, 262, 316, 320, 308, 366, 373, 432, 442, 496, 486, 487]<br />
<br />
;batch 10<br />
:weeks: [35, 99, 99, 189, 249, 291, 298, 413, 413, 426, 452, 433, 471, 520, 564]<br />
:records: [35, 48, 43, 90, 93, 112, 116, 148, 133, 141, 143, 155, 163, 158, 188]<br />
<br />
;batch 30<br />
:weeks: [21, 67, 79, 105, 99, 97, 115, 132, 137, 149, 160, 158, 170, 178, 181]<br />
:records: [13, 170, 200, 227, 272, 254, 336, 316, 406, 423, 442, 415, 464, 496, 521]<br />
<br />
;batch 50<br />
:weeks: [33, 21, 82, 83, 91, 113, 123, 149, 145, 144, 152, 166, 164, 175, 192]<br />
:records: [58, 42, 187, 247, 271, 306, 331, 365, 397, 413, 468, 502, 495, 507, 540]<br />
<br />
Well, those are here just for fun because there is not much value in such results except for showing something does not work as expected.<br />
<br />
=Discussion=<br />
In this simulation I managed to create heavily simplified model of database populating process in our boy scouts group.<br />
<br />
Therefore the resuls appears to be approximately as they should, but they lack on the reliability if they should be used as a base for a decision.<br />
At most I can take a hint about the amount of records to batch upload. That relatively small amount makes a major difference.<br />
<br />
To further improve the model there should be implemented:<br />
*Chance for agents to "not like the record", that would sometimes stoped the agent from picking a record to use. It could try picking another if there would be more, if not the search would fail. This would be a small improvment to a model realisticity.<br />
*Enhance the feature of records quality so it could not be increased infinitely. <br />
*Add monitoring for values of records quality, so I can see better what is the state of the db like.<br />
<br />
=Code=<br />
This is my code on github, because I could not upload .jl file and a did not wanted to make zip: [https://raw.githubusercontent.com/simik394/simulace-populatingskautdb/refs/heads/main/simulace-nobatch.jl]<br />
<br />
And the home repo [https://github.com/simik394/simulace-populatingskautdb]<br />
<br />
[[User:Tros01|Tros01]] ([[User talk:Tros01|talk]]) 22:19, 19 January 2025 (CET)</div>Tros01http://www.simulace.info/index.php?title=Populating_the_database&diff=26616Populating the database2025-01-26T22:16:20Z<p>Tros01: /* Variables */</p>
<hr />
<div>Úvodní odstavec<br />
<br />
=Problem definition=<br />
==Why?==<br />
Lets say that I have a database containing prepared activities and educational content for boy scouts group. Its purpose is to serve as a source of inspiration and eventually of collection of high quality content appropriate for kids during our weekly meetings or other occasions. From which source should be easy to get precisely only the desired results based on defined properties on each activity (eg. time needed for preparation, minimal number of players, etc.)<br />
<br />
BUT actually its currently more like a proof of concept and not a really operational tool. So accordingly there aren't yet any real records to speak about.<br />
This very early stage of development is exactly the reason why I think it is reasonable to think about how will the database be populated with data. As this will be crucial for its future usability and success. Therefore, the simulation should focus on modeling this data population process.<br />
==What?==<br />
To be precise, the simulation will be concerned with user behavior and related volume of stored records.<br />
<br />
It is important to say that user interface for reading is only the default web gui of the database itself (Neo4j), so the users will have to use the Cypher query language. So after they go through such a way to access the records, there better be some decent amount of useful ones in the database. This is because otherwise their whole effort would be pointless and the user would be discouraged from using the database again.<br />
<br />
Creating the records on the other hand will be easy and accessible as much as possible (user writes to google document in specified folder and with specified structure which enables then loading it programmaticaly into the database). This ease of creation is key to encouraging consistent contributions.<br />
<br />
And here comes the question whether this "natural" way of data population is enough, or rather how long will it take for the database to be able to provide satisfactory results for the user in majority of the cases and as such could be called a useful tool. If the time required would be too long, the users could lose interest of even contributing new content .<br />
Therefore, the simulation will model the rate of content creation and the subsequent impact on database searchability and usability.<br />
<br />
Additionally will be also evaluated the "batch population approach" to see weather it is worth considering to implement. This will involve creating a model of user behavior and content creation, simulating different scenarios, and analyzing the results.<br />
==Objectives==<br />
This simulation aims to predict the growth of the database, determine the feasibility of the current data population strategy and evaluate the alternative.<br />
<br />
#Predict the time needed to reach a critical mass of data sufficient for effective use.<br />
#Evaluate the effectiveness of the current data population method relatively to alternative.<br />
<br />
=Method=<br />
==Agent-based model==<br />
The core method used for this simulation is agent-based modeling (ABM). This approach was selected because it aligns well with the nature of the problem, which involves multiple individual users (agents) interacting with a shared environment (the database). Specifically, it enabled me to simulate:<br />
<br />
*Individual User Behaviors: Each agent acts independently, deciding whether to search the database, create a new record, or improve existing ones, based on their local information and probabilities.<br />
*Heterogeneity (Limited): While the agents initially are identical, they change during the simulation based on their interactions with the database.<br />
*Emergent System Behavior: The overall growth and usability of the database is not programmed directly, but emerges from the accumulation of individual actions.<br />
<br />
Alternatively the system dynamics or simple math equations could be used but neither of them would be more fitting for this usecase.<br />
While system dynamics could model the overall growth of the database as a system, it would not provide the same level of detail regarding individual user actions. System dynamics works well when dealing with aggregate levels and rates of change but isn't great for capturing how each agent behaviour individually impacts the system.<br />
<br />
Just as the equations could model a simplified database growth equation, but it would be extremely difficult to derive a model which includes agents success/fail feedback, record improvement and cooldown and thus it was not considered as applicable for this problem.<br />
==Julia==<br />
Because the ABM approach was chosen the NetLogo was concidered as environment for implemantation of the simulation, but also was the language Julia as it is also often used for simulations. In the end the Julia was chosen because of its more general usability and therefore more usecases when learned to use.<br />
<br />
The simulation is implemented in Julia using the Distributions, StatsBase, and Logging packages.<br />
Logging is enabled to output data about records, agents and overall progress of simulation to a log file called simulation.log.<br />
<br />
Plots are used for visualization and stored as *.png files.<br />
<br />
=Model=<br />
<br />
==Entities==<br />
;Database (db):<br />
A dictionary storing Record objects, categorized by integers representing different activity categories.<br />
*The keys of the dictionary are integers representing category id.<br />
*Each category is associated with a vector (array) of Record objects.<br />
*Initially, each category has an empty vector, which can be populated by new records.<br />
<br />
;Record:<br />
A struct containing:<br />
*id (Integer): A unique identifier for the record, auto-incrementing with each creation.<br />
*quality (Float64): Represents the perceived quality or usability of the record. <br />
<br />
(Originally it should more closely resamble the real live improvements by being represented by only range 1-10 as the real live records also can not be improved infinitelly, but in the end there was left simplier implemantation that just has a chance to improve the record during every picked to use event by random value withou top limit.)<br />
<br />
;Agent:<br />
A struct representing a user of the database.<br />
*probabilityToSearch (Float64): The agent's current probability of finding a useful record, it is based on past success of the agent when searching the db. This parameter influences agent's decision whether to search the db or not.<br />
*used (Dict{Int, Vector{Int}}): A dictionary that stores which record IDs have been used by agent and in which week the record has been used, so it won't be used by the same agent during a given cooldown period. Keys are record ids and values are vectors containing week integers in which the record has been used.<br />
<br />
==Variables==<br />
;NUM_AGENTS: <br />
: Integer representing the number of agents (users) participating in the simulation. Value is fixed at 3.<br />
: It is because in our group we have three active leaders for the regular meating.<br />
;BATCH_UPLOAD_SIZES:<br />
: Vector of integers representing different sizes of initial record batches uploaded to the database. The values used in simulation are [0, 10, 30, 50].<br />
: I do not expect to have higher hundreds of the records in the db and I am mainly interested in the begining of the process so here chosen values provide enough info. <br />
;initialQualityDist: <br />
: A lognormal distribution (LogNormal(3, 2)) used to generate the initial quality of new records. The mean is set to 3, and the standard deviation is set to 2, meaning the typical quality of created record will be around 3, but there could be some with higher or lower.<br />
:Because I originally intended to have Records quality kept in range from 1-10 I picked the lognormal distribution with parameters that would result in relatively low to mid quality of records created. Thats reflect better the reality because records can not have high quality without feedback from kids after at least few tries of given activity, which can not be accumulated earlier than after some time, so new records should not have higher initialQuality.<br />
;qualityImprovementProb<br />
: Float64 representing the probability that an agent will improve a record's quality after using it. Value is fixed at 0.7 for the sake of simplicity and simulation feasibility.<br />
: This value was was chosen in hope that leaders will tend to return the favor after using the found record. Also its easier than creating new record, but of course it can not be in all cases so 0.7 seems appropriet.<br />
;recordCreationProb<br />
: Float64 representing the probability that an agent creates a new record when they are preparing an activity and decide not to search the database. Value is fixed at 0.3 for the sake of simplicity and simulation feasibility.<br />
: According to logic applied in qualityImprovementProb here I assume that because the agent didnt found a useful record, he wont be that much interested in investing his time to write down the activity so it could be recorded. And much less when realizing how much pain is to create a quality and useful record.<br />
;categories<br />
: Vector of integer representing the category ids of the db records. The vector is generated as range from 1 to 20, [1:20;].<br />
: Originaly I intended to have categories explicitly named for closer resemblance with reality but I failed to find a real contribution for the simulation, because real live categories are much more comple so this simplified idea is not much realistic to begin with therefore i came to conclusion that using just simple intagers to represent the categories will be better choice for this case.<br />
The original idea was something like this. <br />
const TYPES = ["running", "creative", "thinking", "discussion", "history"] # Types of activities<br />
const PLACES = ["room", "forest", "city", "playground"] # Possible places for activities<br />
const CATEGORIES = [(t, p) for t in TYPES for p in PLACES] # Generate all combinations of types and places<br />
:Using intager instead makes for example much easier change the number of categories, which could be interesting to see how its change influences the observed values.<br />
<br />
<br />
Next three variables limits how long will the simulation run, respectively how long needs the system to be usefull without "fail".<br />
;targetSuccessfulness<br />
: Float64 value, which represents minimum success rate, that needs to be reached for the database to be considered "useful" in a long term. Value is 0.75.<br />
;nSuccessfullFromEpisode<br />
: An integer number representing how many successful searches per episode of the simulation have to occur in order for it to be considered "useful". Value is 4.<br />
;episodeLength<br />
: Integer which represents length of a one "episode" within the simulation, which in this case is a sequence of weeks for which the success rate of the db will be tested if it met required conditions. Value is set to 6, this means 6 weeks.<br />
Such a long time period was chosen based on my requirements, but in the end this choice proved somewhat contraproductive for getting a good results.<br />
<br />
==Flow==<br />
'''1.Initialization:'''<br />
<br />
*The database is created with empty vectors of records for each defined category (integer from 1 to 20).<br />
*A defined number of agents are created with default probabilityToSearch.<br />
*Optionally, a number of initial Record objects will be created (based on parameter BATCH_UPLOAD_SIZE), and randomly assigned to a random category within the database.<br />
<br />
'''2.Weekly Cycle (One Tick):'''<br />
<br />
*Each week (tick), each agent attempts to prepare an activity.<br />
*Each agent selects a random category.<br />
*Then each agent decides whether to search the database based on their current probabilityToSearch (It was originally designed to be able to dynamicaly calculate probabilityToSearch of agents independently, but for the same reason the recordCreationProb is global to all agents, also this variable was left the same for all agents).<br />
<br />
;Search Behavior:<br />
<br />
*If the agent decides to search, it looks up all records that matches it selected category.<br />
*If records are found, the agents samples without replacement a predefined number of records for evaluation. Each has different probability based on its quality. The more quality it has, the higher the probability to be chosen. (Weights are calculated like this [rec.quality / sum(r.quality for r in records) for rec in records])<br />
*An agent tries to pick for use randomly one record from those records. <br />
*Before the agent uses any of the found records, there has to be checked if they haven't been used in a defined "cooldown period", which is set to 54 weeks. Each agent keeps track of used records and the weeks where they where used.<br />
*If the record the agent tries to pick is on cooldown, the agent proceeds to trying another one from the sampled ones until it finds a cooled down one or until there are no more samples (usually in the beginning of the simulation when there are yot not created record in the db).<br />
*If the record is used, there is a probability of the agent improving the quality of that used record.<br />
<br />
;Record Creation Behavior:<br />
<br />
*If the agent decides not to search or if the search is unsuccessful, it has a chance of creating a new record (based on parameter recordCreationProb).<br />
*If a new record is created, it's assigned a randomly generated initial quality based on the lognormal distribution, and pushed to db under it's selected category.<br />
*Also there is kept record of total number oc record created so far during the simulation and the order number of each record is assigned to the record during its creation as its id. This way its possible to keep track of which records were used before by the given agent.<br />
<br />
'''3.Evaluation'''<br />
*Further the simulation tracks total search attempts and successes. The success is considered only when a record is successfully used for an activity and not when a record is found or searched for.<br />
*At the end of each week, a weekly success rate is calculated by dividing the amount of successful record usages by the number of attempts that were performed.<br />
*The simulation continues until the database has reached "sufficient" usability.<br />
*A database is considered as "sufficiently useful" when success rates in a defined episode length (6 weeks) are over a defined threshold (75%) for a given minimum number of successful weeks (4 out of 6). In other words, when this condition is met within a 3 month timeframe.<br />
<br />
==Limitations==<br />
<br />
*Simplified Categories: The categories used in the model are represented by integers and lack any explicit meaning. It was intended to use a combination of string as category representation, but the complexity has no effect on the results, therefore integer representation is used to make code simpler.<br />
*Agent Uniformity: Each agent has an identical recordCreationProb which is not realistic, and does not model different level of contributing to the db.<br />
*Fixed Parameters: Many model parameters, such as qualityImprovementProb, recordCreationProb, NUM_AGENTS are fixed values and don't change during simulation, which makes the simulation a bit static.<br />
*Single Activity Per Week: Each agent prepares only one activity per week, which may be an oversimplification of real user behavior.<br />
*Limited Complexity: The simulation lacks a deeper understanding of how records relate to each other or have a more diverse properties than just an "quality".<br />
<br />
=Results=<br />
In the last section of appended code there was realized an attempt to calculate the results simply by adding new function which whould call the main simulation given number of times and recorded the results so the variability caused by randomness could be viewed. Specifically how the required number of weeks and number of created records varied when running the simulation repeatedly.<br />
<br />
Unfortunately there has been some enexpected and probably undesired patterns occuring in the obtained "multi run" results. Most likely a skillissue on my side. Further elaboration follows.<br />
<br />
Also there is a bug/feature with my function which determines when the search process is successfull enough. Because i require certain amount of time to assess the stability of said successfullness, there is a minimal but fixed timeframe in the begining of the simulation. And because of this when the number of weeks required for the system to be recognized as usefull is measured, its value can not begin earlier than after said timeframe, so that is why the smallest number of weeks in the results are 21.<br />
<br />
Also the counter of created records does not count the records created via batch upload so when reading it needs to be kept in mind.<br />
<br />
Also in the github repository with code, there are plots showing how the successrate evolves in time.<br />
==Single run==<br />
This means runing the multi run function for single iteration.<br />
<br />
But it was run manually three times.<br />
;batch 0 <br />
:weeks until "usefullness": 82, 51, 69<br />
:records created in db: 44, 40, 55<br />
<br />
;batch 10<br />
:weeks: 21, 33, 21<br />
:records: 21, 26, 19 <br />
<br />
;batch 30<br />
:weeks: 24, 21, 22<br />
:records: 26, 17, 18<br />
<br />
;batch 50<br />
:weeks: 21, 21, 21<br />
:records: 30, 18, 27<br />
<br />
It appears that the batch upload in the beginning realy speeds up the time required for the database to be considered usefull, but unfortunately the implementation can not ends earlier then after at least small fixed timeframe.<br />
Its obvious that the results are heavily influenced by the randomness in the model.<br />
<br />
It seems that the first small batch upload has the largest influence on the resulting values and larger batches brings only relatively smaller improvements, that suggests to use the batch upload in real life, but its redundant to focus on optimizing the upload process for larger amounts, because they are not needed and only small amount of records (10) is enough to significantly boost the speed of populating.<br />
<br />
==Multi run==<br />
;batch 0<br />
:weeks: [55, 72, 70, 78, 94, 114, 126, 120, 135, 140, 152, 156, 180, 161, 167]<br />
:records: [32, 129, 108, 195, 262, 316, 320, 308, 366, 373, 432, 442, 496, 486, 487]<br />
<br />
;batch 10<br />
:weeks: [35, 99, 99, 189, 249, 291, 298, 413, 413, 426, 452, 433, 471, 520, 564]<br />
:records: [35, 48, 43, 90, 93, 112, 116, 148, 133, 141, 143, 155, 163, 158, 188]<br />
<br />
;batch 30<br />
:weeks: [21, 67, 79, 105, 99, 97, 115, 132, 137, 149, 160, 158, 170, 178, 181]<br />
:records: [13, 170, 200, 227, 272, 254, 336, 316, 406, 423, 442, 415, 464, 496, 521]<br />
<br />
;batch 50<br />
:weeks: [33, 21, 82, 83, 91, 113, 123, 149, 145, 144, 152, 166, 164, 175, 192]<br />
:records: [58, 42, 187, 247, 271, 306, 331, 365, 397, 413, 468, 502, 495, 507, 540]<br />
<br />
Well, those are here just for fun because there is not much value in such results except for showing something does not work as expected.<br />
<br />
=Discussion=<br />
In this simulation I managed to create heavily simplified model of database populating process in our boy scouts group.<br />
<br />
Therefore the resuls appears to be approximately as they should, but they lack on the reliability if they should be used as a base for a decision.<br />
At most I can take a hint about the amount of records to batch upload. That relatively small amount makes a major difference.<br />
<br />
To further improve the model there should be implemented:<br />
*Chance for agents to "not like the record", that would sometimes stoped the agent from picking a record to use. It could try picking another if there would be more, if not the search would fail. This would be a small improvment to a model realisticity.<br />
*Enhance the feature of records quality so it could not be increased infinitely. <br />
*Add monitoring for values of records quality, so I can see better what is the state of the db like.<br />
<br />
=Code=<br />
This is my code on github, because I could not upload .jl file and a did not wanted to make zip: [https://raw.githubusercontent.com/simik394/simulace-populatingskautdb/refs/heads/main/simulace-nobatch.jl]<br />
<br />
And the home repo [https://github.com/simik394/simulace-populatingskautdb]<br />
<br />
[[User:Tros01|Tros01]] ([[User talk:Tros01|talk]]) 22:19, 19 January 2025 (CET)</div>Tros01http://www.simulace.info/index.php?title=Populating_the_database&diff=26550Populating the database2025-01-20T00:00:37Z<p>Tros01: /* Discussion */</p>
<hr />
<div>Úvodní odstavec<br />
<br />
=Problem definition=<br />
==Why?==<br />
Lets say that I have a database containing prepared activities and educational content for boy scouts group. Its purpose is to serve as a source of inspiration and eventually of collection of high quality content appropriate for kids during our weekly meetings or other occasions. From which source should be easy to get precisely only the desired results based on defined properties on each activity (eg. time needed for preparation, minimal number of players, etc.)<br />
<br />
BUT actually its currently more like a proof of concept and not a really operational tool. So accordingly there aren't yet any real records to speak about.<br />
This very early stage of development is exactly the reason why I think it is reasonable to think about how will the database be populated with data. As this will be crucial for its future usability and success. Therefore, the simulation should focus on modeling this data population process.<br />
==What?==<br />
To be precise, the simulation will be concerned with user behavior and related volume of stored records.<br />
<br />
It is important to say that user interface for reading is only the default web gui of the database itself (Neo4j), so the users will have to use the Cypher query language. So after they go through such a way to access the records, there better be some decent amount of useful ones in the database. This is because otherwise their whole effort would be pointless and the user would be discouraged from using the database again.<br />
<br />
Creating the records on the other hand will be easy and accessible as much as possible (user writes to google document in specified folder and with specified structure which enables then loading it programmaticaly into the database). This ease of creation is key to encouraging consistent contributions.<br />
<br />
And here comes the question whether this "natural" way of data population is enough, or rather how long will it take for the database to be able to provide satisfactory results for the user in majority of the cases and as such could be called a useful tool. If the time required would be too long, the users could lose interest of even contributing new content .<br />
Therefore, the simulation will model the rate of content creation and the subsequent impact on database searchability and usability.<br />
<br />
Additionally will be also evaluated the "batch population approach" to see weather it is worth considering to implement. This will involve creating a model of user behavior and content creation, simulating different scenarios, and analyzing the results.<br />
==Objectives==<br />
This simulation aims to predict the growth of the database, determine the feasibility of the current data population strategy and evaluate the alternative.<br />
<br />
#Predict the time needed to reach a critical mass of data sufficient for effective use.<br />
#Evaluate the effectiveness of the current data population method relatively to alternative.<br />
<br />
=Method=<br />
==Agent-based model==<br />
The core method used for this simulation is agent-based modeling (ABM). This approach was selected because it aligns well with the nature of the problem, which involves multiple individual users (agents) interacting with a shared environment (the database). Specifically, it enabled me to simulate:<br />
<br />
*Individual User Behaviors: Each agent acts independently, deciding whether to search the database, create a new record, or improve existing ones, based on their local information and probabilities.<br />
*Heterogeneity (Limited): While the agents initially are identical, they change during the simulation based on their interactions with the database.<br />
*Emergent System Behavior: The overall growth and usability of the database is not programmed directly, but emerges from the accumulation of individual actions.<br />
<br />
Alternatively the system dynamics or simple math equations could be used but neither of them would be more fitting for this usecase.<br />
While system dynamics could model the overall growth of the database as a system, it would not provide the same level of detail regarding individual user actions. System dynamics works well when dealing with aggregate levels and rates of change but isn't great for capturing how each agent behaviour individually impacts the system.<br />
<br />
Just as the equations could model a simplified database growth equation, but it would be extremely difficult to derive a model which includes agents success/fail feedback, record improvement and cooldown and thus it was not considered as applicable for this problem.<br />
==Julia==<br />
Because the ABM approach was chosen the NetLogo was concidered as environment for implemantation of the simulation, but also was the language Julia as it is also often used for simulations. In the end the Julia was chosen because of its more general usability and therefore more usecases when learned to use.<br />
<br />
The simulation is implemented in Julia using the Distributions, StatsBase, and Logging packages.<br />
Logging is enabled to output data about records, agents and overall progress of simulation to a log file called simulation.log.<br />
<br />
Plots are used for visualization and stored as *.png files.<br />
<br />
=Model=<br />
<br />
==Entities==<br />
;Database (db):<br />
A dictionary storing Record objects, categorized by integers representing different activity categories.<br />
*The keys of the dictionary are integers representing category id.<br />
*Each category is associated with a vector (array) of Record objects.<br />
*Initially, each category has an empty vector, which can be populated by new records.<br />
<br />
;Record:<br />
A struct containing:<br />
*id (Integer): A unique identifier for the record, auto-incrementing with each creation.<br />
*quality (Float64): Represents the perceived quality or usability of the record. <br />
<br />
(Originally it should more closely resamble the real live improvements by being represented by only range 1-10 as the real live records also can not be improved infinitelly, but in the end there was left simplier implemantation that just has a chance to improve the record during every picked to use event by random value withou top limit.)<br />
<br />
;Agent:<br />
A struct representing a user of the database.<br />
*probabilityToSearch (Float64): The agent's current probability of finding a useful record, it is based on past success of the agent when searching the db. This parameter influences agent's decision whether to search the db or not.<br />
*used (Dict{Int, Vector{Int}}): A dictionary that stores which record IDs have been used by agent and in which week the record has been used, so it won't be used by the same agent during a given cooldown period. Keys are record ids and values are vectors containing week integers in which the record has been used.<br />
<br />
==Variables==<br />
;NUM_AGENTS: <br />
: Integer representing the number of agents (users) participating in the simulation. Value is fixed at 3.<br />
;BATCH_UPLOAD_SIZES:<br />
: Vector of integers representing different sizes of initial record batches uploaded to the database. The values used in simulation are [0, 10].<br />
;initialQualityDist: <br />
: A lognormal distribution (LogNormal(3, 2)) used to generate the initial quality of new records. The mean is set to 3, and the standard deviation is set to 2, meaning the typical quality of created record will be around 3, but there could be some with higher or lower.<br />
;qualityImprovementProb<br />
: Float64 representing the probability that an agent will improve a record's quality after using it. Value is fixed at 0.7 for the sake of simplicity and simulation feasibility.<br />
;recordCreationProb<br />
: Float64 representing the probability that an agent creates a new record when they are preparing an activity and decide not to search the database. Value is fixed at 0.3 for the sake of simplicity and simulation feasibility.<br />
;categories<br />
: Vector of integer representing the category ids of the db records. The vector is generated as range from 1 to 20, [1:20;].<br />
;targetSuccessfulness<br />
: Float64 value, which represents minimum success rate, that needs to be reached for the database to be considered "useful" in a long term. Value is 0.75.<br />
;nSuccessfullFromEpisode<br />
: An integer number representing how many successful searches per episode of the simulation have to occur in order for it to be considered "useful". Value is 4.<br />
;episodeLength<br />
: Integer which represents length of a one "episode" within the simulation, which in this case is a sequence of weeks for which the success rate of the db will be tested if it met required conditions. Value is set to 6, this means 6 weeks.<br />
<br />
==Flow==<br />
'''1.Initialization:'''<br />
<br />
*The database is created with empty vectors of records for each defined category (integer from 1 to 20).<br />
*A defined number of agents are created with default probabilityToSearch.<br />
*Optionally, a number of initial Record objects will be created (based on parameter BATCH_UPLOAD_SIZE), and randomly assigned to a random category within the database.<br />
<br />
'''2.Weekly Cycle (One Tick):'''<br />
<br />
*Each week (tick), each agent attempts to prepare an activity.<br />
*Each agent selects a random category.<br />
*Then each agent decides whether to search the database based on their current probabilityToSearch (It was originally designed to be able to dynamicaly calculate probabilityToSearch of agents independently, but for the same reason the recordCreationProb is global to all agents, also this variable was left the same for all agents).<br />
<br />
;Search Behavior:<br />
<br />
*If the agent decides to search, it looks up all records that matches it selected category.<br />
*If records are found, the agents samples without replacement a predefined number of records for evaluation. Each has different probability based on its quality. The more quality it has, the higher the probability to be chosen. (Weights are calculated like this [rec.quality / sum(r.quality for r in records) for rec in records])<br />
*An agent tries to pick for use randomly one record from those records. <br />
*Before the agent uses any of the found records, there has to be checked if they haven't been used in a defined "cooldown period", which is set to 54 weeks. Each agent keeps track of used records and the weeks where they where used.<br />
*If the record the agent tries to pick is on cooldown, the agent proceeds to trying another one from the sampled ones until it finds a cooled down one or until there are no more samples (usually in the beginning of the simulation when there are yot not created record in the db).<br />
*If the record is used, there is a probability of the agent improving the quality of that used record.<br />
<br />
;Record Creation Behavior:<br />
<br />
*If the agent decides not to search or if the search is unsuccessful, it has a chance of creating a new record (based on parameter recordCreationProb).<br />
*If a new record is created, it's assigned a randomly generated initial quality based on the lognormal distribution, and pushed to db under it's selected category.<br />
*Also there is kept record of total number oc record created so far during the simulation and the order number of each record is assigned to the record during its creation as its id. This way its possible to keep track of which records were used before by the given agent.<br />
<br />
'''3.Evaluation'''<br />
*Further the simulation tracks total search attempts and successes. The success is considered only when a record is successfully used for an activity and not when a record is found or searched for.<br />
*At the end of each week, a weekly success rate is calculated by dividing the amount of successful record usages by the number of attempts that were performed.<br />
*The simulation continues until the database has reached "sufficient" usability.<br />
*A database is considered as "sufficiently useful" when success rates in a defined episode length (6 weeks) are over a defined threshold (75%) for a given minimum number of successful weeks (4 out of 6). In other words, when this condition is met within a 3 month timeframe.<br />
<br />
==Limitations==<br />
<br />
*Simplified Categories: The categories used in the model are represented by integers and lack any explicit meaning. It was intended to use a combination of string as category representation, but the complexity has no effect on the results, therefore integer representation is used to make code simpler.<br />
*Agent Uniformity: Each agent has an identical recordCreationProb which is not realistic, and does not model different level of contributing to the db.<br />
*Fixed Parameters: Many model parameters, such as qualityImprovementProb, recordCreationProb, NUM_AGENTS are fixed values and don't change during simulation, which makes the simulation a bit static.<br />
*Single Activity Per Week: Each agent prepares only one activity per week, which may be an oversimplification of real user behavior.<br />
*Limited Complexity: The simulation lacks a deeper understanding of how records relate to each other or have a more diverse properties than just an "quality".<br />
<br />
=Results=<br />
In the last section of appended code there was realized an attempt to calculate the results simply by adding new function which whould call the main simulation given number of times and recorded the results so the variability caused by randomness could be viewed. Specifically how the required number of weeks and number of created records varied when running the simulation repeatedly.<br />
<br />
Unfortunately there has been some enexpected and probably undesired patterns occuring in the obtained "multi run" results. Most likely a skillissue on my side. Further elaboration follows.<br />
<br />
Also there is a bug/feature with my function which determines when the search process is successfull enough. Because i require certain amount of time to assess the stability of said successfullness, there is a minimal but fixed timeframe in the begining of the simulation. And because of this when the number of weeks required for the system to be recognized as usefull is measured, its value can not begin earlier than after said timeframe, so that is why the smallest number of weeks in the results are 21.<br />
<br />
Also the counter of created records does not count the records created via batch upload so when reading it needs to be kept in mind.<br />
<br />
Also in the github repository with code, there are plots showing how the successrate evolves in time.<br />
==Single run==<br />
This means runing the multi run function for single iteration.<br />
<br />
But it was run manually three times.<br />
;batch 0 <br />
:weeks until "usefullness": 82, 51, 69<br />
:records created in db: 44, 40, 55<br />
<br />
;batch 10<br />
:weeks: 21, 33, 21<br />
:records: 21, 26, 19 <br />
<br />
;batch 30<br />
:weeks: 24, 21, 22<br />
:records: 26, 17, 18<br />
<br />
;batch 50<br />
:weeks: 21, 21, 21<br />
:records: 30, 18, 27<br />
<br />
It appears that the batch upload in the beginning realy speeds up the time required for the database to be considered usefull, but unfortunately the implementation can not ends earlier then after at least small fixed timeframe.<br />
Its obvious that the results are heavily influenced by the randomness in the model.<br />
<br />
It seems that the first small batch upload has the largest influence on the resulting values and larger batches brings only relatively smaller improvements, that suggests to use the batch upload in real life, but its redundant to focus on optimizing the upload process for larger amounts, because they are not needed and only small amount of records (10) is enough to significantly boost the speed of populating.<br />
<br />
==Multi run==<br />
;batch 0<br />
:weeks: [55, 72, 70, 78, 94, 114, 126, 120, 135, 140, 152, 156, 180, 161, 167]<br />
:records: [32, 129, 108, 195, 262, 316, 320, 308, 366, 373, 432, 442, 496, 486, 487]<br />
<br />
;batch 10<br />
:weeks: [35, 99, 99, 189, 249, 291, 298, 413, 413, 426, 452, 433, 471, 520, 564]<br />
:records: [35, 48, 43, 90, 93, 112, 116, 148, 133, 141, 143, 155, 163, 158, 188]<br />
<br />
;batch 30<br />
:weeks: [21, 67, 79, 105, 99, 97, 115, 132, 137, 149, 160, 158, 170, 178, 181]<br />
:records: [13, 170, 200, 227, 272, 254, 336, 316, 406, 423, 442, 415, 464, 496, 521]<br />
<br />
;batch 50<br />
:weeks: [33, 21, 82, 83, 91, 113, 123, 149, 145, 144, 152, 166, 164, 175, 192]<br />
:records: [58, 42, 187, 247, 271, 306, 331, 365, 397, 413, 468, 502, 495, 507, 540]<br />
<br />
Well, those are here just for fun because there is not much value in such results except for showing something does not work as expected.<br />
<br />
=Discussion=<br />
In this simulation I managed to create heavily simplified model of database populating process in our boy scouts group.<br />
<br />
Therefore the resuls appears to be approximately as they should, but they lack on the reliability if they should be used as a base for a decision.<br />
At most I can take a hint about the amount of records to batch upload. That relatively small amount makes a major difference.<br />
<br />
To further improve the model there should be implemented:<br />
*Chance for agents to "not like the record", that would sometimes stoped the agent from picking a record to use. It could try picking another if there would be more, if not the search would fail. This would be a small improvment to a model realisticity.<br />
*Enhance the feature of records quality so it could not be increased infinitely. <br />
*Add monitoring for values of records quality, so I can see better what is the state of the db like.<br />
<br />
=Code=<br />
This is my code on github, because I could not upload .jl file and a did not wanted to make zip: [https://raw.githubusercontent.com/simik394/simulace-populatingskautdb/refs/heads/main/simulace-nobatch.jl]<br />
<br />
And the home repo [https://github.com/simik394/simulace-populatingskautdb]<br />
<br />
[[User:Tros01|Tros01]] ([[User talk:Tros01|talk]]) 22:19, 19 January 2025 (CET)</div>Tros01http://www.simulace.info/index.php?title=Populating_the_database&diff=26549Populating the database2025-01-19T23:49:52Z<p>Tros01: /* Discussion */</p>
<hr />
<div>Úvodní odstavec<br />
<br />
=Problem definition=<br />
==Why?==<br />
Lets say that I have a database containing prepared activities and educational content for boy scouts group. Its purpose is to serve as a source of inspiration and eventually of collection of high quality content appropriate for kids during our weekly meetings or other occasions. From which source should be easy to get precisely only the desired results based on defined properties on each activity (eg. time needed for preparation, minimal number of players, etc.)<br />
<br />
BUT actually its currently more like a proof of concept and not a really operational tool. So accordingly there aren't yet any real records to speak about.<br />
This very early stage of development is exactly the reason why I think it is reasonable to think about how will the database be populated with data. As this will be crucial for its future usability and success. Therefore, the simulation should focus on modeling this data population process.<br />
==What?==<br />
To be precise, the simulation will be concerned with user behavior and related volume of stored records.<br />
<br />
It is important to say that user interface for reading is only the default web gui of the database itself (Neo4j), so the users will have to use the Cypher query language. So after they go through such a way to access the records, there better be some decent amount of useful ones in the database. This is because otherwise their whole effort would be pointless and the user would be discouraged from using the database again.<br />
<br />
Creating the records on the other hand will be easy and accessible as much as possible (user writes to google document in specified folder and with specified structure which enables then loading it programmaticaly into the database). This ease of creation is key to encouraging consistent contributions.<br />
<br />
And here comes the question whether this "natural" way of data population is enough, or rather how long will it take for the database to be able to provide satisfactory results for the user in majority of the cases and as such could be called a useful tool. If the time required would be too long, the users could lose interest of even contributing new content .<br />
Therefore, the simulation will model the rate of content creation and the subsequent impact on database searchability and usability.<br />
<br />
Additionally will be also evaluated the "batch population approach" to see weather it is worth considering to implement. This will involve creating a model of user behavior and content creation, simulating different scenarios, and analyzing the results.<br />
==Objectives==<br />
This simulation aims to predict the growth of the database, determine the feasibility of the current data population strategy and evaluate the alternative.<br />
<br />
#Predict the time needed to reach a critical mass of data sufficient for effective use.<br />
#Evaluate the effectiveness of the current data population method relatively to alternative.<br />
<br />
=Method=<br />
==Agent-based model==<br />
The core method used for this simulation is agent-based modeling (ABM). This approach was selected because it aligns well with the nature of the problem, which involves multiple individual users (agents) interacting with a shared environment (the database). Specifically, it enabled me to simulate:<br />
<br />
*Individual User Behaviors: Each agent acts independently, deciding whether to search the database, create a new record, or improve existing ones, based on their local information and probabilities.<br />
*Heterogeneity (Limited): While the agents initially are identical, they change during the simulation based on their interactions with the database.<br />
*Emergent System Behavior: The overall growth and usability of the database is not programmed directly, but emerges from the accumulation of individual actions.<br />
<br />
Alternatively the system dynamics or simple math equations could be used but neither of them would be more fitting for this usecase.<br />
While system dynamics could model the overall growth of the database as a system, it would not provide the same level of detail regarding individual user actions. System dynamics works well when dealing with aggregate levels and rates of change but isn't great for capturing how each agent behaviour individually impacts the system.<br />
<br />
Just as the equations could model a simplified database growth equation, but it would be extremely difficult to derive a model which includes agents success/fail feedback, record improvement and cooldown and thus it was not considered as applicable for this problem.<br />
==Julia==<br />
Because the ABM approach was chosen the NetLogo was concidered as environment for implemantation of the simulation, but also was the language Julia as it is also often used for simulations. In the end the Julia was chosen because of its more general usability and therefore more usecases when learned to use.<br />
<br />
The simulation is implemented in Julia using the Distributions, StatsBase, and Logging packages.<br />
Logging is enabled to output data about records, agents and overall progress of simulation to a log file called simulation.log.<br />
<br />
Plots are used for visualization and stored as *.png files.<br />
<br />
=Model=<br />
<br />
==Entities==<br />
;Database (db):<br />
A dictionary storing Record objects, categorized by integers representing different activity categories.<br />
*The keys of the dictionary are integers representing category id.<br />
*Each category is associated with a vector (array) of Record objects.<br />
*Initially, each category has an empty vector, which can be populated by new records.<br />
<br />
;Record:<br />
A struct containing:<br />
*id (Integer): A unique identifier for the record, auto-incrementing with each creation.<br />
*quality (Float64): Represents the perceived quality or usability of the record. <br />
<br />
(Originally it should more closely resamble the real live improvements by being represented by only range 1-10 as the real live records also can not be improved infinitelly, but in the end there was left simplier implemantation that just has a chance to improve the record during every picked to use event by random value withou top limit.)<br />
<br />
;Agent:<br />
A struct representing a user of the database.<br />
*probabilityToSearch (Float64): The agent's current probability of finding a useful record, it is based on past success of the agent when searching the db. This parameter influences agent's decision whether to search the db or not.<br />
*used (Dict{Int, Vector{Int}}): A dictionary that stores which record IDs have been used by agent and in which week the record has been used, so it won't be used by the same agent during a given cooldown period. Keys are record ids and values are vectors containing week integers in which the record has been used.<br />
<br />
==Variables==<br />
;NUM_AGENTS: <br />
: Integer representing the number of agents (users) participating in the simulation. Value is fixed at 3.<br />
;BATCH_UPLOAD_SIZES:<br />
: Vector of integers representing different sizes of initial record batches uploaded to the database. The values used in simulation are [0, 10].<br />
;initialQualityDist: <br />
: A lognormal distribution (LogNormal(3, 2)) used to generate the initial quality of new records. The mean is set to 3, and the standard deviation is set to 2, meaning the typical quality of created record will be around 3, but there could be some with higher or lower.<br />
;qualityImprovementProb<br />
: Float64 representing the probability that an agent will improve a record's quality after using it. Value is fixed at 0.7 for the sake of simplicity and simulation feasibility.<br />
;recordCreationProb<br />
: Float64 representing the probability that an agent creates a new record when they are preparing an activity and decide not to search the database. Value is fixed at 0.3 for the sake of simplicity and simulation feasibility.<br />
;categories<br />
: Vector of integer representing the category ids of the db records. The vector is generated as range from 1 to 20, [1:20;].<br />
;targetSuccessfulness<br />
: Float64 value, which represents minimum success rate, that needs to be reached for the database to be considered "useful" in a long term. Value is 0.75.<br />
;nSuccessfullFromEpisode<br />
: An integer number representing how many successful searches per episode of the simulation have to occur in order for it to be considered "useful". Value is 4.<br />
;episodeLength<br />
: Integer which represents length of a one "episode" within the simulation, which in this case is a sequence of weeks for which the success rate of the db will be tested if it met required conditions. Value is set to 6, this means 6 weeks.<br />
<br />
==Flow==<br />
'''1.Initialization:'''<br />
<br />
*The database is created with empty vectors of records for each defined category (integer from 1 to 20).<br />
*A defined number of agents are created with default probabilityToSearch.<br />
*Optionally, a number of initial Record objects will be created (based on parameter BATCH_UPLOAD_SIZE), and randomly assigned to a random category within the database.<br />
<br />
'''2.Weekly Cycle (One Tick):'''<br />
<br />
*Each week (tick), each agent attempts to prepare an activity.<br />
*Each agent selects a random category.<br />
*Then each agent decides whether to search the database based on their current probabilityToSearch (It was originally designed to be able to dynamicaly calculate probabilityToSearch of agents independently, but for the same reason the recordCreationProb is global to all agents, also this variable was left the same for all agents).<br />
<br />
;Search Behavior:<br />
<br />
*If the agent decides to search, it looks up all records that matches it selected category.<br />
*If records are found, the agents samples without replacement a predefined number of records for evaluation. Each has different probability based on its quality. The more quality it has, the higher the probability to be chosen. (Weights are calculated like this [rec.quality / sum(r.quality for r in records) for rec in records])<br />
*An agent tries to pick for use randomly one record from those records. <br />
*Before the agent uses any of the found records, there has to be checked if they haven't been used in a defined "cooldown period", which is set to 54 weeks. Each agent keeps track of used records and the weeks where they where used.<br />
*If the record the agent tries to pick is on cooldown, the agent proceeds to trying another one from the sampled ones until it finds a cooled down one or until there are no more samples (usually in the beginning of the simulation when there are yot not created record in the db).<br />
*If the record is used, there is a probability of the agent improving the quality of that used record.<br />
<br />
;Record Creation Behavior:<br />
<br />
*If the agent decides not to search or if the search is unsuccessful, it has a chance of creating a new record (based on parameter recordCreationProb).<br />
*If a new record is created, it's assigned a randomly generated initial quality based on the lognormal distribution, and pushed to db under it's selected category.<br />
*Also there is kept record of total number oc record created so far during the simulation and the order number of each record is assigned to the record during its creation as its id. This way its possible to keep track of which records were used before by the given agent.<br />
<br />
'''3.Evaluation'''<br />
*Further the simulation tracks total search attempts and successes. The success is considered only when a record is successfully used for an activity and not when a record is found or searched for.<br />
*At the end of each week, a weekly success rate is calculated by dividing the amount of successful record usages by the number of attempts that were performed.<br />
*The simulation continues until the database has reached "sufficient" usability.<br />
*A database is considered as "sufficiently useful" when success rates in a defined episode length (6 weeks) are over a defined threshold (75%) for a given minimum number of successful weeks (4 out of 6). In other words, when this condition is met within a 3 month timeframe.<br />
<br />
==Limitations==<br />
<br />
*Simplified Categories: The categories used in the model are represented by integers and lack any explicit meaning. It was intended to use a combination of string as category representation, but the complexity has no effect on the results, therefore integer representation is used to make code simpler.<br />
*Agent Uniformity: Each agent has an identical recordCreationProb which is not realistic, and does not model different level of contributing to the db.<br />
*Fixed Parameters: Many model parameters, such as qualityImprovementProb, recordCreationProb, NUM_AGENTS are fixed values and don't change during simulation, which makes the simulation a bit static.<br />
*Single Activity Per Week: Each agent prepares only one activity per week, which may be an oversimplification of real user behavior.<br />
*Limited Complexity: The simulation lacks a deeper understanding of how records relate to each other or have a more diverse properties than just an "quality".<br />
<br />
=Results=<br />
In the last section of appended code there was realized an attempt to calculate the results simply by adding new function which whould call the main simulation given number of times and recorded the results so the variability caused by randomness could be viewed. Specifically how the required number of weeks and number of created records varied when running the simulation repeatedly.<br />
<br />
Unfortunately there has been some enexpected and probably undesired patterns occuring in the obtained "multi run" results. Most likely a skillissue on my side. Further elaboration follows.<br />
<br />
Also there is a bug/feature with my function which determines when the search process is successfull enough. Because i require certain amount of time to assess the stability of said successfullness, there is a minimal but fixed timeframe in the begining of the simulation. And because of this when the number of weeks required for the system to be recognized as usefull is measured, its value can not begin earlier than after said timeframe, so that is why the smallest number of weeks in the results are 21.<br />
<br />
Also the counter of created records does not count the records created via batch upload so when reading it needs to be kept in mind.<br />
<br />
Also in the github repository with code, there are plots showing how the successrate evolves in time.<br />
==Single run==<br />
This means runing the multi run function for single iteration.<br />
<br />
But it was run manually three times.<br />
;batch 0 <br />
:weeks until "usefullness": 82, 51, 69<br />
:records created in db: 44, 40, 55<br />
<br />
;batch 10<br />
:weeks: 21, 33, 21<br />
:records: 21, 26, 19 <br />
<br />
;batch 30<br />
:weeks: 24, 21, 22<br />
:records: 26, 17, 18<br />
<br />
;batch 50<br />
:weeks: 21, 21, 21<br />
:records: 30, 18, 27<br />
<br />
It appears that the batch upload in the beginning realy speeds up the time required for the database to be considered usefull, but unfortunately the implementation can not ends earlier then after at least small fixed timeframe.<br />
Its obvious that the results are heavily influenced by the randomness in the model.<br />
<br />
It seems that the first small batch upload has the largest influence on the resulting values and larger batches brings only relatively smaller improvements, that suggests to use the batch upload in real life, but its redundant to focus on optimizing the upload process for larger amounts, because they are not needed and only small amount of records (10) is enough to significantly boost the speed of populating.<br />
<br />
==Multi run==<br />
;batch 0<br />
:weeks: [55, 72, 70, 78, 94, 114, 126, 120, 135, 140, 152, 156, 180, 161, 167]<br />
:records: [32, 129, 108, 195, 262, 316, 320, 308, 366, 373, 432, 442, 496, 486, 487]<br />
<br />
;batch 10<br />
:weeks: [35, 99, 99, 189, 249, 291, 298, 413, 413, 426, 452, 433, 471, 520, 564]<br />
:records: [35, 48, 43, 90, 93, 112, 116, 148, 133, 141, 143, 155, 163, 158, 188]<br />
<br />
;batch 30<br />
:weeks: [21, 67, 79, 105, 99, 97, 115, 132, 137, 149, 160, 158, 170, 178, 181]<br />
:records: [13, 170, 200, 227, 272, 254, 336, 316, 406, 423, 442, 415, 464, 496, 521]<br />
<br />
;batch 50<br />
:weeks: [33, 21, 82, 83, 91, 113, 123, 149, 145, 144, 152, 166, 164, 175, 192]<br />
:records: [58, 42, 187, 247, 271, 306, 331, 365, 397, 413, 468, 502, 495, 507, 540]<br />
<br />
Well, those are here just for fun because there is not much value in such results except for showing something does not work as expected.<br />
<br />
=Discussion=<br />
In this simulation I managed to create heavily simplified model of database populating process in our boy scouts group.<br />
<br />
Therefore the resuls appears to be approximately as they should, but they lack on the reliability if they should be used as a base for a decision.<br />
At most I can take a hint about the amount of records to batch upload. That relatively small amount makes a major difference.<br />
<br />
=Code=<br />
This is my code on github, because I could not upload .jl file and a did not wanted to make zip: [https://raw.githubusercontent.com/simik394/simulace-populatingskautdb/refs/heads/main/simulace-nobatch.jl]<br />
<br />
And the home repo [https://github.com/simik394/simulace-populatingskautdb]<br />
<br />
[[User:Tros01|Tros01]] ([[User talk:Tros01|talk]]) 22:19, 19 January 2025 (CET)</div>Tros01http://www.simulace.info/index.php?title=Populating_the_database&diff=26548Populating the database2025-01-19T23:47:29Z<p>Tros01: /* Single run */</p>
<hr />
<div>Úvodní odstavec<br />
<br />
=Problem definition=<br />
==Why?==<br />
Lets say that I have a database containing prepared activities and educational content for boy scouts group. Its purpose is to serve as a source of inspiration and eventually of collection of high quality content appropriate for kids during our weekly meetings or other occasions. From which source should be easy to get precisely only the desired results based on defined properties on each activity (eg. time needed for preparation, minimal number of players, etc.)<br />
<br />
BUT actually its currently more like a proof of concept and not a really operational tool. So accordingly there aren't yet any real records to speak about.<br />
This very early stage of development is exactly the reason why I think it is reasonable to think about how will the database be populated with data. As this will be crucial for its future usability and success. Therefore, the simulation should focus on modeling this data population process.<br />
==What?==<br />
To be precise, the simulation will be concerned with user behavior and related volume of stored records.<br />
<br />
It is important to say that user interface for reading is only the default web gui of the database itself (Neo4j), so the users will have to use the Cypher query language. So after they go through such a way to access the records, there better be some decent amount of useful ones in the database. This is because otherwise their whole effort would be pointless and the user would be discouraged from using the database again.<br />
<br />
Creating the records on the other hand will be easy and accessible as much as possible (user writes to google document in specified folder and with specified structure which enables then loading it programmaticaly into the database). This ease of creation is key to encouraging consistent contributions.<br />
<br />
And here comes the question whether this "natural" way of data population is enough, or rather how long will it take for the database to be able to provide satisfactory results for the user in majority of the cases and as such could be called a useful tool. If the time required would be too long, the users could lose interest of even contributing new content .<br />
Therefore, the simulation will model the rate of content creation and the subsequent impact on database searchability and usability.<br />
<br />
Additionally will be also evaluated the "batch population approach" to see weather it is worth considering to implement. This will involve creating a model of user behavior and content creation, simulating different scenarios, and analyzing the results.<br />
==Objectives==<br />
This simulation aims to predict the growth of the database, determine the feasibility of the current data population strategy and evaluate the alternative.<br />
<br />
#Predict the time needed to reach a critical mass of data sufficient for effective use.<br />
#Evaluate the effectiveness of the current data population method relatively to alternative.<br />
<br />
=Method=<br />
==Agent-based model==<br />
The core method used for this simulation is agent-based modeling (ABM). This approach was selected because it aligns well with the nature of the problem, which involves multiple individual users (agents) interacting with a shared environment (the database). Specifically, it enabled me to simulate:<br />
<br />
*Individual User Behaviors: Each agent acts independently, deciding whether to search the database, create a new record, or improve existing ones, based on their local information and probabilities.<br />
*Heterogeneity (Limited): While the agents initially are identical, they change during the simulation based on their interactions with the database.<br />
*Emergent System Behavior: The overall growth and usability of the database is not programmed directly, but emerges from the accumulation of individual actions.<br />
<br />
Alternatively the system dynamics or simple math equations could be used but neither of them would be more fitting for this usecase.<br />
While system dynamics could model the overall growth of the database as a system, it would not provide the same level of detail regarding individual user actions. System dynamics works well when dealing with aggregate levels and rates of change but isn't great for capturing how each agent behaviour individually impacts the system.<br />
<br />
Just as the equations could model a simplified database growth equation, but it would be extremely difficult to derive a model which includes agents success/fail feedback, record improvement and cooldown and thus it was not considered as applicable for this problem.<br />
==Julia==<br />
Because the ABM approach was chosen the NetLogo was concidered as environment for implemantation of the simulation, but also was the language Julia as it is also often used for simulations. In the end the Julia was chosen because of its more general usability and therefore more usecases when learned to use.<br />
<br />
The simulation is implemented in Julia using the Distributions, StatsBase, and Logging packages.<br />
Logging is enabled to output data about records, agents and overall progress of simulation to a log file called simulation.log.<br />
<br />
Plots are used for visualization and stored as *.png files.<br />
<br />
=Model=<br />
<br />
==Entities==<br />
;Database (db):<br />
A dictionary storing Record objects, categorized by integers representing different activity categories.<br />
*The keys of the dictionary are integers representing category id.<br />
*Each category is associated with a vector (array) of Record objects.<br />
*Initially, each category has an empty vector, which can be populated by new records.<br />
<br />
;Record:<br />
A struct containing:<br />
*id (Integer): A unique identifier for the record, auto-incrementing with each creation.<br />
*quality (Float64): Represents the perceived quality or usability of the record. <br />
<br />
(Originally it should more closely resamble the real live improvements by being represented by only range 1-10 as the real live records also can not be improved infinitelly, but in the end there was left simplier implemantation that just has a chance to improve the record during every picked to use event by random value withou top limit.)<br />
<br />
;Agent:<br />
A struct representing a user of the database.<br />
*probabilityToSearch (Float64): The agent's current probability of finding a useful record, it is based on past success of the agent when searching the db. This parameter influences agent's decision whether to search the db or not.<br />
*used (Dict{Int, Vector{Int}}): A dictionary that stores which record IDs have been used by agent and in which week the record has been used, so it won't be used by the same agent during a given cooldown period. Keys are record ids and values are vectors containing week integers in which the record has been used.<br />
<br />
==Variables==<br />
;NUM_AGENTS: <br />
: Integer representing the number of agents (users) participating in the simulation. Value is fixed at 3.<br />
;BATCH_UPLOAD_SIZES:<br />
: Vector of integers representing different sizes of initial record batches uploaded to the database. The values used in simulation are [0, 10].<br />
;initialQualityDist: <br />
: A lognormal distribution (LogNormal(3, 2)) used to generate the initial quality of new records. The mean is set to 3, and the standard deviation is set to 2, meaning the typical quality of created record will be around 3, but there could be some with higher or lower.<br />
;qualityImprovementProb<br />
: Float64 representing the probability that an agent will improve a record's quality after using it. Value is fixed at 0.7 for the sake of simplicity and simulation feasibility.<br />
;recordCreationProb<br />
: Float64 representing the probability that an agent creates a new record when they are preparing an activity and decide not to search the database. Value is fixed at 0.3 for the sake of simplicity and simulation feasibility.<br />
;categories<br />
: Vector of integer representing the category ids of the db records. The vector is generated as range from 1 to 20, [1:20;].<br />
;targetSuccessfulness<br />
: Float64 value, which represents minimum success rate, that needs to be reached for the database to be considered "useful" in a long term. Value is 0.75.<br />
;nSuccessfullFromEpisode<br />
: An integer number representing how many successful searches per episode of the simulation have to occur in order for it to be considered "useful". Value is 4.<br />
;episodeLength<br />
: Integer which represents length of a one "episode" within the simulation, which in this case is a sequence of weeks for which the success rate of the db will be tested if it met required conditions. Value is set to 6, this means 6 weeks.<br />
<br />
==Flow==<br />
'''1.Initialization:'''<br />
<br />
*The database is created with empty vectors of records for each defined category (integer from 1 to 20).<br />
*A defined number of agents are created with default probabilityToSearch.<br />
*Optionally, a number of initial Record objects will be created (based on parameter BATCH_UPLOAD_SIZE), and randomly assigned to a random category within the database.<br />
<br />
'''2.Weekly Cycle (One Tick):'''<br />
<br />
*Each week (tick), each agent attempts to prepare an activity.<br />
*Each agent selects a random category.<br />
*Then each agent decides whether to search the database based on their current probabilityToSearch (It was originally designed to be able to dynamicaly calculate probabilityToSearch of agents independently, but for the same reason the recordCreationProb is global to all agents, also this variable was left the same for all agents).<br />
<br />
;Search Behavior:<br />
<br />
*If the agent decides to search, it looks up all records that matches it selected category.<br />
*If records are found, the agents samples without replacement a predefined number of records for evaluation. Each has different probability based on its quality. The more quality it has, the higher the probability to be chosen. (Weights are calculated like this [rec.quality / sum(r.quality for r in records) for rec in records])<br />
*An agent tries to pick for use randomly one record from those records. <br />
*Before the agent uses any of the found records, there has to be checked if they haven't been used in a defined "cooldown period", which is set to 54 weeks. Each agent keeps track of used records and the weeks where they where used.<br />
*If the record the agent tries to pick is on cooldown, the agent proceeds to trying another one from the sampled ones until it finds a cooled down one or until there are no more samples (usually in the beginning of the simulation when there are yot not created record in the db).<br />
*If the record is used, there is a probability of the agent improving the quality of that used record.<br />
<br />
;Record Creation Behavior:<br />
<br />
*If the agent decides not to search or if the search is unsuccessful, it has a chance of creating a new record (based on parameter recordCreationProb).<br />
*If a new record is created, it's assigned a randomly generated initial quality based on the lognormal distribution, and pushed to db under it's selected category.<br />
*Also there is kept record of total number oc record created so far during the simulation and the order number of each record is assigned to the record during its creation as its id. This way its possible to keep track of which records were used before by the given agent.<br />
<br />
'''3.Evaluation'''<br />
*Further the simulation tracks total search attempts and successes. The success is considered only when a record is successfully used for an activity and not when a record is found or searched for.<br />
*At the end of each week, a weekly success rate is calculated by dividing the amount of successful record usages by the number of attempts that were performed.<br />
*The simulation continues until the database has reached "sufficient" usability.<br />
*A database is considered as "sufficiently useful" when success rates in a defined episode length (6 weeks) are over a defined threshold (75%) for a given minimum number of successful weeks (4 out of 6). In other words, when this condition is met within a 3 month timeframe.<br />
<br />
==Limitations==<br />
<br />
*Simplified Categories: The categories used in the model are represented by integers and lack any explicit meaning. It was intended to use a combination of string as category representation, but the complexity has no effect on the results, therefore integer representation is used to make code simpler.<br />
*Agent Uniformity: Each agent has an identical recordCreationProb which is not realistic, and does not model different level of contributing to the db.<br />
*Fixed Parameters: Many model parameters, such as qualityImprovementProb, recordCreationProb, NUM_AGENTS are fixed values and don't change during simulation, which makes the simulation a bit static.<br />
*Single Activity Per Week: Each agent prepares only one activity per week, which may be an oversimplification of real user behavior.<br />
*Limited Complexity: The simulation lacks a deeper understanding of how records relate to each other or have a more diverse properties than just an "quality".<br />
<br />
=Results=<br />
In the last section of appended code there was realized an attempt to calculate the results simply by adding new function which whould call the main simulation given number of times and recorded the results so the variability caused by randomness could be viewed. Specifically how the required number of weeks and number of created records varied when running the simulation repeatedly.<br />
<br />
Unfortunately there has been some enexpected and probably undesired patterns occuring in the obtained "multi run" results. Most likely a skillissue on my side. Further elaboration follows.<br />
<br />
Also there is a bug/feature with my function which determines when the search process is successfull enough. Because i require certain amount of time to assess the stability of said successfullness, there is a minimal but fixed timeframe in the begining of the simulation. And because of this when the number of weeks required for the system to be recognized as usefull is measured, its value can not begin earlier than after said timeframe, so that is why the smallest number of weeks in the results are 21.<br />
<br />
Also the counter of created records does not count the records created via batch upload so when reading it needs to be kept in mind.<br />
<br />
Also in the github repository with code, there are plots showing how the successrate evolves in time.<br />
==Single run==<br />
This means runing the multi run function for single iteration.<br />
<br />
But it was run manually three times.<br />
;batch 0 <br />
:weeks until "usefullness": 82, 51, 69<br />
:records created in db: 44, 40, 55<br />
<br />
;batch 10<br />
:weeks: 21, 33, 21<br />
:records: 21, 26, 19 <br />
<br />
;batch 30<br />
:weeks: 24, 21, 22<br />
:records: 26, 17, 18<br />
<br />
;batch 50<br />
:weeks: 21, 21, 21<br />
:records: 30, 18, 27<br />
<br />
It appears that the batch upload in the beginning realy speeds up the time required for the database to be considered usefull, but unfortunately the implementation can not ends earlier then after at least small fixed timeframe.<br />
Its obvious that the results are heavily influenced by the randomness in the model.<br />
<br />
It seems that the first small batch upload has the largest influence on the resulting values and larger batches brings only relatively smaller improvements, that suggests to use the batch upload in real life, but its redundant to focus on optimizing the upload process for larger amounts, because they are not needed and only small amount of records (10) is enough to significantly boost the speed of populating.<br />
<br />
==Multi run==<br />
;batch 0<br />
:weeks: [55, 72, 70, 78, 94, 114, 126, 120, 135, 140, 152, 156, 180, 161, 167]<br />
:records: [32, 129, 108, 195, 262, 316, 320, 308, 366, 373, 432, 442, 496, 486, 487]<br />
<br />
;batch 10<br />
:weeks: [35, 99, 99, 189, 249, 291, 298, 413, 413, 426, 452, 433, 471, 520, 564]<br />
:records: [35, 48, 43, 90, 93, 112, 116, 148, 133, 141, 143, 155, 163, 158, 188]<br />
<br />
;batch 30<br />
:weeks: [21, 67, 79, 105, 99, 97, 115, 132, 137, 149, 160, 158, 170, 178, 181]<br />
:records: [13, 170, 200, 227, 272, 254, 336, 316, 406, 423, 442, 415, 464, 496, 521]<br />
<br />
;batch 50<br />
:weeks: [33, 21, 82, 83, 91, 113, 123, 149, 145, 144, 152, 166, 164, 175, 192]<br />
:records: [58, 42, 187, 247, 271, 306, 331, 365, 397, 413, 468, 502, 495, 507, 540]<br />
<br />
Well, those are here just for fun because there is not much value in such results except for showing something does not work as expected.<br />
<br />
=Discussion=<br />
In this simulation I managed to create heavily simplified model of database populating process in our boy scouts group.<br />
<br />
Therefore the resuls appears to be approximately as they should, but they lack on the reliability if they should be used as a base for a decision.<br />
<br />
=Code=<br />
This is my code on github, because I could not upload .jl file and a did not wanted to make zip: [https://raw.githubusercontent.com/simik394/simulace-populatingskautdb/refs/heads/main/simulace-nobatch.jl]<br />
<br />
And the home repo [https://github.com/simik394/simulace-populatingskautdb]<br />
<br />
[[User:Tros01|Tros01]] ([[User talk:Tros01|talk]]) 22:19, 19 January 2025 (CET)</div>Tros01http://www.simulace.info/index.php?title=Populating_the_database&diff=26547Populating the database2025-01-19T23:40:09Z<p>Tros01: /* Julia */</p>
<hr />
<div>Úvodní odstavec<br />
<br />
=Problem definition=<br />
==Why?==<br />
Lets say that I have a database containing prepared activities and educational content for boy scouts group. Its purpose is to serve as a source of inspiration and eventually of collection of high quality content appropriate for kids during our weekly meetings or other occasions. From which source should be easy to get precisely only the desired results based on defined properties on each activity (eg. time needed for preparation, minimal number of players, etc.)<br />
<br />
BUT actually its currently more like a proof of concept and not a really operational tool. So accordingly there aren't yet any real records to speak about.<br />
This very early stage of development is exactly the reason why I think it is reasonable to think about how will the database be populated with data. As this will be crucial for its future usability and success. Therefore, the simulation should focus on modeling this data population process.<br />
==What?==<br />
To be precise, the simulation will be concerned with user behavior and related volume of stored records.<br />
<br />
It is important to say that user interface for reading is only the default web gui of the database itself (Neo4j), so the users will have to use the Cypher query language. So after they go through such a way to access the records, there better be some decent amount of useful ones in the database. This is because otherwise their whole effort would be pointless and the user would be discouraged from using the database again.<br />
<br />
Creating the records on the other hand will be easy and accessible as much as possible (user writes to google document in specified folder and with specified structure which enables then loading it programmaticaly into the database). This ease of creation is key to encouraging consistent contributions.<br />
<br />
And here comes the question whether this "natural" way of data population is enough, or rather how long will it take for the database to be able to provide satisfactory results for the user in majority of the cases and as such could be called a useful tool. If the time required would be too long, the users could lose interest of even contributing new content .<br />
Therefore, the simulation will model the rate of content creation and the subsequent impact on database searchability and usability.<br />
<br />
Additionally will be also evaluated the "batch population approach" to see weather it is worth considering to implement. This will involve creating a model of user behavior and content creation, simulating different scenarios, and analyzing the results.<br />
==Objectives==<br />
This simulation aims to predict the growth of the database, determine the feasibility of the current data population strategy and evaluate the alternative.<br />
<br />
#Predict the time needed to reach a critical mass of data sufficient for effective use.<br />
#Evaluate the effectiveness of the current data population method relatively to alternative.<br />
<br />
=Method=<br />
==Agent-based model==<br />
The core method used for this simulation is agent-based modeling (ABM). This approach was selected because it aligns well with the nature of the problem, which involves multiple individual users (agents) interacting with a shared environment (the database). Specifically, it enabled me to simulate:<br />
<br />
*Individual User Behaviors: Each agent acts independently, deciding whether to search the database, create a new record, or improve existing ones, based on their local information and probabilities.<br />
*Heterogeneity (Limited): While the agents initially are identical, they change during the simulation based on their interactions with the database.<br />
*Emergent System Behavior: The overall growth and usability of the database is not programmed directly, but emerges from the accumulation of individual actions.<br />
<br />
Alternatively the system dynamics or simple math equations could be used but neither of them would be more fitting for this usecase.<br />
While system dynamics could model the overall growth of the database as a system, it would not provide the same level of detail regarding individual user actions. System dynamics works well when dealing with aggregate levels and rates of change but isn't great for capturing how each agent behaviour individually impacts the system.<br />
<br />
Just as the equations could model a simplified database growth equation, but it would be extremely difficult to derive a model which includes agents success/fail feedback, record improvement and cooldown and thus it was not considered as applicable for this problem.<br />
==Julia==<br />
Because the ABM approach was chosen the NetLogo was concidered as environment for implemantation of the simulation, but also was the language Julia as it is also often used for simulations. In the end the Julia was chosen because of its more general usability and therefore more usecases when learned to use.<br />
<br />
The simulation is implemented in Julia using the Distributions, StatsBase, and Logging packages.<br />
Logging is enabled to output data about records, agents and overall progress of simulation to a log file called simulation.log.<br />
<br />
Plots are used for visualization and stored as *.png files.<br />
<br />
=Model=<br />
<br />
==Entities==<br />
;Database (db):<br />
A dictionary storing Record objects, categorized by integers representing different activity categories.<br />
*The keys of the dictionary are integers representing category id.<br />
*Each category is associated with a vector (array) of Record objects.<br />
*Initially, each category has an empty vector, which can be populated by new records.<br />
<br />
;Record:<br />
A struct containing:<br />
*id (Integer): A unique identifier for the record, auto-incrementing with each creation.<br />
*quality (Float64): Represents the perceived quality or usability of the record. <br />
<br />
(Originally it should more closely resamble the real live improvements by being represented by only range 1-10 as the real live records also can not be improved infinitelly, but in the end there was left simplier implemantation that just has a chance to improve the record during every picked to use event by random value withou top limit.)<br />
<br />
;Agent:<br />
A struct representing a user of the database.<br />
*probabilityToSearch (Float64): The agent's current probability of finding a useful record, it is based on past success of the agent when searching the db. This parameter influences agent's decision whether to search the db or not.<br />
*used (Dict{Int, Vector{Int}}): A dictionary that stores which record IDs have been used by agent and in which week the record has been used, so it won't be used by the same agent during a given cooldown period. Keys are record ids and values are vectors containing week integers in which the record has been used.<br />
<br />
==Variables==<br />
;NUM_AGENTS: <br />
: Integer representing the number of agents (users) participating in the simulation. Value is fixed at 3.<br />
;BATCH_UPLOAD_SIZES:<br />
: Vector of integers representing different sizes of initial record batches uploaded to the database. The values used in simulation are [0, 10].<br />
;initialQualityDist: <br />
: A lognormal distribution (LogNormal(3, 2)) used to generate the initial quality of new records. The mean is set to 3, and the standard deviation is set to 2, meaning the typical quality of created record will be around 3, but there could be some with higher or lower.<br />
;qualityImprovementProb<br />
: Float64 representing the probability that an agent will improve a record's quality after using it. Value is fixed at 0.7 for the sake of simplicity and simulation feasibility.<br />
;recordCreationProb<br />
: Float64 representing the probability that an agent creates a new record when they are preparing an activity and decide not to search the database. Value is fixed at 0.3 for the sake of simplicity and simulation feasibility.<br />
;categories<br />
: Vector of integer representing the category ids of the db records. The vector is generated as range from 1 to 20, [1:20;].<br />
;targetSuccessfulness<br />
: Float64 value, which represents minimum success rate, that needs to be reached for the database to be considered "useful" in a long term. Value is 0.75.<br />
;nSuccessfullFromEpisode<br />
: An integer number representing how many successful searches per episode of the simulation have to occur in order for it to be considered "useful". Value is 4.<br />
;episodeLength<br />
: Integer which represents length of a one "episode" within the simulation, which in this case is a sequence of weeks for which the success rate of the db will be tested if it met required conditions. Value is set to 6, this means 6 weeks.<br />
<br />
==Flow==<br />
'''1.Initialization:'''<br />
<br />
*The database is created with empty vectors of records for each defined category (integer from 1 to 20).<br />
*A defined number of agents are created with default probabilityToSearch.<br />
*Optionally, a number of initial Record objects will be created (based on parameter BATCH_UPLOAD_SIZE), and randomly assigned to a random category within the database.<br />
<br />
'''2.Weekly Cycle (One Tick):'''<br />
<br />
*Each week (tick), each agent attempts to prepare an activity.<br />
*Each agent selects a random category.<br />
*Then each agent decides whether to search the database based on their current probabilityToSearch (It was originally designed to be able to dynamicaly calculate probabilityToSearch of agents independently, but for the same reason the recordCreationProb is global to all agents, also this variable was left the same for all agents).<br />
<br />
;Search Behavior:<br />
<br />
*If the agent decides to search, it looks up all records that matches it selected category.<br />
*If records are found, the agents samples without replacement a predefined number of records for evaluation. Each has different probability based on its quality. The more quality it has, the higher the probability to be chosen. (Weights are calculated like this [rec.quality / sum(r.quality for r in records) for rec in records])<br />
*An agent tries to pick for use randomly one record from those records. <br />
*Before the agent uses any of the found records, there has to be checked if they haven't been used in a defined "cooldown period", which is set to 54 weeks. Each agent keeps track of used records and the weeks where they where used.<br />
*If the record the agent tries to pick is on cooldown, the agent proceeds to trying another one from the sampled ones until it finds a cooled down one or until there are no more samples (usually in the beginning of the simulation when there are yot not created record in the db).<br />
*If the record is used, there is a probability of the agent improving the quality of that used record.<br />
<br />
;Record Creation Behavior:<br />
<br />
*If the agent decides not to search or if the search is unsuccessful, it has a chance of creating a new record (based on parameter recordCreationProb).<br />
*If a new record is created, it's assigned a randomly generated initial quality based on the lognormal distribution, and pushed to db under it's selected category.<br />
*Also there is kept record of total number oc record created so far during the simulation and the order number of each record is assigned to the record during its creation as its id. This way its possible to keep track of which records were used before by the given agent.<br />
<br />
'''3.Evaluation'''<br />
*Further the simulation tracks total search attempts and successes. The success is considered only when a record is successfully used for an activity and not when a record is found or searched for.<br />
*At the end of each week, a weekly success rate is calculated by dividing the amount of successful record usages by the number of attempts that were performed.<br />
*The simulation continues until the database has reached "sufficient" usability.<br />
*A database is considered as "sufficiently useful" when success rates in a defined episode length (6 weeks) are over a defined threshold (75%) for a given minimum number of successful weeks (4 out of 6). In other words, when this condition is met within a 3 month timeframe.<br />
<br />
==Limitations==<br />
<br />
*Simplified Categories: The categories used in the model are represented by integers and lack any explicit meaning. It was intended to use a combination of string as category representation, but the complexity has no effect on the results, therefore integer representation is used to make code simpler.<br />
*Agent Uniformity: Each agent has an identical recordCreationProb which is not realistic, and does not model different level of contributing to the db.<br />
*Fixed Parameters: Many model parameters, such as qualityImprovementProb, recordCreationProb, NUM_AGENTS are fixed values and don't change during simulation, which makes the simulation a bit static.<br />
*Single Activity Per Week: Each agent prepares only one activity per week, which may be an oversimplification of real user behavior.<br />
*Limited Complexity: The simulation lacks a deeper understanding of how records relate to each other or have a more diverse properties than just an "quality".<br />
<br />
=Results=<br />
In the last section of appended code there was realized an attempt to calculate the results simply by adding new function which whould call the main simulation given number of times and recorded the results so the variability caused by randomness could be viewed. Specifically how the required number of weeks and number of created records varied when running the simulation repeatedly.<br />
<br />
Unfortunately there has been some enexpected and probably undesired patterns occuring in the obtained "multi run" results. Most likely a skillissue on my side. Further elaboration follows.<br />
<br />
Also there is a bug/feature with my function which determines when the search process is successfull enough. Because i require certain amount of time to assess the stability of said successfullness, there is a minimal but fixed timeframe in the begining of the simulation. And because of this when the number of weeks required for the system to be recognized as usefull is measured, its value can not begin earlier than after said timeframe, so that is why the smallest number of weeks in the results are 21.<br />
<br />
Also the counter of created records does not count the records created via batch upload so when reading it needs to be kept in mind.<br />
<br />
Also in the github repository with code, there are plots showing how the successrate evolves in time.<br />
==Single run==<br />
This means runing the multi run function for single iteration.<br />
<br />
But it was run manually three times.<br />
;batch 0 <br />
:weeks until "usefullness": 82, 51, 69<br />
:records created in db: 44, 40, 55<br />
<br />
;batch 10<br />
:weeks: 21, 33, 21<br />
:records: 21, 26, 19 <br />
<br />
;batch 30<br />
:weeks: 24, 21, 22<br />
:records: 26, 17, 18<br />
<br />
;batch 50<br />
:weeks: 21, 21, 21<br />
:records: 30, 18, 27<br />
<br />
It appears that the batch upload in the beginning realy speeds up the time required for the database to be considered usefull, but unfortunately the implementation can not ends earlier then after at least small fixed timeframe.<br />
Its obvious that the results are heavily influenced by the randomness in the model.<br />
<br />
==Multi run==<br />
;batch 0<br />
:weeks: [55, 72, 70, 78, 94, 114, 126, 120, 135, 140, 152, 156, 180, 161, 167]<br />
:records: [32, 129, 108, 195, 262, 316, 320, 308, 366, 373, 432, 442, 496, 486, 487]<br />
<br />
;batch 10<br />
:weeks: [35, 99, 99, 189, 249, 291, 298, 413, 413, 426, 452, 433, 471, 520, 564]<br />
:records: [35, 48, 43, 90, 93, 112, 116, 148, 133, 141, 143, 155, 163, 158, 188]<br />
<br />
;batch 30<br />
:weeks: [21, 67, 79, 105, 99, 97, 115, 132, 137, 149, 160, 158, 170, 178, 181]<br />
:records: [13, 170, 200, 227, 272, 254, 336, 316, 406, 423, 442, 415, 464, 496, 521]<br />
<br />
;batch 50<br />
:weeks: [33, 21, 82, 83, 91, 113, 123, 149, 145, 144, 152, 166, 164, 175, 192]<br />
:records: [58, 42, 187, 247, 271, 306, 331, 365, 397, 413, 468, 502, 495, 507, 540]<br />
<br />
Well, those are here just for fun because there is not much value in such results except for showing something does not work as expected.<br />
<br />
=Discussion=<br />
In this simulation I managed to create heavily simplified model of database populating process in our boy scouts group.<br />
<br />
Therefore the resuls appears to be approximately as they should, but they lack on the reliability if they should be used as a base for a decision.<br />
<br />
=Code=<br />
This is my code on github, because I could not upload .jl file and a did not wanted to make zip: [https://raw.githubusercontent.com/simik394/simulace-populatingskautdb/refs/heads/main/simulace-nobatch.jl]<br />
<br />
And the home repo [https://github.com/simik394/simulace-populatingskautdb]<br />
<br />
[[User:Tros01|Tros01]] ([[User talk:Tros01|talk]]) 22:19, 19 January 2025 (CET)</div>Tros01http://www.simulace.info/index.php?title=Populating_the_database&diff=26546Populating the database2025-01-19T23:38:12Z<p>Tros01: /* Model */</p>
<hr />
<div>Úvodní odstavec<br />
<br />
=Problem definition=<br />
==Why?==<br />
Lets say that I have a database containing prepared activities and educational content for boy scouts group. Its purpose is to serve as a source of inspiration and eventually of collection of high quality content appropriate for kids during our weekly meetings or other occasions. From which source should be easy to get precisely only the desired results based on defined properties on each activity (eg. time needed for preparation, minimal number of players, etc.)<br />
<br />
BUT actually its currently more like a proof of concept and not a really operational tool. So accordingly there aren't yet any real records to speak about.<br />
This very early stage of development is exactly the reason why I think it is reasonable to think about how will the database be populated with data. As this will be crucial for its future usability and success. Therefore, the simulation should focus on modeling this data population process.<br />
==What?==<br />
To be precise, the simulation will be concerned with user behavior and related volume of stored records.<br />
<br />
It is important to say that user interface for reading is only the default web gui of the database itself (Neo4j), so the users will have to use the Cypher query language. So after they go through such a way to access the records, there better be some decent amount of useful ones in the database. This is because otherwise their whole effort would be pointless and the user would be discouraged from using the database again.<br />
<br />
Creating the records on the other hand will be easy and accessible as much as possible (user writes to google document in specified folder and with specified structure which enables then loading it programmaticaly into the database). This ease of creation is key to encouraging consistent contributions.<br />
<br />
And here comes the question whether this "natural" way of data population is enough, or rather how long will it take for the database to be able to provide satisfactory results for the user in majority of the cases and as such could be called a useful tool. If the time required would be too long, the users could lose interest of even contributing new content .<br />
Therefore, the simulation will model the rate of content creation and the subsequent impact on database searchability and usability.<br />
<br />
Additionally will be also evaluated the "batch population approach" to see weather it is worth considering to implement. This will involve creating a model of user behavior and content creation, simulating different scenarios, and analyzing the results.<br />
==Objectives==<br />
This simulation aims to predict the growth of the database, determine the feasibility of the current data population strategy and evaluate the alternative.<br />
<br />
#Predict the time needed to reach a critical mass of data sufficient for effective use.<br />
#Evaluate the effectiveness of the current data population method relatively to alternative.<br />
<br />
=Method=<br />
==Agent-based model==<br />
The core method used for this simulation is agent-based modeling (ABM). This approach was selected because it aligns well with the nature of the problem, which involves multiple individual users (agents) interacting with a shared environment (the database). Specifically, it enabled me to simulate:<br />
<br />
*Individual User Behaviors: Each agent acts independently, deciding whether to search the database, create a new record, or improve existing ones, based on their local information and probabilities.<br />
*Heterogeneity (Limited): While the agents initially are identical, they change during the simulation based on their interactions with the database.<br />
*Emergent System Behavior: The overall growth and usability of the database is not programmed directly, but emerges from the accumulation of individual actions.<br />
<br />
Alternatively the system dynamics or simple math equations could be used but neither of them would be more fitting for this usecase.<br />
While system dynamics could model the overall growth of the database as a system, it would not provide the same level of detail regarding individual user actions. System dynamics works well when dealing with aggregate levels and rates of change but isn't great for capturing how each agent behaviour individually impacts the system.<br />
<br />
Just as the equations could model a simplified database growth equation, but it would be extremely difficult to derive a model which includes agents success/fail feedback, record improvement and cooldown and thus it was not considered as applicable for this problem.<br />
==Julia==<br />
Because the ABM approach was chosen the NetLogo was concidered as environment for implemantation of the simulation, but also was the language Julia as it is also often used for simulations. In the end the Julia was chosen because of its more general usability and therefore more usecases when learned to use.<br />
<br />
diskuse možností řešení, výběr metody a prostředku (metod a prostředků) řešení, zdůvodnění výběru (jinými slovy, proč to chcete řešit tak, jak to chcete řešit, jaké jsou jiné alternativy a proč je ta Vámi zvolená pro tuto úlohu nejvhodnější)<br />
<br />
=Model=<br />
<br />
==Entities==<br />
;Database (db):<br />
A dictionary storing Record objects, categorized by integers representing different activity categories.<br />
*The keys of the dictionary are integers representing category id.<br />
*Each category is associated with a vector (array) of Record objects.<br />
*Initially, each category has an empty vector, which can be populated by new records.<br />
<br />
;Record:<br />
A struct containing:<br />
*id (Integer): A unique identifier for the record, auto-incrementing with each creation.<br />
*quality (Float64): Represents the perceived quality or usability of the record. <br />
<br />
(Originally it should more closely resamble the real live improvements by being represented by only range 1-10 as the real live records also can not be improved infinitelly, but in the end there was left simplier implemantation that just has a chance to improve the record during every picked to use event by random value withou top limit.)<br />
<br />
;Agent:<br />
A struct representing a user of the database.<br />
*probabilityToSearch (Float64): The agent's current probability of finding a useful record, it is based on past success of the agent when searching the db. This parameter influences agent's decision whether to search the db or not.<br />
*used (Dict{Int, Vector{Int}}): A dictionary that stores which record IDs have been used by agent and in which week the record has been used, so it won't be used by the same agent during a given cooldown period. Keys are record ids and values are vectors containing week integers in which the record has been used.<br />
<br />
==Variables==<br />
;NUM_AGENTS: <br />
: Integer representing the number of agents (users) participating in the simulation. Value is fixed at 3.<br />
;BATCH_UPLOAD_SIZES:<br />
: Vector of integers representing different sizes of initial record batches uploaded to the database. The values used in simulation are [0, 10].<br />
;initialQualityDist: <br />
: A lognormal distribution (LogNormal(3, 2)) used to generate the initial quality of new records. The mean is set to 3, and the standard deviation is set to 2, meaning the typical quality of created record will be around 3, but there could be some with higher or lower.<br />
;qualityImprovementProb<br />
: Float64 representing the probability that an agent will improve a record's quality after using it. Value is fixed at 0.7 for the sake of simplicity and simulation feasibility.<br />
;recordCreationProb<br />
: Float64 representing the probability that an agent creates a new record when they are preparing an activity and decide not to search the database. Value is fixed at 0.3 for the sake of simplicity and simulation feasibility.<br />
;categories<br />
: Vector of integer representing the category ids of the db records. The vector is generated as range from 1 to 20, [1:20;].<br />
;targetSuccessfulness<br />
: Float64 value, which represents minimum success rate, that needs to be reached for the database to be considered "useful" in a long term. Value is 0.75.<br />
;nSuccessfullFromEpisode<br />
: An integer number representing how many successful searches per episode of the simulation have to occur in order for it to be considered "useful". Value is 4.<br />
;episodeLength<br />
: Integer which represents length of a one "episode" within the simulation, which in this case is a sequence of weeks for which the success rate of the db will be tested if it met required conditions. Value is set to 6, this means 6 weeks.<br />
<br />
==Flow==<br />
'''1.Initialization:'''<br />
<br />
*The database is created with empty vectors of records for each defined category (integer from 1 to 20).<br />
*A defined number of agents are created with default probabilityToSearch.<br />
*Optionally, a number of initial Record objects will be created (based on parameter BATCH_UPLOAD_SIZE), and randomly assigned to a random category within the database.<br />
<br />
'''2.Weekly Cycle (One Tick):'''<br />
<br />
*Each week (tick), each agent attempts to prepare an activity.<br />
*Each agent selects a random category.<br />
*Then each agent decides whether to search the database based on their current probabilityToSearch (It was originally designed to be able to dynamicaly calculate probabilityToSearch of agents independently, but for the same reason the recordCreationProb is global to all agents, also this variable was left the same for all agents).<br />
<br />
;Search Behavior:<br />
<br />
*If the agent decides to search, it looks up all records that matches it selected category.<br />
*If records are found, the agents samples without replacement a predefined number of records for evaluation. Each has different probability based on its quality. The more quality it has, the higher the probability to be chosen. (Weights are calculated like this [rec.quality / sum(r.quality for r in records) for rec in records])<br />
*An agent tries to pick for use randomly one record from those records. <br />
*Before the agent uses any of the found records, there has to be checked if they haven't been used in a defined "cooldown period", which is set to 54 weeks. Each agent keeps track of used records and the weeks where they where used.<br />
*If the record the agent tries to pick is on cooldown, the agent proceeds to trying another one from the sampled ones until it finds a cooled down one or until there are no more samples (usually in the beginning of the simulation when there are yot not created record in the db).<br />
*If the record is used, there is a probability of the agent improving the quality of that used record.<br />
<br />
;Record Creation Behavior:<br />
<br />
*If the agent decides not to search or if the search is unsuccessful, it has a chance of creating a new record (based on parameter recordCreationProb).<br />
*If a new record is created, it's assigned a randomly generated initial quality based on the lognormal distribution, and pushed to db under it's selected category.<br />
*Also there is kept record of total number oc record created so far during the simulation and the order number of each record is assigned to the record during its creation as its id. This way its possible to keep track of which records were used before by the given agent.<br />
<br />
'''3.Evaluation'''<br />
*Further the simulation tracks total search attempts and successes. The success is considered only when a record is successfully used for an activity and not when a record is found or searched for.<br />
*At the end of each week, a weekly success rate is calculated by dividing the amount of successful record usages by the number of attempts that were performed.<br />
*The simulation continues until the database has reached "sufficient" usability.<br />
*A database is considered as "sufficiently useful" when success rates in a defined episode length (6 weeks) are over a defined threshold (75%) for a given minimum number of successful weeks (4 out of 6). In other words, when this condition is met within a 3 month timeframe.<br />
<br />
==Limitations==<br />
<br />
*Simplified Categories: The categories used in the model are represented by integers and lack any explicit meaning. It was intended to use a combination of string as category representation, but the complexity has no effect on the results, therefore integer representation is used to make code simpler.<br />
*Agent Uniformity: Each agent has an identical recordCreationProb which is not realistic, and does not model different level of contributing to the db.<br />
*Fixed Parameters: Many model parameters, such as qualityImprovementProb, recordCreationProb, NUM_AGENTS are fixed values and don't change during simulation, which makes the simulation a bit static.<br />
*Single Activity Per Week: Each agent prepares only one activity per week, which may be an oversimplification of real user behavior.<br />
*Limited Complexity: The simulation lacks a deeper understanding of how records relate to each other or have a more diverse properties than just an "quality".<br />
<br />
=Results=<br />
In the last section of appended code there was realized an attempt to calculate the results simply by adding new function which whould call the main simulation given number of times and recorded the results so the variability caused by randomness could be viewed. Specifically how the required number of weeks and number of created records varied when running the simulation repeatedly.<br />
<br />
Unfortunately there has been some enexpected and probably undesired patterns occuring in the obtained "multi run" results. Most likely a skillissue on my side. Further elaboration follows.<br />
<br />
Also there is a bug/feature with my function which determines when the search process is successfull enough. Because i require certain amount of time to assess the stability of said successfullness, there is a minimal but fixed timeframe in the begining of the simulation. And because of this when the number of weeks required for the system to be recognized as usefull is measured, its value can not begin earlier than after said timeframe, so that is why the smallest number of weeks in the results are 21.<br />
<br />
Also the counter of created records does not count the records created via batch upload so when reading it needs to be kept in mind.<br />
<br />
Also in the github repository with code, there are plots showing how the successrate evolves in time.<br />
==Single run==<br />
This means runing the multi run function for single iteration.<br />
<br />
But it was run manually three times.<br />
;batch 0 <br />
:weeks until "usefullness": 82, 51, 69<br />
:records created in db: 44, 40, 55<br />
<br />
;batch 10<br />
:weeks: 21, 33, 21<br />
:records: 21, 26, 19 <br />
<br />
;batch 30<br />
:weeks: 24, 21, 22<br />
:records: 26, 17, 18<br />
<br />
;batch 50<br />
:weeks: 21, 21, 21<br />
:records: 30, 18, 27<br />
<br />
It appears that the batch upload in the beginning realy speeds up the time required for the database to be considered usefull, but unfortunately the implementation can not ends earlier then after at least small fixed timeframe.<br />
Its obvious that the results are heavily influenced by the randomness in the model.<br />
<br />
==Multi run==<br />
;batch 0<br />
:weeks: [55, 72, 70, 78, 94, 114, 126, 120, 135, 140, 152, 156, 180, 161, 167]<br />
:records: [32, 129, 108, 195, 262, 316, 320, 308, 366, 373, 432, 442, 496, 486, 487]<br />
<br />
;batch 10<br />
:weeks: [35, 99, 99, 189, 249, 291, 298, 413, 413, 426, 452, 433, 471, 520, 564]<br />
:records: [35, 48, 43, 90, 93, 112, 116, 148, 133, 141, 143, 155, 163, 158, 188]<br />
<br />
;batch 30<br />
:weeks: [21, 67, 79, 105, 99, 97, 115, 132, 137, 149, 160, 158, 170, 178, 181]<br />
:records: [13, 170, 200, 227, 272, 254, 336, 316, 406, 423, 442, 415, 464, 496, 521]<br />
<br />
;batch 50<br />
:weeks: [33, 21, 82, 83, 91, 113, 123, 149, 145, 144, 152, 166, 164, 175, 192]<br />
:records: [58, 42, 187, 247, 271, 306, 331, 365, 397, 413, 468, 502, 495, 507, 540]<br />
<br />
Well, those are here just for fun because there is not much value in such results except for showing something does not work as expected.<br />
<br />
=Discussion=<br />
In this simulation I managed to create heavily simplified model of database populating process in our boy scouts group.<br />
<br />
Therefore the resuls appears to be approximately as they should, but they lack on the reliability if they should be used as a base for a decision.<br />
<br />
=Code=<br />
This is my code on github, because I could not upload .jl file and a did not wanted to make zip: [https://raw.githubusercontent.com/simik394/simulace-populatingskautdb/refs/heads/main/simulace-nobatch.jl]<br />
<br />
And the home repo [https://github.com/simik394/simulace-populatingskautdb]<br />
<br />
[[User:Tros01|Tros01]] ([[User talk:Tros01|talk]]) 22:19, 19 January 2025 (CET)</div>Tros01http://www.simulace.info/index.php?title=Populating_the_database&diff=26545Populating the database2025-01-19T23:34:37Z<p>Tros01: /* Discussion */</p>
<hr />
<div>Úvodní odstavec<br />
<br />
=Problem definition=<br />
==Why?==<br />
Lets say that I have a database containing prepared activities and educational content for boy scouts group. Its purpose is to serve as a source of inspiration and eventually of collection of high quality content appropriate for kids during our weekly meetings or other occasions. From which source should be easy to get precisely only the desired results based on defined properties on each activity (eg. time needed for preparation, minimal number of players, etc.)<br />
<br />
BUT actually its currently more like a proof of concept and not a really operational tool. So accordingly there aren't yet any real records to speak about.<br />
This very early stage of development is exactly the reason why I think it is reasonable to think about how will the database be populated with data. As this will be crucial for its future usability and success. Therefore, the simulation should focus on modeling this data population process.<br />
==What?==<br />
To be precise, the simulation will be concerned with user behavior and related volume of stored records.<br />
<br />
It is important to say that user interface for reading is only the default web gui of the database itself (Neo4j), so the users will have to use the Cypher query language. So after they go through such a way to access the records, there better be some decent amount of useful ones in the database. This is because otherwise their whole effort would be pointless and the user would be discouraged from using the database again.<br />
<br />
Creating the records on the other hand will be easy and accessible as much as possible (user writes to google document in specified folder and with specified structure which enables then loading it programmaticaly into the database). This ease of creation is key to encouraging consistent contributions.<br />
<br />
And here comes the question whether this "natural" way of data population is enough, or rather how long will it take for the database to be able to provide satisfactory results for the user in majority of the cases and as such could be called a useful tool. If the time required would be too long, the users could lose interest of even contributing new content .<br />
Therefore, the simulation will model the rate of content creation and the subsequent impact on database searchability and usability.<br />
<br />
Additionally will be also evaluated the "batch population approach" to see weather it is worth considering to implement. This will involve creating a model of user behavior and content creation, simulating different scenarios, and analyzing the results.<br />
==Objectives==<br />
This simulation aims to predict the growth of the database, determine the feasibility of the current data population strategy and evaluate the alternative.<br />
<br />
#Predict the time needed to reach a critical mass of data sufficient for effective use.<br />
#Evaluate the effectiveness of the current data population method relatively to alternative.<br />
<br />
=Method=<br />
==Agent-based model==<br />
The core method used for this simulation is agent-based modeling (ABM). This approach was selected because it aligns well with the nature of the problem, which involves multiple individual users (agents) interacting with a shared environment (the database). Specifically, it enabled me to simulate:<br />
<br />
*Individual User Behaviors: Each agent acts independently, deciding whether to search the database, create a new record, or improve existing ones, based on their local information and probabilities.<br />
*Heterogeneity (Limited): While the agents initially are identical, they change during the simulation based on their interactions with the database.<br />
*Emergent System Behavior: The overall growth and usability of the database is not programmed directly, but emerges from the accumulation of individual actions.<br />
<br />
Alternatively the system dynamics or simple math equations could be used but neither of them would be more fitting for this usecase.<br />
While system dynamics could model the overall growth of the database as a system, it would not provide the same level of detail regarding individual user actions. System dynamics works well when dealing with aggregate levels and rates of change but isn't great for capturing how each agent behaviour individually impacts the system.<br />
<br />
Just as the equations could model a simplified database growth equation, but it would be extremely difficult to derive a model which includes agents success/fail feedback, record improvement and cooldown and thus it was not considered as applicable for this problem.<br />
==Julia==<br />
Because the ABM approach was chosen the NetLogo was concidered as environment for implemantation of the simulation, but also was the language Julia as it is also often used for simulations. In the end the Julia was chosen because of its more general usability and therefore more usecases when learned to use.<br />
<br />
diskuse možností řešení, výběr metody a prostředku (metod a prostředků) řešení, zdůvodnění výběru (jinými slovy, proč to chcete řešit tak, jak to chcete řešit, jaké jsou jiné alternativy a proč je ta Vámi zvolená pro tuto úlohu nejvhodnější)<br />
<br />
=Model=<br />
<br />
==Entities==<br />
;Database (db):<br />
A dictionary storing Record objects, categorized by integers representing different activity categories.<br />
*The keys of the dictionary are integers representing category id.<br />
*Each category is associated with a vector (array) of Record objects.<br />
*Initially, each category has an empty vector, which can be populated by new records.<br />
<br />
;Record:<br />
A struct containing:<br />
*id (Integer): A unique identifier for the record, auto-incrementing with each creation.<br />
*quality (Float64): Represents the perceived quality or usability of the record. <br />
<br />
(Originally it should more closely resamble the real live improvements by being represented by only range 1-10 as the real live records also can not be improved infinitelly, but in the end there was left simplier implemantation that just has a chance to improve the record during every picked to use event by random value withou top limit.)<br />
<br />
;Agent:<br />
A struct representing a user of the database.<br />
*probabilityToSearch (Float64): The agent's current probability of finding a useful record, it is based on past success of the agent when searching the db. This parameter influences agent's decision whether to search the db or not.<br />
*used (Dict{Int, Vector{Int}}): A dictionary that stores which record IDs have been used by agent and in which week the record has been used, so it won't be used by the same agent during a given cooldown period. Keys are record ids and values are vectors containing week integers in which the record has been used.<br />
<br />
==Variables==<br />
;NUM_AGENTS: <br />
: Integer representing the number of agents (users) participating in the simulation. Value is fixed at 3.<br />
;BATCH_UPLOAD_SIZES:<br />
: Vector of integers representing different sizes of initial record batches uploaded to the database. The values used in simulation are [0, 10].<br />
;initialQualityDist: <br />
: A lognormal distribution (LogNormal(3, 2)) used to generate the initial quality of new records. The mean is set to 3, and the standard deviation is set to 2, meaning the typical quality of created record will be around 3, but there could be some with higher or lower.<br />
;qualityImprovementProb<br />
: Float64 representing the probability that an agent will improve a record's quality after using it. Value is fixed at 0.7 for the sake of simplicity and simulation feasibility.<br />
;recordCreationProb<br />
: Float64 representing the probability that an agent creates a new record when they are preparing an activity and decide not to search the database. Value is fixed at 0.3 for the sake of simplicity and simulation feasibility.<br />
;categories<br />
: Vector of integer representing the category ids of the db records. The vector is generated as range from 1 to 20, [1:20;].<br />
;targetSuccessfulness<br />
: Float64 value, which represents minimum success rate, that needs to be reached for the database to be considered "useful" in a long term. Value is 0.75.<br />
;nSuccessfullFromEpisode<br />
: An integer number representing how many successful searches per episode of the simulation have to occur in order for it to be considered "useful". Value is 4.<br />
;episodeLength<br />
: Integer which represents length of a one "episode" within the simulation, which in this case is a sequence of weeks for which the success rate of the db will be tested if it met required conditions. Value is set to 6, this means 6 weeks.<br />
<br />
==Flow==<br />
'''1.Initialization:'''<br />
<br />
*The database is created with empty vectors of records for each defined category (integer from 1 to 20).<br />
*A defined number of agents are created with default probabilityToSearch.<br />
*Optionally, a number of initial Record objects will be created (based on parameter BATCH_UPLOAD_SIZE), and randomly assigned to a random category within the database.<br />
<br />
'''2.Weekly Cycle (One Tick):'''<br />
<br />
*Each week (tick), each agent attempts to prepare an activity.<br />
*Each agent selects a random category.<br />
*Then each agent decides whether to search the database based on their current probabilityToSearch (It was originally designed to be able to dynamicaly calculate probabilityToSearch of agents independently, but for the same reason the recordCreationProb is global to all agents, also this variable was left the same for all agents).<br />
<br />
;Search Behavior:<br />
<br />
*If the agent decides to search, it looks up all records that matches it selected category.<br />
*If records are found, the agents samples without replacement a predefined number of records for evaluation. Each has different probability based on its quality. The more quality it has, the higher the probability to be chosen. (Weights are calculated like this [rec.quality / sum(r.quality for r in records) for rec in records])<br />
*An agent tries to pick for use randomly one record from those records. <br />
*Before the agent uses any of the found records, there has to be checked if they haven't been used in a defined "cooldown period", which is set to 54 weeks. Each agent keeps track of used records and the weeks where they where used.<br />
*If the record the agent tries to pick is on cooldown, the agent proceeds to trying another one from the sampled ones until it finds a cooled down one or until there are no more samples (usually in the beginning of the simulation when there are yot not created record in the db).<br />
*If the record is used, there is a probability of the agent improving the quality of that used record.<br />
<br />
;Record Creation Behavior:<br />
<br />
*If the agent decides not to search or if the search is unsuccessful, it has a chance of creating a new record (based on parameter recordCreationProb).<br />
*If a new record is created, it's assigned a randomly generated initial quality based on the lognormal distribution, and pushed to db under it's selected category.<br />
*Also there is kept record of total number oc record created so far during the simulation and the order number of each record is assigned to the record during its creation as its id. This way its possible to keep track of which records were used before by the given agent.<br />
<br />
'''3.Evaluation'''<br />
*Further the simulation tracks total search attempts and successes. The success is considered only when a record is successfully used for an activity and not when a record is found or searched for.<br />
*At the end of each week, a weekly success rate is calculated by dividing the amount of successful record usages by the number of attempts that were performed.<br />
*The simulation continues until the database has reached "sufficient" usability.<br />
*A database is considered as "sufficiently useful" when success rates in a defined episode length (6 weeks) are over a defined threshold (75%) for a given minimum number of successful weeks (4 out of 6). In other words, when this condition is met within a 3 month timeframe.<br />
<br />
=Results=<br />
In the last section of appended code there was realized an attempt to calculate the results simply by adding new function which whould call the main simulation given number of times and recorded the results so the variability caused by randomness could be viewed. Specifically how the required number of weeks and number of created records varied when running the simulation repeatedly.<br />
<br />
Unfortunately there has been some enexpected and probably undesired patterns occuring in the obtained "multi run" results. Most likely a skillissue on my side. Further elaboration follows.<br />
<br />
Also there is a bug/feature with my function which determines when the search process is successfull enough. Because i require certain amount of time to assess the stability of said successfullness, there is a minimal but fixed timeframe in the begining of the simulation. And because of this when the number of weeks required for the system to be recognized as usefull is measured, its value can not begin earlier than after said timeframe, so that is why the smallest number of weeks in the results are 21.<br />
<br />
Also the counter of created records does not count the records created via batch upload so when reading it needs to be kept in mind.<br />
<br />
Also in the github repository with code, there are plots showing how the successrate evolves in time.<br />
==Single run==<br />
This means runing the multi run function for single iteration.<br />
<br />
But it was run manually three times.<br />
;batch 0 <br />
:weeks until "usefullness": 82, 51, 69<br />
:records created in db: 44, 40, 55<br />
<br />
;batch 10<br />
:weeks: 21, 33, 21<br />
:records: 21, 26, 19 <br />
<br />
;batch 30<br />
:weeks: 24, 21, 22<br />
:records: 26, 17, 18<br />
<br />
;batch 50<br />
:weeks: 21, 21, 21<br />
:records: 30, 18, 27<br />
<br />
It appears that the batch upload in the beginning realy speeds up the time required for the database to be considered usefull, but unfortunately the implementation can not ends earlier then after at least small fixed timeframe.<br />
Its obvious that the results are heavily influenced by the randomness in the model.<br />
<br />
==Multi run==<br />
;batch 0<br />
:weeks: [55, 72, 70, 78, 94, 114, 126, 120, 135, 140, 152, 156, 180, 161, 167]<br />
:records: [32, 129, 108, 195, 262, 316, 320, 308, 366, 373, 432, 442, 496, 486, 487]<br />
<br />
;batch 10<br />
:weeks: [35, 99, 99, 189, 249, 291, 298, 413, 413, 426, 452, 433, 471, 520, 564]<br />
:records: [35, 48, 43, 90, 93, 112, 116, 148, 133, 141, 143, 155, 163, 158, 188]<br />
<br />
;batch 30<br />
:weeks: [21, 67, 79, 105, 99, 97, 115, 132, 137, 149, 160, 158, 170, 178, 181]<br />
:records: [13, 170, 200, 227, 272, 254, 336, 316, 406, 423, 442, 415, 464, 496, 521]<br />
<br />
;batch 50<br />
:weeks: [33, 21, 82, 83, 91, 113, 123, 149, 145, 144, 152, 166, 164, 175, 192]<br />
:records: [58, 42, 187, 247, 271, 306, 331, 365, 397, 413, 468, 502, 495, 507, 540]<br />
<br />
Well, those are here just for fun because there is not much value in such results except for showing something does not work as expected.<br />
<br />
=Discussion=<br />
In this simulation I managed to create heavily simplified model of database populating process in our boy scouts group.<br />
<br />
Therefore the resuls appears to be approximately as they should, but they lack on the reliability if they should be used as a base for a decision.<br />
<br />
=Code=<br />
This is my code on github, because I could not upload .jl file and a did not wanted to make zip: [https://raw.githubusercontent.com/simik394/simulace-populatingskautdb/refs/heads/main/simulace-nobatch.jl]<br />
<br />
And the home repo [https://github.com/simik394/simulace-populatingskautdb]<br />
<br />
[[User:Tros01|Tros01]] ([[User talk:Tros01|talk]]) 22:19, 19 January 2025 (CET)</div>Tros01http://www.simulace.info/index.php?title=Populating_the_database&diff=26544Populating the database2025-01-19T23:34:26Z<p>Tros01: /* Discussion */</p>
<hr />
<div>Úvodní odstavec<br />
<br />
=Problem definition=<br />
==Why?==<br />
Lets say that I have a database containing prepared activities and educational content for boy scouts group. Its purpose is to serve as a source of inspiration and eventually of collection of high quality content appropriate for kids during our weekly meetings or other occasions. From which source should be easy to get precisely only the desired results based on defined properties on each activity (eg. time needed for preparation, minimal number of players, etc.)<br />
<br />
BUT actually its currently more like a proof of concept and not a really operational tool. So accordingly there aren't yet any real records to speak about.<br />
This very early stage of development is exactly the reason why I think it is reasonable to think about how will the database be populated with data. As this will be crucial for its future usability and success. Therefore, the simulation should focus on modeling this data population process.<br />
==What?==<br />
To be precise, the simulation will be concerned with user behavior and related volume of stored records.<br />
<br />
It is important to say that user interface for reading is only the default web gui of the database itself (Neo4j), so the users will have to use the Cypher query language. So after they go through such a way to access the records, there better be some decent amount of useful ones in the database. This is because otherwise their whole effort would be pointless and the user would be discouraged from using the database again.<br />
<br />
Creating the records on the other hand will be easy and accessible as much as possible (user writes to google document in specified folder and with specified structure which enables then loading it programmaticaly into the database). This ease of creation is key to encouraging consistent contributions.<br />
<br />
And here comes the question whether this "natural" way of data population is enough, or rather how long will it take for the database to be able to provide satisfactory results for the user in majority of the cases and as such could be called a useful tool. If the time required would be too long, the users could lose interest of even contributing new content .<br />
Therefore, the simulation will model the rate of content creation and the subsequent impact on database searchability and usability.<br />
<br />
Additionally will be also evaluated the "batch population approach" to see weather it is worth considering to implement. This will involve creating a model of user behavior and content creation, simulating different scenarios, and analyzing the results.<br />
==Objectives==<br />
This simulation aims to predict the growth of the database, determine the feasibility of the current data population strategy and evaluate the alternative.<br />
<br />
#Predict the time needed to reach a critical mass of data sufficient for effective use.<br />
#Evaluate the effectiveness of the current data population method relatively to alternative.<br />
<br />
=Method=<br />
==Agent-based model==<br />
The core method used for this simulation is agent-based modeling (ABM). This approach was selected because it aligns well with the nature of the problem, which involves multiple individual users (agents) interacting with a shared environment (the database). Specifically, it enabled me to simulate:<br />
<br />
*Individual User Behaviors: Each agent acts independently, deciding whether to search the database, create a new record, or improve existing ones, based on their local information and probabilities.<br />
*Heterogeneity (Limited): While the agents initially are identical, they change during the simulation based on their interactions with the database.<br />
*Emergent System Behavior: The overall growth and usability of the database is not programmed directly, but emerges from the accumulation of individual actions.<br />
<br />
Alternatively the system dynamics or simple math equations could be used but neither of them would be more fitting for this usecase.<br />
While system dynamics could model the overall growth of the database as a system, it would not provide the same level of detail regarding individual user actions. System dynamics works well when dealing with aggregate levels and rates of change but isn't great for capturing how each agent behaviour individually impacts the system.<br />
<br />
Just as the equations could model a simplified database growth equation, but it would be extremely difficult to derive a model which includes agents success/fail feedback, record improvement and cooldown and thus it was not considered as applicable for this problem.<br />
==Julia==<br />
Because the ABM approach was chosen the NetLogo was concidered as environment for implemantation of the simulation, but also was the language Julia as it is also often used for simulations. In the end the Julia was chosen because of its more general usability and therefore more usecases when learned to use.<br />
<br />
diskuse možností řešení, výběr metody a prostředku (metod a prostředků) řešení, zdůvodnění výběru (jinými slovy, proč to chcete řešit tak, jak to chcete řešit, jaké jsou jiné alternativy a proč je ta Vámi zvolená pro tuto úlohu nejvhodnější)<br />
<br />
=Model=<br />
<br />
==Entities==<br />
;Database (db):<br />
A dictionary storing Record objects, categorized by integers representing different activity categories.<br />
*The keys of the dictionary are integers representing category id.<br />
*Each category is associated with a vector (array) of Record objects.<br />
*Initially, each category has an empty vector, which can be populated by new records.<br />
<br />
;Record:<br />
A struct containing:<br />
*id (Integer): A unique identifier for the record, auto-incrementing with each creation.<br />
*quality (Float64): Represents the perceived quality or usability of the record. <br />
<br />
(Originally it should more closely resamble the real live improvements by being represented by only range 1-10 as the real live records also can not be improved infinitelly, but in the end there was left simplier implemantation that just has a chance to improve the record during every picked to use event by random value withou top limit.)<br />
<br />
;Agent:<br />
A struct representing a user of the database.<br />
*probabilityToSearch (Float64): The agent's current probability of finding a useful record, it is based on past success of the agent when searching the db. This parameter influences agent's decision whether to search the db or not.<br />
*used (Dict{Int, Vector{Int}}): A dictionary that stores which record IDs have been used by agent and in which week the record has been used, so it won't be used by the same agent during a given cooldown period. Keys are record ids and values are vectors containing week integers in which the record has been used.<br />
<br />
==Variables==<br />
;NUM_AGENTS: <br />
: Integer representing the number of agents (users) participating in the simulation. Value is fixed at 3.<br />
;BATCH_UPLOAD_SIZES:<br />
: Vector of integers representing different sizes of initial record batches uploaded to the database. The values used in simulation are [0, 10].<br />
;initialQualityDist: <br />
: A lognormal distribution (LogNormal(3, 2)) used to generate the initial quality of new records. The mean is set to 3, and the standard deviation is set to 2, meaning the typical quality of created record will be around 3, but there could be some with higher or lower.<br />
;qualityImprovementProb<br />
: Float64 representing the probability that an agent will improve a record's quality after using it. Value is fixed at 0.7 for the sake of simplicity and simulation feasibility.<br />
;recordCreationProb<br />
: Float64 representing the probability that an agent creates a new record when they are preparing an activity and decide not to search the database. Value is fixed at 0.3 for the sake of simplicity and simulation feasibility.<br />
;categories<br />
: Vector of integer representing the category ids of the db records. The vector is generated as range from 1 to 20, [1:20;].<br />
;targetSuccessfulness<br />
: Float64 value, which represents minimum success rate, that needs to be reached for the database to be considered "useful" in a long term. Value is 0.75.<br />
;nSuccessfullFromEpisode<br />
: An integer number representing how many successful searches per episode of the simulation have to occur in order for it to be considered "useful". Value is 4.<br />
;episodeLength<br />
: Integer which represents length of a one "episode" within the simulation, which in this case is a sequence of weeks for which the success rate of the db will be tested if it met required conditions. Value is set to 6, this means 6 weeks.<br />
<br />
==Flow==<br />
'''1.Initialization:'''<br />
<br />
*The database is created with empty vectors of records for each defined category (integer from 1 to 20).<br />
*A defined number of agents are created with default probabilityToSearch.<br />
*Optionally, a number of initial Record objects will be created (based on parameter BATCH_UPLOAD_SIZE), and randomly assigned to a random category within the database.<br />
<br />
'''2.Weekly Cycle (One Tick):'''<br />
<br />
*Each week (tick), each agent attempts to prepare an activity.<br />
*Each agent selects a random category.<br />
*Then each agent decides whether to search the database based on their current probabilityToSearch (It was originally designed to be able to dynamicaly calculate probabilityToSearch of agents independently, but for the same reason the recordCreationProb is global to all agents, also this variable was left the same for all agents).<br />
<br />
;Search Behavior:<br />
<br />
*If the agent decides to search, it looks up all records that matches it selected category.<br />
*If records are found, the agents samples without replacement a predefined number of records for evaluation. Each has different probability based on its quality. The more quality it has, the higher the probability to be chosen. (Weights are calculated like this [rec.quality / sum(r.quality for r in records) for rec in records])<br />
*An agent tries to pick for use randomly one record from those records. <br />
*Before the agent uses any of the found records, there has to be checked if they haven't been used in a defined "cooldown period", which is set to 54 weeks. Each agent keeps track of used records and the weeks where they where used.<br />
*If the record the agent tries to pick is on cooldown, the agent proceeds to trying another one from the sampled ones until it finds a cooled down one or until there are no more samples (usually in the beginning of the simulation when there are yot not created record in the db).<br />
*If the record is used, there is a probability of the agent improving the quality of that used record.<br />
<br />
;Record Creation Behavior:<br />
<br />
*If the agent decides not to search or if the search is unsuccessful, it has a chance of creating a new record (based on parameter recordCreationProb).<br />
*If a new record is created, it's assigned a randomly generated initial quality based on the lognormal distribution, and pushed to db under it's selected category.<br />
*Also there is kept record of total number oc record created so far during the simulation and the order number of each record is assigned to the record during its creation as its id. This way its possible to keep track of which records were used before by the given agent.<br />
<br />
'''3.Evaluation'''<br />
*Further the simulation tracks total search attempts and successes. The success is considered only when a record is successfully used for an activity and not when a record is found or searched for.<br />
*At the end of each week, a weekly success rate is calculated by dividing the amount of successful record usages by the number of attempts that were performed.<br />
*The simulation continues until the database has reached "sufficient" usability.<br />
*A database is considered as "sufficiently useful" when success rates in a defined episode length (6 weeks) are over a defined threshold (75%) for a given minimum number of successful weeks (4 out of 6). In other words, when this condition is met within a 3 month timeframe.<br />
<br />
=Results=<br />
In the last section of appended code there was realized an attempt to calculate the results simply by adding new function which whould call the main simulation given number of times and recorded the results so the variability caused by randomness could be viewed. Specifically how the required number of weeks and number of created records varied when running the simulation repeatedly.<br />
<br />
Unfortunately there has been some enexpected and probably undesired patterns occuring in the obtained "multi run" results. Most likely a skillissue on my side. Further elaboration follows.<br />
<br />
Also there is a bug/feature with my function which determines when the search process is successfull enough. Because i require certain amount of time to assess the stability of said successfullness, there is a minimal but fixed timeframe in the begining of the simulation. And because of this when the number of weeks required for the system to be recognized as usefull is measured, its value can not begin earlier than after said timeframe, so that is why the smallest number of weeks in the results are 21.<br />
<br />
Also the counter of created records does not count the records created via batch upload so when reading it needs to be kept in mind.<br />
<br />
Also in the github repository with code, there are plots showing how the successrate evolves in time.<br />
==Single run==<br />
This means runing the multi run function for single iteration.<br />
<br />
But it was run manually three times.<br />
;batch 0 <br />
:weeks until "usefullness": 82, 51, 69<br />
:records created in db: 44, 40, 55<br />
<br />
;batch 10<br />
:weeks: 21, 33, 21<br />
:records: 21, 26, 19 <br />
<br />
;batch 30<br />
:weeks: 24, 21, 22<br />
:records: 26, 17, 18<br />
<br />
;batch 50<br />
:weeks: 21, 21, 21<br />
:records: 30, 18, 27<br />
<br />
It appears that the batch upload in the beginning realy speeds up the time required for the database to be considered usefull, but unfortunately the implementation can not ends earlier then after at least small fixed timeframe.<br />
Its obvious that the results are heavily influenced by the randomness in the model.<br />
<br />
==Multi run==<br />
;batch 0<br />
:weeks: [55, 72, 70, 78, 94, 114, 126, 120, 135, 140, 152, 156, 180, 161, 167]<br />
:records: [32, 129, 108, 195, 262, 316, 320, 308, 366, 373, 432, 442, 496, 486, 487]<br />
<br />
;batch 10<br />
:weeks: [35, 99, 99, 189, 249, 291, 298, 413, 413, 426, 452, 433, 471, 520, 564]<br />
:records: [35, 48, 43, 90, 93, 112, 116, 148, 133, 141, 143, 155, 163, 158, 188]<br />
<br />
;batch 30<br />
:weeks: [21, 67, 79, 105, 99, 97, 115, 132, 137, 149, 160, 158, 170, 178, 181]<br />
:records: [13, 170, 200, 227, 272, 254, 336, 316, 406, 423, 442, 415, 464, 496, 521]<br />
<br />
;batch 50<br />
:weeks: [33, 21, 82, 83, 91, 113, 123, 149, 145, 144, 152, 166, 164, 175, 192]<br />
:records: [58, 42, 187, 247, 271, 306, 331, 365, 397, 413, 468, 502, 495, 507, 540]<br />
<br />
Well, those are here just for fun because there is not much value in such results except for showing something does not work as expected.<br />
<br />
=Discussion=<br />
In this simulation I managed to create heavily simplified model of database populating process in our boy scouts group.<br />
Therefore the resuls appears to be approximately as they should, but they lack on the reliability if they should be used as a base for a decision.<br />
<br />
=Code=<br />
This is my code on github, because I could not upload .jl file and a did not wanted to make zip: [https://raw.githubusercontent.com/simik394/simulace-populatingskautdb/refs/heads/main/simulace-nobatch.jl]<br />
<br />
And the home repo [https://github.com/simik394/simulace-populatingskautdb]<br />
<br />
[[User:Tros01|Tros01]] ([[User talk:Tros01|talk]]) 22:19, 19 January 2025 (CET)</div>Tros01http://www.simulace.info/index.php?title=Populating_the_database&diff=26543Populating the database2025-01-19T23:27:15Z<p>Tros01: /* Results */</p>
<hr />
<div>Úvodní odstavec<br />
<br />
=Problem definition=<br />
==Why?==<br />
Lets say that I have a database containing prepared activities and educational content for boy scouts group. Its purpose is to serve as a source of inspiration and eventually of collection of high quality content appropriate for kids during our weekly meetings or other occasions. From which source should be easy to get precisely only the desired results based on defined properties on each activity (eg. time needed for preparation, minimal number of players, etc.)<br />
<br />
BUT actually its currently more like a proof of concept and not a really operational tool. So accordingly there aren't yet any real records to speak about.<br />
This very early stage of development is exactly the reason why I think it is reasonable to think about how will the database be populated with data. As this will be crucial for its future usability and success. Therefore, the simulation should focus on modeling this data population process.<br />
==What?==<br />
To be precise, the simulation will be concerned with user behavior and related volume of stored records.<br />
<br />
It is important to say that user interface for reading is only the default web gui of the database itself (Neo4j), so the users will have to use the Cypher query language. So after they go through such a way to access the records, there better be some decent amount of useful ones in the database. This is because otherwise their whole effort would be pointless and the user would be discouraged from using the database again.<br />
<br />
Creating the records on the other hand will be easy and accessible as much as possible (user writes to google document in specified folder and with specified structure which enables then loading it programmaticaly into the database). This ease of creation is key to encouraging consistent contributions.<br />
<br />
And here comes the question whether this "natural" way of data population is enough, or rather how long will it take for the database to be able to provide satisfactory results for the user in majority of the cases and as such could be called a useful tool. If the time required would be too long, the users could lose interest of even contributing new content .<br />
Therefore, the simulation will model the rate of content creation and the subsequent impact on database searchability and usability.<br />
<br />
Additionally will be also evaluated the "batch population approach" to see weather it is worth considering to implement. This will involve creating a model of user behavior and content creation, simulating different scenarios, and analyzing the results.<br />
==Objectives==<br />
This simulation aims to predict the growth of the database, determine the feasibility of the current data population strategy and evaluate the alternative.<br />
<br />
#Predict the time needed to reach a critical mass of data sufficient for effective use.<br />
#Evaluate the effectiveness of the current data population method relatively to alternative.<br />
<br />
=Method=<br />
==Agent-based model==<br />
The core method used for this simulation is agent-based modeling (ABM). This approach was selected because it aligns well with the nature of the problem, which involves multiple individual users (agents) interacting with a shared environment (the database). Specifically, it enabled me to simulate:<br />
<br />
*Individual User Behaviors: Each agent acts independently, deciding whether to search the database, create a new record, or improve existing ones, based on their local information and probabilities.<br />
*Heterogeneity (Limited): While the agents initially are identical, they change during the simulation based on their interactions with the database.<br />
*Emergent System Behavior: The overall growth and usability of the database is not programmed directly, but emerges from the accumulation of individual actions.<br />
<br />
Alternatively the system dynamics or simple math equations could be used but neither of them would be more fitting for this usecase.<br />
While system dynamics could model the overall growth of the database as a system, it would not provide the same level of detail regarding individual user actions. System dynamics works well when dealing with aggregate levels and rates of change but isn't great for capturing how each agent behaviour individually impacts the system.<br />
<br />
Just as the equations could model a simplified database growth equation, but it would be extremely difficult to derive a model which includes agents success/fail feedback, record improvement and cooldown and thus it was not considered as applicable for this problem.<br />
==Julia==<br />
Because the ABM approach was chosen the NetLogo was concidered as environment for implemantation of the simulation, but also was the language Julia as it is also often used for simulations. In the end the Julia was chosen because of its more general usability and therefore more usecases when learned to use.<br />
<br />
diskuse možností řešení, výběr metody a prostředku (metod a prostředků) řešení, zdůvodnění výběru (jinými slovy, proč to chcete řešit tak, jak to chcete řešit, jaké jsou jiné alternativy a proč je ta Vámi zvolená pro tuto úlohu nejvhodnější)<br />
<br />
=Model=<br />
<br />
==Entities==<br />
;Database (db):<br />
A dictionary storing Record objects, categorized by integers representing different activity categories.<br />
*The keys of the dictionary are integers representing category id.<br />
*Each category is associated with a vector (array) of Record objects.<br />
*Initially, each category has an empty vector, which can be populated by new records.<br />
<br />
;Record:<br />
A struct containing:<br />
*id (Integer): A unique identifier for the record, auto-incrementing with each creation.<br />
*quality (Float64): Represents the perceived quality or usability of the record. <br />
<br />
(Originally it should more closely resamble the real live improvements by being represented by only range 1-10 as the real live records also can not be improved infinitelly, but in the end there was left simplier implemantation that just has a chance to improve the record during every picked to use event by random value withou top limit.)<br />
<br />
;Agent:<br />
A struct representing a user of the database.<br />
*probabilityToSearch (Float64): The agent's current probability of finding a useful record, it is based on past success of the agent when searching the db. This parameter influences agent's decision whether to search the db or not.<br />
*used (Dict{Int, Vector{Int}}): A dictionary that stores which record IDs have been used by agent and in which week the record has been used, so it won't be used by the same agent during a given cooldown period. Keys are record ids and values are vectors containing week integers in which the record has been used.<br />
<br />
==Variables==<br />
;NUM_AGENTS: <br />
: Integer representing the number of agents (users) participating in the simulation. Value is fixed at 3.<br />
;BATCH_UPLOAD_SIZES:<br />
: Vector of integers representing different sizes of initial record batches uploaded to the database. The values used in simulation are [0, 10].<br />
;initialQualityDist: <br />
: A lognormal distribution (LogNormal(3, 2)) used to generate the initial quality of new records. The mean is set to 3, and the standard deviation is set to 2, meaning the typical quality of created record will be around 3, but there could be some with higher or lower.<br />
;qualityImprovementProb<br />
: Float64 representing the probability that an agent will improve a record's quality after using it. Value is fixed at 0.7 for the sake of simplicity and simulation feasibility.<br />
;recordCreationProb<br />
: Float64 representing the probability that an agent creates a new record when they are preparing an activity and decide not to search the database. Value is fixed at 0.3 for the sake of simplicity and simulation feasibility.<br />
;categories<br />
: Vector of integer representing the category ids of the db records. The vector is generated as range from 1 to 20, [1:20;].<br />
;targetSuccessfulness<br />
: Float64 value, which represents minimum success rate, that needs to be reached for the database to be considered "useful" in a long term. Value is 0.75.<br />
;nSuccessfullFromEpisode<br />
: An integer number representing how many successful searches per episode of the simulation have to occur in order for it to be considered "useful". Value is 4.<br />
;episodeLength<br />
: Integer which represents length of a one "episode" within the simulation, which in this case is a sequence of weeks for which the success rate of the db will be tested if it met required conditions. Value is set to 6, this means 6 weeks.<br />
<br />
==Flow==<br />
'''1.Initialization:'''<br />
<br />
*The database is created with empty vectors of records for each defined category (integer from 1 to 20).<br />
*A defined number of agents are created with default probabilityToSearch.<br />
*Optionally, a number of initial Record objects will be created (based on parameter BATCH_UPLOAD_SIZE), and randomly assigned to a random category within the database.<br />
<br />
'''2.Weekly Cycle (One Tick):'''<br />
<br />
*Each week (tick), each agent attempts to prepare an activity.<br />
*Each agent selects a random category.<br />
*Then each agent decides whether to search the database based on their current probabilityToSearch (It was originally designed to be able to dynamicaly calculate probabilityToSearch of agents independently, but for the same reason the recordCreationProb is global to all agents, also this variable was left the same for all agents).<br />
<br />
;Search Behavior:<br />
<br />
*If the agent decides to search, it looks up all records that matches it selected category.<br />
*If records are found, the agents samples without replacement a predefined number of records for evaluation. Each has different probability based on its quality. The more quality it has, the higher the probability to be chosen. (Weights are calculated like this [rec.quality / sum(r.quality for r in records) for rec in records])<br />
*An agent tries to pick for use randomly one record from those records. <br />
*Before the agent uses any of the found records, there has to be checked if they haven't been used in a defined "cooldown period", which is set to 54 weeks. Each agent keeps track of used records and the weeks where they where used.<br />
*If the record the agent tries to pick is on cooldown, the agent proceeds to trying another one from the sampled ones until it finds a cooled down one or until there are no more samples (usually in the beginning of the simulation when there are yot not created record in the db).<br />
*If the record is used, there is a probability of the agent improving the quality of that used record.<br />
<br />
;Record Creation Behavior:<br />
<br />
*If the agent decides not to search or if the search is unsuccessful, it has a chance of creating a new record (based on parameter recordCreationProb).<br />
*If a new record is created, it's assigned a randomly generated initial quality based on the lognormal distribution, and pushed to db under it's selected category.<br />
*Also there is kept record of total number oc record created so far during the simulation and the order number of each record is assigned to the record during its creation as its id. This way its possible to keep track of which records were used before by the given agent.<br />
<br />
'''3.Evaluation'''<br />
*Further the simulation tracks total search attempts and successes. The success is considered only when a record is successfully used for an activity and not when a record is found or searched for.<br />
*At the end of each week, a weekly success rate is calculated by dividing the amount of successful record usages by the number of attempts that were performed.<br />
*The simulation continues until the database has reached "sufficient" usability.<br />
*A database is considered as "sufficiently useful" when success rates in a defined episode length (6 weeks) are over a defined threshold (75%) for a given minimum number of successful weeks (4 out of 6). In other words, when this condition is met within a 3 month timeframe.<br />
<br />
=Results=<br />
In the last section of appended code there was realized an attempt to calculate the results simply by adding new function which whould call the main simulation given number of times and recorded the results so the variability caused by randomness could be viewed. Specifically how the required number of weeks and number of created records varied when running the simulation repeatedly.<br />
<br />
Unfortunately there has been some enexpected and probably undesired patterns occuring in the obtained "multi run" results. Most likely a skillissue on my side. Further elaboration follows.<br />
<br />
Also there is a bug/feature with my function which determines when the search process is successfull enough. Because i require certain amount of time to assess the stability of said successfullness, there is a minimal but fixed timeframe in the begining of the simulation. And because of this when the number of weeks required for the system to be recognized as usefull is measured, its value can not begin earlier than after said timeframe, so that is why the smallest number of weeks in the results are 21.<br />
<br />
Also the counter of created records does not count the records created via batch upload so when reading it needs to be kept in mind.<br />
<br />
Also in the github repository with code, there are plots showing how the successrate evolves in time.<br />
==Single run==<br />
This means runing the multi run function for single iteration.<br />
<br />
But it was run manually three times.<br />
;batch 0 <br />
:weeks until "usefullness": 82, 51, 69<br />
:records created in db: 44, 40, 55<br />
<br />
;batch 10<br />
:weeks: 21, 33, 21<br />
:records: 21, 26, 19 <br />
<br />
;batch 30<br />
:weeks: 24, 21, 22<br />
:records: 26, 17, 18<br />
<br />
;batch 50<br />
:weeks: 21, 21, 21<br />
:records: 30, 18, 27<br />
<br />
It appears that the batch upload in the beginning realy speeds up the time required for the database to be considered usefull, but unfortunately the implementation can not ends earlier then after at least small fixed timeframe.<br />
Its obvious that the results are heavily influenced by the randomness in the model.<br />
<br />
==Multi run==<br />
;batch 0<br />
:weeks: [55, 72, 70, 78, 94, 114, 126, 120, 135, 140, 152, 156, 180, 161, 167]<br />
:records: [32, 129, 108, 195, 262, 316, 320, 308, 366, 373, 432, 442, 496, 486, 487]<br />
<br />
;batch 10<br />
:weeks: [35, 99, 99, 189, 249, 291, 298, 413, 413, 426, 452, 433, 471, 520, 564]<br />
:records: [35, 48, 43, 90, 93, 112, 116, 148, 133, 141, 143, 155, 163, 158, 188]<br />
<br />
;batch 30<br />
:weeks: [21, 67, 79, 105, 99, 97, 115, 132, 137, 149, 160, 158, 170, 178, 181]<br />
:records: [13, 170, 200, 227, 272, 254, 336, 316, 406, 423, 442, 415, 464, 496, 521]<br />
<br />
;batch 50<br />
:weeks: [33, 21, 82, 83, 91, 113, 123, 149, 145, 144, 152, 166, 164, 175, 192]<br />
:records: [58, 42, 187, 247, 271, 306, 331, 365, 397, 413, 468, 502, 495, 507, 540]<br />
<br />
Well, those are here just for fun because there is not much value in such results except for showing something does not work as expected.<br />
<br />
=Discussion=<br />
jak se Vám podařilo definovaný problém vyřešit<br />
<br />
<br />
=Code=<br />
This is my code on github, because I could not upload .jl file and a did not wanted to make zip: [https://raw.githubusercontent.com/simik394/simulace-populatingskautdb/refs/heads/main/simulace-nobatch.jl]<br />
<br />
And the home repo [https://github.com/simik394/simulace-populatingskautdb]<br />
<br />
[[User:Tros01|Tros01]] ([[User talk:Tros01|talk]]) 22:19, 19 January 2025 (CET)</div>Tros01http://www.simulace.info/index.php?title=Populating_the_database&diff=26542Populating the database2025-01-19T23:18:27Z<p>Tros01: /* Flow */</p>
<hr />
<div>Úvodní odstavec<br />
<br />
=Problem definition=<br />
==Why?==<br />
Lets say that I have a database containing prepared activities and educational content for boy scouts group. Its purpose is to serve as a source of inspiration and eventually of collection of high quality content appropriate for kids during our weekly meetings or other occasions. From which source should be easy to get precisely only the desired results based on defined properties on each activity (eg. time needed for preparation, minimal number of players, etc.)<br />
<br />
BUT actually its currently more like a proof of concept and not a really operational tool. So accordingly there aren't yet any real records to speak about.<br />
This very early stage of development is exactly the reason why I think it is reasonable to think about how will the database be populated with data. As this will be crucial for its future usability and success. Therefore, the simulation should focus on modeling this data population process.<br />
==What?==<br />
To be precise, the simulation will be concerned with user behavior and related volume of stored records.<br />
<br />
It is important to say that user interface for reading is only the default web gui of the database itself (Neo4j), so the users will have to use the Cypher query language. So after they go through such a way to access the records, there better be some decent amount of useful ones in the database. This is because otherwise their whole effort would be pointless and the user would be discouraged from using the database again.<br />
<br />
Creating the records on the other hand will be easy and accessible as much as possible (user writes to google document in specified folder and with specified structure which enables then loading it programmaticaly into the database). This ease of creation is key to encouraging consistent contributions.<br />
<br />
And here comes the question whether this "natural" way of data population is enough, or rather how long will it take for the database to be able to provide satisfactory results for the user in majority of the cases and as such could be called a useful tool. If the time required would be too long, the users could lose interest of even contributing new content .<br />
Therefore, the simulation will model the rate of content creation and the subsequent impact on database searchability and usability.<br />
<br />
Additionally will be also evaluated the "batch population approach" to see weather it is worth considering to implement. This will involve creating a model of user behavior and content creation, simulating different scenarios, and analyzing the results.<br />
==Objectives==<br />
This simulation aims to predict the growth of the database, determine the feasibility of the current data population strategy and evaluate the alternative.<br />
<br />
#Predict the time needed to reach a critical mass of data sufficient for effective use.<br />
#Evaluate the effectiveness of the current data population method relatively to alternative.<br />
<br />
=Method=<br />
==Agent-based model==<br />
The core method used for this simulation is agent-based modeling (ABM). This approach was selected because it aligns well with the nature of the problem, which involves multiple individual users (agents) interacting with a shared environment (the database). Specifically, it enabled me to simulate:<br />
<br />
*Individual User Behaviors: Each agent acts independently, deciding whether to search the database, create a new record, or improve existing ones, based on their local information and probabilities.<br />
*Heterogeneity (Limited): While the agents initially are identical, they change during the simulation based on their interactions with the database.<br />
*Emergent System Behavior: The overall growth and usability of the database is not programmed directly, but emerges from the accumulation of individual actions.<br />
<br />
Alternatively the system dynamics or simple math equations could be used but neither of them would be more fitting for this usecase.<br />
While system dynamics could model the overall growth of the database as a system, it would not provide the same level of detail regarding individual user actions. System dynamics works well when dealing with aggregate levels and rates of change but isn't great for capturing how each agent behaviour individually impacts the system.<br />
<br />
Just as the equations could model a simplified database growth equation, but it would be extremely difficult to derive a model which includes agents success/fail feedback, record improvement and cooldown and thus it was not considered as applicable for this problem.<br />
==Julia==<br />
Because the ABM approach was chosen the NetLogo was concidered as environment for implemantation of the simulation, but also was the language Julia as it is also often used for simulations. In the end the Julia was chosen because of its more general usability and therefore more usecases when learned to use.<br />
<br />
diskuse možností řešení, výběr metody a prostředku (metod a prostředků) řešení, zdůvodnění výběru (jinými slovy, proč to chcete řešit tak, jak to chcete řešit, jaké jsou jiné alternativy a proč je ta Vámi zvolená pro tuto úlohu nejvhodnější)<br />
<br />
=Model=<br />
<br />
==Entities==<br />
;Database (db):<br />
A dictionary storing Record objects, categorized by integers representing different activity categories.<br />
*The keys of the dictionary are integers representing category id.<br />
*Each category is associated with a vector (array) of Record objects.<br />
*Initially, each category has an empty vector, which can be populated by new records.<br />
<br />
;Record:<br />
A struct containing:<br />
*id (Integer): A unique identifier for the record, auto-incrementing with each creation.<br />
*quality (Float64): Represents the perceived quality or usability of the record. <br />
<br />
(Originally it should more closely resamble the real live improvements by being represented by only range 1-10 as the real live records also can not be improved infinitelly, but in the end there was left simplier implemantation that just has a chance to improve the record during every picked to use event by random value withou top limit.)<br />
<br />
;Agent:<br />
A struct representing a user of the database.<br />
*probabilityToSearch (Float64): The agent's current probability of finding a useful record, it is based on past success of the agent when searching the db. This parameter influences agent's decision whether to search the db or not.<br />
*used (Dict{Int, Vector{Int}}): A dictionary that stores which record IDs have been used by agent and in which week the record has been used, so it won't be used by the same agent during a given cooldown period. Keys are record ids and values are vectors containing week integers in which the record has been used.<br />
<br />
==Variables==<br />
;NUM_AGENTS: <br />
: Integer representing the number of agents (users) participating in the simulation. Value is fixed at 3.<br />
;BATCH_UPLOAD_SIZES:<br />
: Vector of integers representing different sizes of initial record batches uploaded to the database. The values used in simulation are [0, 10].<br />
;initialQualityDist: <br />
: A lognormal distribution (LogNormal(3, 2)) used to generate the initial quality of new records. The mean is set to 3, and the standard deviation is set to 2, meaning the typical quality of created record will be around 3, but there could be some with higher or lower.<br />
;qualityImprovementProb<br />
: Float64 representing the probability that an agent will improve a record's quality after using it. Value is fixed at 0.7 for the sake of simplicity and simulation feasibility.<br />
;recordCreationProb<br />
: Float64 representing the probability that an agent creates a new record when they are preparing an activity and decide not to search the database. Value is fixed at 0.3 for the sake of simplicity and simulation feasibility.<br />
;categories<br />
: Vector of integer representing the category ids of the db records. The vector is generated as range from 1 to 20, [1:20;].<br />
;targetSuccessfulness<br />
: Float64 value, which represents minimum success rate, that needs to be reached for the database to be considered "useful" in a long term. Value is 0.75.<br />
;nSuccessfullFromEpisode<br />
: An integer number representing how many successful searches per episode of the simulation have to occur in order for it to be considered "useful". Value is 4.<br />
;episodeLength<br />
: Integer which represents length of a one "episode" within the simulation, which in this case is a sequence of weeks for which the success rate of the db will be tested if it met required conditions. Value is set to 6, this means 6 weeks.<br />
<br />
==Flow==<br />
'''1.Initialization:'''<br />
<br />
*The database is created with empty vectors of records for each defined category (integer from 1 to 20).<br />
*A defined number of agents are created with default probabilityToSearch.<br />
*Optionally, a number of initial Record objects will be created (based on parameter BATCH_UPLOAD_SIZE), and randomly assigned to a random category within the database.<br />
<br />
'''2.Weekly Cycle (One Tick):'''<br />
<br />
*Each week (tick), each agent attempts to prepare an activity.<br />
*Each agent selects a random category.<br />
*Then each agent decides whether to search the database based on their current probabilityToSearch (It was originally designed to be able to dynamicaly calculate probabilityToSearch of agents independently, but for the same reason the recordCreationProb is global to all agents, also this variable was left the same for all agents).<br />
<br />
;Search Behavior:<br />
<br />
*If the agent decides to search, it looks up all records that matches it selected category.<br />
*If records are found, the agents samples without replacement a predefined number of records for evaluation. Each has different probability based on its quality. The more quality it has, the higher the probability to be chosen. (Weights are calculated like this [rec.quality / sum(r.quality for r in records) for rec in records])<br />
*An agent tries to pick for use randomly one record from those records. <br />
*Before the agent uses any of the found records, there has to be checked if they haven't been used in a defined "cooldown period", which is set to 54 weeks. Each agent keeps track of used records and the weeks where they where used.<br />
*If the record the agent tries to pick is on cooldown, the agent proceeds to trying another one from the sampled ones until it finds a cooled down one or until there are no more samples (usually in the beginning of the simulation when there are yot not created record in the db).<br />
*If the record is used, there is a probability of the agent improving the quality of that used record.<br />
<br />
;Record Creation Behavior:<br />
<br />
*If the agent decides not to search or if the search is unsuccessful, it has a chance of creating a new record (based on parameter recordCreationProb).<br />
*If a new record is created, it's assigned a randomly generated initial quality based on the lognormal distribution, and pushed to db under it's selected category.<br />
*Also there is kept record of total number oc record created so far during the simulation and the order number of each record is assigned to the record during its creation as its id. This way its possible to keep track of which records were used before by the given agent.<br />
<br />
'''3.Evaluation'''<br />
*Further the simulation tracks total search attempts and successes. The success is considered only when a record is successfully used for an activity and not when a record is found or searched for.<br />
*At the end of each week, a weekly success rate is calculated by dividing the amount of successful record usages by the number of attempts that were performed.<br />
*The simulation continues until the database has reached "sufficient" usability.<br />
*A database is considered as "sufficiently useful" when success rates in a defined episode length (6 weeks) are over a defined threshold (75%) for a given minimum number of successful weeks (4 out of 6). In other words, when this condition is met within a 3 month timeframe.<br />
<br />
=Results=<br />
In the last section of appended code there was realized an attempt to calculate the results simply by adding new function which whould call the main simulation given number of times and recorded the results so the variability caused by randomness could be viewed. Specifically how the required number of weeks and number of created records varied when running the simulation repeatedly.<br />
<br />
Unfortunately there has been some enexpected and probably undesired patterns occuring in the obtained "multi run" results. Most likely a skillissue on my side. Further elaboration follows.<br />
<br />
Also there is a bug/feature with my function which determines when the search process is successfull enough. Because i require certain amount of time to assess the stability of said successfullness, there is a minimal but fixed timeframe in the begining of the simulation. And because of this when the number of weeks required for the system to be recognized as usefull is measured, its value can not begin earlier than after said timeframe, so that is why the smallest number of weeks in the results are 21.<br />
<br />
Also the counter of created records does not count the records created via batch upload so when reading it needs to be kept in mind.<br />
==Single run==<br />
This means runing the multi run function for single iteration.<br />
<br />
But it was run manually three times.<br />
;batch 0 <br />
:weeks until "usefullness": 82, 51, 69<br />
:records created in db: 44, 40, 55<br />
<br />
;batch 10<br />
:weeks: 21, 33, 21<br />
:records: 21, 26, 19 <br />
<br />
;batch 30<br />
:weeks: 24, 21, 22<br />
:records: 26, 17, 18<br />
<br />
;batch 50<br />
:weeks: 21, 21, 21<br />
:records: 30, 18, 27<br />
<br />
It appears that the batch upload in the beginning realy speeds up the time required for the database to be considered usefull, but unfortunately the implementation can not ends earlier then after at least small fixed timeframe.<br />
Its obvious that the results are heavily influenced by the randomness in the model.<br />
<br />
==Multi run==<br />
;batch 0<br />
:weeks: [55, 72, 70, 78, 94, 114, 126, 120, 135, 140, 152, 156, 180, 161, 167]<br />
:records: [32, 129, 108, 195, 262, 316, 320, 308, 366, 373, 432, 442, 496, 486, 487]<br />
<br />
;batch 10<br />
:weeks: [35, 99, 99, 189, 249, 291, 298, 413, 413, 426, 452, 433, 471, 520, 564]<br />
:records: [35, 48, 43, 90, 93, 112, 116, 148, 133, 141, 143, 155, 163, 158, 188]<br />
<br />
;batch 30<br />
:weeks: [21, 67, 79, 105, 99, 97, 115, 132, 137, 149, 160, 158, 170, 178, 181]<br />
:records: [13, 170, 200, 227, 272, 254, 336, 316, 406, 423, 442, 415, 464, 496, 521]<br />
<br />
;batch 50<br />
:weeks: [33, 21, 82, 83, 91, 113, 123, 149, 145, 144, 152, 166, 164, 175, 192]<br />
:records: [58, 42, 187, 247, 271, 306, 331, 365, 397, 413, 468, 502, 495, 507, 540]<br />
<br />
Well, those are here just for fun because there is not much value in such results except for showing something does not work as expected.<br />
<br />
=Discussion=<br />
jak se Vám podařilo definovaný problém vyřešit<br />
<br />
<br />
=Code=<br />
This is my code on github, because I could not upload .jl file and a did not wanted to make zip: [https://raw.githubusercontent.com/simik394/simulace-populatingskautdb/refs/heads/main/simulace-nobatch.jl]<br />
<br />
And the home repo [https://github.com/simik394/simulace-populatingskautdb]<br />
<br />
[[User:Tros01|Tros01]] ([[User talk:Tros01|talk]]) 22:19, 19 January 2025 (CET)</div>Tros01http://www.simulace.info/index.php?title=Populating_the_database&diff=26541Populating the database2025-01-19T23:09:01Z<p>Tros01: /* Multi run */</p>
<hr />
<div>Úvodní odstavec<br />
<br />
=Problem definition=<br />
==Why?==<br />
Lets say that I have a database containing prepared activities and educational content for boy scouts group. Its purpose is to serve as a source of inspiration and eventually of collection of high quality content appropriate for kids during our weekly meetings or other occasions. From which source should be easy to get precisely only the desired results based on defined properties on each activity (eg. time needed for preparation, minimal number of players, etc.)<br />
<br />
BUT actually its currently more like a proof of concept and not a really operational tool. So accordingly there aren't yet any real records to speak about.<br />
This very early stage of development is exactly the reason why I think it is reasonable to think about how will the database be populated with data. As this will be crucial for its future usability and success. Therefore, the simulation should focus on modeling this data population process.<br />
==What?==<br />
To be precise, the simulation will be concerned with user behavior and related volume of stored records.<br />
<br />
It is important to say that user interface for reading is only the default web gui of the database itself (Neo4j), so the users will have to use the Cypher query language. So after they go through such a way to access the records, there better be some decent amount of useful ones in the database. This is because otherwise their whole effort would be pointless and the user would be discouraged from using the database again.<br />
<br />
Creating the records on the other hand will be easy and accessible as much as possible (user writes to google document in specified folder and with specified structure which enables then loading it programmaticaly into the database). This ease of creation is key to encouraging consistent contributions.<br />
<br />
And here comes the question whether this "natural" way of data population is enough, or rather how long will it take for the database to be able to provide satisfactory results for the user in majority of the cases and as such could be called a useful tool. If the time required would be too long, the users could lose interest of even contributing new content .<br />
Therefore, the simulation will model the rate of content creation and the subsequent impact on database searchability and usability.<br />
<br />
Additionally will be also evaluated the "batch population approach" to see weather it is worth considering to implement. This will involve creating a model of user behavior and content creation, simulating different scenarios, and analyzing the results.<br />
==Objectives==<br />
This simulation aims to predict the growth of the database, determine the feasibility of the current data population strategy and evaluate the alternative.<br />
<br />
#Predict the time needed to reach a critical mass of data sufficient for effective use.<br />
#Evaluate the effectiveness of the current data population method relatively to alternative.<br />
<br />
=Method=<br />
==Agent-based model==<br />
The core method used for this simulation is agent-based modeling (ABM). This approach was selected because it aligns well with the nature of the problem, which involves multiple individual users (agents) interacting with a shared environment (the database). Specifically, it enabled me to simulate:<br />
<br />
*Individual User Behaviors: Each agent acts independently, deciding whether to search the database, create a new record, or improve existing ones, based on their local information and probabilities.<br />
*Heterogeneity (Limited): While the agents initially are identical, they change during the simulation based on their interactions with the database.<br />
*Emergent System Behavior: The overall growth and usability of the database is not programmed directly, but emerges from the accumulation of individual actions.<br />
<br />
Alternatively the system dynamics or simple math equations could be used but neither of them would be more fitting for this usecase.<br />
While system dynamics could model the overall growth of the database as a system, it would not provide the same level of detail regarding individual user actions. System dynamics works well when dealing with aggregate levels and rates of change but isn't great for capturing how each agent behaviour individually impacts the system.<br />
<br />
Just as the equations could model a simplified database growth equation, but it would be extremely difficult to derive a model which includes agents success/fail feedback, record improvement and cooldown and thus it was not considered as applicable for this problem.<br />
==Julia==<br />
Because the ABM approach was chosen the NetLogo was concidered as environment for implemantation of the simulation, but also was the language Julia as it is also often used for simulations. In the end the Julia was chosen because of its more general usability and therefore more usecases when learned to use.<br />
<br />
diskuse možností řešení, výběr metody a prostředku (metod a prostředků) řešení, zdůvodnění výběru (jinými slovy, proč to chcete řešit tak, jak to chcete řešit, jaké jsou jiné alternativy a proč je ta Vámi zvolená pro tuto úlohu nejvhodnější)<br />
<br />
=Model=<br />
<br />
==Entities==<br />
;Database (db):<br />
A dictionary storing Record objects, categorized by integers representing different activity categories.<br />
*The keys of the dictionary are integers representing category id.<br />
*Each category is associated with a vector (array) of Record objects.<br />
*Initially, each category has an empty vector, which can be populated by new records.<br />
<br />
;Record:<br />
A struct containing:<br />
*id (Integer): A unique identifier for the record, auto-incrementing with each creation.<br />
*quality (Float64): Represents the perceived quality or usability of the record. <br />
<br />
(Originally it should more closely resamble the real live improvements by being represented by only range 1-10 as the real live records also can not be improved infinitelly, but in the end there was left simplier implemantation that just has a chance to improve the record during every picked to use event by random value withou top limit.)<br />
<br />
;Agent:<br />
A struct representing a user of the database.<br />
*probabilityToSearch (Float64): The agent's current probability of finding a useful record, it is based on past success of the agent when searching the db. This parameter influences agent's decision whether to search the db or not.<br />
*used (Dict{Int, Vector{Int}}): A dictionary that stores which record IDs have been used by agent and in which week the record has been used, so it won't be used by the same agent during a given cooldown period. Keys are record ids and values are vectors containing week integers in which the record has been used.<br />
<br />
==Variables==<br />
;NUM_AGENTS: <br />
: Integer representing the number of agents (users) participating in the simulation. Value is fixed at 3.<br />
;BATCH_UPLOAD_SIZES:<br />
: Vector of integers representing different sizes of initial record batches uploaded to the database. The values used in simulation are [0, 10].<br />
;initialQualityDist: <br />
: A lognormal distribution (LogNormal(3, 2)) used to generate the initial quality of new records. The mean is set to 3, and the standard deviation is set to 2, meaning the typical quality of created record will be around 3, but there could be some with higher or lower.<br />
;qualityImprovementProb<br />
: Float64 representing the probability that an agent will improve a record's quality after using it. Value is fixed at 0.7 for the sake of simplicity and simulation feasibility.<br />
;recordCreationProb<br />
: Float64 representing the probability that an agent creates a new record when they are preparing an activity and decide not to search the database. Value is fixed at 0.3 for the sake of simplicity and simulation feasibility.<br />
;categories<br />
: Vector of integer representing the category ids of the db records. The vector is generated as range from 1 to 20, [1:20;].<br />
;targetSuccessfulness<br />
: Float64 value, which represents minimum success rate, that needs to be reached for the database to be considered "useful" in a long term. Value is 0.75.<br />
;nSuccessfullFromEpisode<br />
: An integer number representing how many successful searches per episode of the simulation have to occur in order for it to be considered "useful". Value is 4.<br />
;episodeLength<br />
: Integer which represents length of a one "episode" within the simulation, which in this case is a sequence of weeks for which the success rate of the db will be tested if it met required conditions. Value is set to 6, this means 6 weeks.<br />
<br />
==Flow==<br />
'''1.Initialization:'''<br />
<br />
*The database is created with empty vectors of records for each defined category (integer from 1 to 20).<br />
*A defined number of agents are created with default probabilityToSearch.<br />
*Optionally, a number of initial Record objects will be created (based on parameter BATCH_UPLOAD_SIZE), and randomly assigned to a random category within the database.<br />
<br />
'''2.Weekly Cycle (One Tick):'''<br />
<br />
*Each week (tick), each agent attempts to prepare an activity.<br />
*Each agent selects a random category.<br />
*Then each agent decides whether to search the database based on their current probabilityToSearch (It was originally designed to be able to dynamicaly calculate probabilityToSearch of agents independently, but for the same reason the recordCreationProb is global to all agents, also this variable was left the same for all agents).<br />
<br />
;Search Behavior:<br />
<br />
*If the agent decides to search, it looks up all records that matches it selected category.<br />
*If records are found, the agents samples without replacement a predefined number of records for evaluation. Each has different probability based on its quality. The more quality it has, the higher the probability to be chosen. (Weights are calculated like this [rec.quality / sum(r.quality for r in records) for rec in records])<br />
*An agent tries to pick for use randomly one record from those records. <br />
*Before the agent uses any of the found records, there has to be checked if they haven't been used in a defined "cooldown period", which is set to 54 weeks. Each agent keeps track of used records and the weeks where they where used.<br />
*If the record the agent tries to pick is on cooldown, the agent proceeds to trying another one from the sampled ones until it finds a cooled down one or until there are no more samples (usually in the beginning of the simulation when there are yot not created record in the db).<br />
*If the record is used, there is a probability of the agent improving the quality of that used record.<br />
<br />
;Record Creation Behavior:<br />
<br />
*If the agent decides not to search or if the search is unsuccessful, it has a chance of creating a new record (based on parameter recordCreationProb).<br />
*If a new record is created, it's assigned a randomly generated initial quality based on the lognormal distribution, and pushed to db under it's selected category.<br />
*Also there is kept record of total number oc record created so far during the simulation and the order number of each record is assigned to the record during its creation as its id. This way its possible to keep track of which records were used before by the given agent.<br />
<br />
'''3.Evaluation'''<br />
*Further the simulation tracks total search attempts and successes. The success is considered only when a record is successfully used for an activity and not when a record is found or searched for.<br />
*At the end of each week, a weekly success rate is calculated by dividing the amount of successful record usages by the number of attempts that were performed.<br />
*The simulation continues until the database has reached "sufficient" usability.<br />
*A database is considered as "sufficiently useful" when success rates in a defined episode length (6 weeks) are over a defined threshold (75%) for a given minimum number of successful weeks (4 out of 6). In other words, when this condition is met within a 3 month timeframe.<br />
<br />
<br />
Detailní popis modelu, včetně parametrů, oborů hodnot, schémat, omezení modelu, apod. Popis musí být natolik detailní, aby podle něj bylo možné experiment zopakovat (a to samozřejmě i bez toho, že by byly k dispozici příslušné soubory s modelem).<br />
<br />
=Results=<br />
In the last section of appended code there was realized an attempt to calculate the results simply by adding new function which whould call the main simulation given number of times and recorded the results so the variability caused by randomness could be viewed. Specifically how the required number of weeks and number of created records varied when running the simulation repeatedly.<br />
<br />
Unfortunately there has been some enexpected and probably undesired patterns occuring in the obtained "multi run" results. Most likely a skillissue on my side. Further elaboration follows.<br />
<br />
Also there is a bug/feature with my function which determines when the search process is successfull enough. Because i require certain amount of time to assess the stability of said successfullness, there is a minimal but fixed timeframe in the begining of the simulation. And because of this when the number of weeks required for the system to be recognized as usefull is measured, its value can not begin earlier than after said timeframe, so that is why the smallest number of weeks in the results are 21.<br />
<br />
Also the counter of created records does not count the records created via batch upload so when reading it needs to be kept in mind.<br />
==Single run==<br />
This means runing the multi run function for single iteration.<br />
<br />
But it was run manually three times.<br />
;batch 0 <br />
:weeks until "usefullness": 82, 51, 69<br />
:records created in db: 44, 40, 55<br />
<br />
;batch 10<br />
:weeks: 21, 33, 21<br />
:records: 21, 26, 19 <br />
<br />
;batch 30<br />
:weeks: 24, 21, 22<br />
:records: 26, 17, 18<br />
<br />
;batch 50<br />
:weeks: 21, 21, 21<br />
:records: 30, 18, 27<br />
<br />
It appears that the batch upload in the beginning realy speeds up the time required for the database to be considered usefull, but unfortunately the implementation can not ends earlier then after at least small fixed timeframe.<br />
Its obvious that the results are heavily influenced by the randomness in the model.<br />
<br />
==Multi run==<br />
;batch 0<br />
:weeks: [55, 72, 70, 78, 94, 114, 126, 120, 135, 140, 152, 156, 180, 161, 167]<br />
:records: [32, 129, 108, 195, 262, 316, 320, 308, 366, 373, 432, 442, 496, 486, 487]<br />
<br />
;batch 10<br />
:weeks: [35, 99, 99, 189, 249, 291, 298, 413, 413, 426, 452, 433, 471, 520, 564]<br />
:records: [35, 48, 43, 90, 93, 112, 116, 148, 133, 141, 143, 155, 163, 158, 188]<br />
<br />
;batch 30<br />
:weeks: [21, 67, 79, 105, 99, 97, 115, 132, 137, 149, 160, 158, 170, 178, 181]<br />
:records: [13, 170, 200, 227, 272, 254, 336, 316, 406, 423, 442, 415, 464, 496, 521]<br />
<br />
;batch 50<br />
:weeks: [33, 21, 82, 83, 91, 113, 123, 149, 145, 144, 152, 166, 164, 175, 192]<br />
:records: [58, 42, 187, 247, 271, 306, 331, 365, 397, 413, 468, 502, 495, 507, 540]<br />
<br />
Well, those are here just for fun because there is not much value in such results except for showing something does not work as expected.<br />
<br />
=Discussion=<br />
jak se Vám podařilo definovaný problém vyřešit<br />
<br />
<br />
=Code=<br />
This is my code on github, because I could not upload .jl file and a did not wanted to make zip: [https://raw.githubusercontent.com/simik394/simulace-populatingskautdb/refs/heads/main/simulace-nobatch.jl]<br />
<br />
And the home repo [https://github.com/simik394/simulace-populatingskautdb]<br />
<br />
[[User:Tros01|Tros01]] ([[User talk:Tros01|talk]]) 22:19, 19 January 2025 (CET)</div>Tros01http://www.simulace.info/index.php?title=Populating_the_database&diff=26540Populating the database2025-01-19T23:08:06Z<p>Tros01: /* Code */</p>
<hr />
<div>Úvodní odstavec<br />
<br />
=Problem definition=<br />
==Why?==<br />
Lets say that I have a database containing prepared activities and educational content for boy scouts group. Its purpose is to serve as a source of inspiration and eventually of collection of high quality content appropriate for kids during our weekly meetings or other occasions. From which source should be easy to get precisely only the desired results based on defined properties on each activity (eg. time needed for preparation, minimal number of players, etc.)<br />
<br />
BUT actually its currently more like a proof of concept and not a really operational tool. So accordingly there aren't yet any real records to speak about.<br />
This very early stage of development is exactly the reason why I think it is reasonable to think about how will the database be populated with data. As this will be crucial for its future usability and success. Therefore, the simulation should focus on modeling this data population process.<br />
==What?==<br />
To be precise, the simulation will be concerned with user behavior and related volume of stored records.<br />
<br />
It is important to say that user interface for reading is only the default web gui of the database itself (Neo4j), so the users will have to use the Cypher query language. So after they go through such a way to access the records, there better be some decent amount of useful ones in the database. This is because otherwise their whole effort would be pointless and the user would be discouraged from using the database again.<br />
<br />
Creating the records on the other hand will be easy and accessible as much as possible (user writes to google document in specified folder and with specified structure which enables then loading it programmaticaly into the database). This ease of creation is key to encouraging consistent contributions.<br />
<br />
And here comes the question whether this "natural" way of data population is enough, or rather how long will it take for the database to be able to provide satisfactory results for the user in majority of the cases and as such could be called a useful tool. If the time required would be too long, the users could lose interest of even contributing new content .<br />
Therefore, the simulation will model the rate of content creation and the subsequent impact on database searchability and usability.<br />
<br />
Additionally will be also evaluated the "batch population approach" to see weather it is worth considering to implement. This will involve creating a model of user behavior and content creation, simulating different scenarios, and analyzing the results.<br />
==Objectives==<br />
This simulation aims to predict the growth of the database, determine the feasibility of the current data population strategy and evaluate the alternative.<br />
<br />
#Predict the time needed to reach a critical mass of data sufficient for effective use.<br />
#Evaluate the effectiveness of the current data population method relatively to alternative.<br />
<br />
=Method=<br />
==Agent-based model==<br />
The core method used for this simulation is agent-based modeling (ABM). This approach was selected because it aligns well with the nature of the problem, which involves multiple individual users (agents) interacting with a shared environment (the database). Specifically, it enabled me to simulate:<br />
<br />
*Individual User Behaviors: Each agent acts independently, deciding whether to search the database, create a new record, or improve existing ones, based on their local information and probabilities.<br />
*Heterogeneity (Limited): While the agents initially are identical, they change during the simulation based on their interactions with the database.<br />
*Emergent System Behavior: The overall growth and usability of the database is not programmed directly, but emerges from the accumulation of individual actions.<br />
<br />
Alternatively the system dynamics or simple math equations could be used but neither of them would be more fitting for this usecase.<br />
While system dynamics could model the overall growth of the database as a system, it would not provide the same level of detail regarding individual user actions. System dynamics works well when dealing with aggregate levels and rates of change but isn't great for capturing how each agent behaviour individually impacts the system.<br />
<br />
Just as the equations could model a simplified database growth equation, but it would be extremely difficult to derive a model which includes agents success/fail feedback, record improvement and cooldown and thus it was not considered as applicable for this problem.<br />
==Julia==<br />
Because the ABM approach was chosen the NetLogo was concidered as environment for implemantation of the simulation, but also was the language Julia as it is also often used for simulations. In the end the Julia was chosen because of its more general usability and therefore more usecases when learned to use.<br />
<br />
diskuse možností řešení, výběr metody a prostředku (metod a prostředků) řešení, zdůvodnění výběru (jinými slovy, proč to chcete řešit tak, jak to chcete řešit, jaké jsou jiné alternativy a proč je ta Vámi zvolená pro tuto úlohu nejvhodnější)<br />
<br />
=Model=<br />
<br />
==Entities==<br />
;Database (db):<br />
A dictionary storing Record objects, categorized by integers representing different activity categories.<br />
*The keys of the dictionary are integers representing category id.<br />
*Each category is associated with a vector (array) of Record objects.<br />
*Initially, each category has an empty vector, which can be populated by new records.<br />
<br />
;Record:<br />
A struct containing:<br />
*id (Integer): A unique identifier for the record, auto-incrementing with each creation.<br />
*quality (Float64): Represents the perceived quality or usability of the record. <br />
<br />
(Originally it should more closely resamble the real live improvements by being represented by only range 1-10 as the real live records also can not be improved infinitelly, but in the end there was left simplier implemantation that just has a chance to improve the record during every picked to use event by random value withou top limit.)<br />
<br />
;Agent:<br />
A struct representing a user of the database.<br />
*probabilityToSearch (Float64): The agent's current probability of finding a useful record, it is based on past success of the agent when searching the db. This parameter influences agent's decision whether to search the db or not.<br />
*used (Dict{Int, Vector{Int}}): A dictionary that stores which record IDs have been used by agent and in which week the record has been used, so it won't be used by the same agent during a given cooldown period. Keys are record ids and values are vectors containing week integers in which the record has been used.<br />
<br />
==Variables==<br />
;NUM_AGENTS: <br />
: Integer representing the number of agents (users) participating in the simulation. Value is fixed at 3.<br />
;BATCH_UPLOAD_SIZES:<br />
: Vector of integers representing different sizes of initial record batches uploaded to the database. The values used in simulation are [0, 10].<br />
;initialQualityDist: <br />
: A lognormal distribution (LogNormal(3, 2)) used to generate the initial quality of new records. The mean is set to 3, and the standard deviation is set to 2, meaning the typical quality of created record will be around 3, but there could be some with higher or lower.<br />
;qualityImprovementProb<br />
: Float64 representing the probability that an agent will improve a record's quality after using it. Value is fixed at 0.7 for the sake of simplicity and simulation feasibility.<br />
;recordCreationProb<br />
: Float64 representing the probability that an agent creates a new record when they are preparing an activity and decide not to search the database. Value is fixed at 0.3 for the sake of simplicity and simulation feasibility.<br />
;categories<br />
: Vector of integer representing the category ids of the db records. The vector is generated as range from 1 to 20, [1:20;].<br />
;targetSuccessfulness<br />
: Float64 value, which represents minimum success rate, that needs to be reached for the database to be considered "useful" in a long term. Value is 0.75.<br />
;nSuccessfullFromEpisode<br />
: An integer number representing how many successful searches per episode of the simulation have to occur in order for it to be considered "useful". Value is 4.<br />
;episodeLength<br />
: Integer which represents length of a one "episode" within the simulation, which in this case is a sequence of weeks for which the success rate of the db will be tested if it met required conditions. Value is set to 6, this means 6 weeks.<br />
<br />
==Flow==<br />
'''1.Initialization:'''<br />
<br />
*The database is created with empty vectors of records for each defined category (integer from 1 to 20).<br />
*A defined number of agents are created with default probabilityToSearch.<br />
*Optionally, a number of initial Record objects will be created (based on parameter BATCH_UPLOAD_SIZE), and randomly assigned to a random category within the database.<br />
<br />
'''2.Weekly Cycle (One Tick):'''<br />
<br />
*Each week (tick), each agent attempts to prepare an activity.<br />
*Each agent selects a random category.<br />
*Then each agent decides whether to search the database based on their current probabilityToSearch (It was originally designed to be able to dynamicaly calculate probabilityToSearch of agents independently, but for the same reason the recordCreationProb is global to all agents, also this variable was left the same for all agents).<br />
<br />
;Search Behavior:<br />
<br />
*If the agent decides to search, it looks up all records that matches it selected category.<br />
*If records are found, the agents samples without replacement a predefined number of records for evaluation. Each has different probability based on its quality. The more quality it has, the higher the probability to be chosen. (Weights are calculated like this [rec.quality / sum(r.quality for r in records) for rec in records])<br />
*An agent tries to pick for use randomly one record from those records. <br />
*Before the agent uses any of the found records, there has to be checked if they haven't been used in a defined "cooldown period", which is set to 54 weeks. Each agent keeps track of used records and the weeks where they where used.<br />
*If the record the agent tries to pick is on cooldown, the agent proceeds to trying another one from the sampled ones until it finds a cooled down one or until there are no more samples (usually in the beginning of the simulation when there are yot not created record in the db).<br />
*If the record is used, there is a probability of the agent improving the quality of that used record.<br />
<br />
;Record Creation Behavior:<br />
<br />
*If the agent decides not to search or if the search is unsuccessful, it has a chance of creating a new record (based on parameter recordCreationProb).<br />
*If a new record is created, it's assigned a randomly generated initial quality based on the lognormal distribution, and pushed to db under it's selected category.<br />
*Also there is kept record of total number oc record created so far during the simulation and the order number of each record is assigned to the record during its creation as its id. This way its possible to keep track of which records were used before by the given agent.<br />
<br />
'''3.Evaluation'''<br />
*Further the simulation tracks total search attempts and successes. The success is considered only when a record is successfully used for an activity and not when a record is found or searched for.<br />
*At the end of each week, a weekly success rate is calculated by dividing the amount of successful record usages by the number of attempts that were performed.<br />
*The simulation continues until the database has reached "sufficient" usability.<br />
*A database is considered as "sufficiently useful" when success rates in a defined episode length (6 weeks) are over a defined threshold (75%) for a given minimum number of successful weeks (4 out of 6). In other words, when this condition is met within a 3 month timeframe.<br />
<br />
<br />
Detailní popis modelu, včetně parametrů, oborů hodnot, schémat, omezení modelu, apod. Popis musí být natolik detailní, aby podle něj bylo možné experiment zopakovat (a to samozřejmě i bez toho, že by byly k dispozici příslušné soubory s modelem).<br />
<br />
=Results=<br />
In the last section of appended code there was realized an attempt to calculate the results simply by adding new function which whould call the main simulation given number of times and recorded the results so the variability caused by randomness could be viewed. Specifically how the required number of weeks and number of created records varied when running the simulation repeatedly.<br />
<br />
Unfortunately there has been some enexpected and probably undesired patterns occuring in the obtained "multi run" results. Most likely a skillissue on my side. Further elaboration follows.<br />
<br />
Also there is a bug/feature with my function which determines when the search process is successfull enough. Because i require certain amount of time to assess the stability of said successfullness, there is a minimal but fixed timeframe in the begining of the simulation. And because of this when the number of weeks required for the system to be recognized as usefull is measured, its value can not begin earlier than after said timeframe, so that is why the smallest number of weeks in the results are 21.<br />
<br />
Also the counter of created records does not count the records created via batch upload so when reading it needs to be kept in mind.<br />
==Single run==<br />
This means runing the multi run function for single iteration.<br />
<br />
But it was run manually three times.<br />
;batch 0 <br />
:weeks until "usefullness": 82, 51, 69<br />
:records created in db: 44, 40, 55<br />
<br />
;batch 10<br />
:weeks: 21, 33, 21<br />
:records: 21, 26, 19 <br />
<br />
;batch 30<br />
:weeks: 24, 21, 22<br />
:records: 26, 17, 18<br />
<br />
;batch 50<br />
:weeks: 21, 21, 21<br />
:records: 30, 18, 27<br />
<br />
It appears that the batch upload in the beginning realy speeds up the time required for the database to be considered usefull, but unfortunately the implementation can not ends earlier then after at least small fixed timeframe.<br />
Its obvious that the results are heavily influenced by the randomness in the model.<br />
<br />
==Multi run==<br />
;batch 0<br />
:weeks: [55, 72, 70, 78, 94, 114, 126, 120, 135, 140, 152, 156, 180, 161, 167]<br />
:records: [32, 129, 108, 195, 262, 316, 320, 308, 366, 373, 432, 442, 496, 486, 487]<br />
<br />
<br />
;batch 10<br />
:weeks: [35, 99, 99, 189, 249, 291, 298, 413, 413, 426, 452, 433, 471, 520, 564]<br />
:records: [35, 48, 43, 90, 93, 112, 116, 148, 133, 141, 143, 155, 163, 158, 188]<br />
<br />
<br />
;batch 30<br />
:weeks: [21, 67, 79, 105, 99, 97, 115, 132, 137, 149, 160, 158, 170, 178, 181]<br />
:records: [13, 170, 200, 227, 272, 254, 336, 316, 406, 423, 442, 415, 464, 496, 521]<br />
<br />
;batch 50<br />
:weeks: [33, 21, 82, 83, 91, 113, 123, 149, 145, 144, 152, 166, 164, 175, 192]<br />
:records: [58, 42, 187, 247, 271, 306, 331, 365, 397, 413, 468, 502, 495, 507, 540]<br />
<br />
Well, those are here just for fun because there is not much value in such results except for showing something does not work as expected.<br />
<br />
=Discussion=<br />
jak se Vám podařilo definovaný problém vyřešit<br />
<br />
<br />
=Code=<br />
This is my code on github, because I could not upload .jl file and a did not wanted to make zip: [https://raw.githubusercontent.com/simik394/simulace-populatingskautdb/refs/heads/main/simulace-nobatch.jl]<br />
<br />
And the home repo [https://github.com/simik394/simulace-populatingskautdb]<br />
<br />
[[User:Tros01|Tros01]] ([[User talk:Tros01|talk]]) 22:19, 19 January 2025 (CET)</div>Tros01http://www.simulace.info/index.php?title=Populating_the_database&diff=26539Populating the database2025-01-19T22:57:47Z<p>Tros01: /* Results */</p>
<hr />
<div>Úvodní odstavec<br />
<br />
=Problem definition=<br />
==Why?==<br />
Lets say that I have a database containing prepared activities and educational content for boy scouts group. Its purpose is to serve as a source of inspiration and eventually of collection of high quality content appropriate for kids during our weekly meetings or other occasions. From which source should be easy to get precisely only the desired results based on defined properties on each activity (eg. time needed for preparation, minimal number of players, etc.)<br />
<br />
BUT actually its currently more like a proof of concept and not a really operational tool. So accordingly there aren't yet any real records to speak about.<br />
This very early stage of development is exactly the reason why I think it is reasonable to think about how will the database be populated with data. As this will be crucial for its future usability and success. Therefore, the simulation should focus on modeling this data population process.<br />
==What?==<br />
To be precise, the simulation will be concerned with user behavior and related volume of stored records.<br />
<br />
It is important to say that user interface for reading is only the default web gui of the database itself (Neo4j), so the users will have to use the Cypher query language. So after they go through such a way to access the records, there better be some decent amount of useful ones in the database. This is because otherwise their whole effort would be pointless and the user would be discouraged from using the database again.<br />
<br />
Creating the records on the other hand will be easy and accessible as much as possible (user writes to google document in specified folder and with specified structure which enables then loading it programmaticaly into the database). This ease of creation is key to encouraging consistent contributions.<br />
<br />
And here comes the question whether this "natural" way of data population is enough, or rather how long will it take for the database to be able to provide satisfactory results for the user in majority of the cases and as such could be called a useful tool. If the time required would be too long, the users could lose interest of even contributing new content .<br />
Therefore, the simulation will model the rate of content creation and the subsequent impact on database searchability and usability.<br />
<br />
Additionally will be also evaluated the "batch population approach" to see weather it is worth considering to implement. This will involve creating a model of user behavior and content creation, simulating different scenarios, and analyzing the results.<br />
==Objectives==<br />
This simulation aims to predict the growth of the database, determine the feasibility of the current data population strategy and evaluate the alternative.<br />
<br />
#Predict the time needed to reach a critical mass of data sufficient for effective use.<br />
#Evaluate the effectiveness of the current data population method relatively to alternative.<br />
<br />
=Method=<br />
==Agent-based model==<br />
The core method used for this simulation is agent-based modeling (ABM). This approach was selected because it aligns well with the nature of the problem, which involves multiple individual users (agents) interacting with a shared environment (the database). Specifically, it enabled me to simulate:<br />
<br />
*Individual User Behaviors: Each agent acts independently, deciding whether to search the database, create a new record, or improve existing ones, based on their local information and probabilities.<br />
*Heterogeneity (Limited): While the agents initially are identical, they change during the simulation based on their interactions with the database.<br />
*Emergent System Behavior: The overall growth and usability of the database is not programmed directly, but emerges from the accumulation of individual actions.<br />
<br />
Alternatively the system dynamics or simple math equations could be used but neither of them would be more fitting for this usecase.<br />
While system dynamics could model the overall growth of the database as a system, it would not provide the same level of detail regarding individual user actions. System dynamics works well when dealing with aggregate levels and rates of change but isn't great for capturing how each agent behaviour individually impacts the system.<br />
<br />
Just as the equations could model a simplified database growth equation, but it would be extremely difficult to derive a model which includes agents success/fail feedback, record improvement and cooldown and thus it was not considered as applicable for this problem.<br />
==Julia==<br />
Because the ABM approach was chosen the NetLogo was concidered as environment for implemantation of the simulation, but also was the language Julia as it is also often used for simulations. In the end the Julia was chosen because of its more general usability and therefore more usecases when learned to use.<br />
<br />
diskuse možností řešení, výběr metody a prostředku (metod a prostředků) řešení, zdůvodnění výběru (jinými slovy, proč to chcete řešit tak, jak to chcete řešit, jaké jsou jiné alternativy a proč je ta Vámi zvolená pro tuto úlohu nejvhodnější)<br />
<br />
=Model=<br />
<br />
==Entities==<br />
;Database (db):<br />
A dictionary storing Record objects, categorized by integers representing different activity categories.<br />
*The keys of the dictionary are integers representing category id.<br />
*Each category is associated with a vector (array) of Record objects.<br />
*Initially, each category has an empty vector, which can be populated by new records.<br />
<br />
;Record:<br />
A struct containing:<br />
*id (Integer): A unique identifier for the record, auto-incrementing with each creation.<br />
*quality (Float64): Represents the perceived quality or usability of the record. <br />
<br />
(Originally it should more closely resamble the real live improvements by being represented by only range 1-10 as the real live records also can not be improved infinitelly, but in the end there was left simplier implemantation that just has a chance to improve the record during every picked to use event by random value withou top limit.)<br />
<br />
;Agent:<br />
A struct representing a user of the database.<br />
*probabilityToSearch (Float64): The agent's current probability of finding a useful record, it is based on past success of the agent when searching the db. This parameter influences agent's decision whether to search the db or not.<br />
*used (Dict{Int, Vector{Int}}): A dictionary that stores which record IDs have been used by agent and in which week the record has been used, so it won't be used by the same agent during a given cooldown period. Keys are record ids and values are vectors containing week integers in which the record has been used.<br />
<br />
==Variables==<br />
;NUM_AGENTS: <br />
: Integer representing the number of agents (users) participating in the simulation. Value is fixed at 3.<br />
;BATCH_UPLOAD_SIZES:<br />
: Vector of integers representing different sizes of initial record batches uploaded to the database. The values used in simulation are [0, 10].<br />
;initialQualityDist: <br />
: A lognormal distribution (LogNormal(3, 2)) used to generate the initial quality of new records. The mean is set to 3, and the standard deviation is set to 2, meaning the typical quality of created record will be around 3, but there could be some with higher or lower.<br />
;qualityImprovementProb<br />
: Float64 representing the probability that an agent will improve a record's quality after using it. Value is fixed at 0.7 for the sake of simplicity and simulation feasibility.<br />
;recordCreationProb<br />
: Float64 representing the probability that an agent creates a new record when they are preparing an activity and decide not to search the database. Value is fixed at 0.3 for the sake of simplicity and simulation feasibility.<br />
;categories<br />
: Vector of integer representing the category ids of the db records. The vector is generated as range from 1 to 20, [1:20;].<br />
;targetSuccessfulness<br />
: Float64 value, which represents minimum success rate, that needs to be reached for the database to be considered "useful" in a long term. Value is 0.75.<br />
;nSuccessfullFromEpisode<br />
: An integer number representing how many successful searches per episode of the simulation have to occur in order for it to be considered "useful". Value is 4.<br />
;episodeLength<br />
: Integer which represents length of a one "episode" within the simulation, which in this case is a sequence of weeks for which the success rate of the db will be tested if it met required conditions. Value is set to 6, this means 6 weeks.<br />
<br />
==Flow==<br />
'''1.Initialization:'''<br />
<br />
*The database is created with empty vectors of records for each defined category (integer from 1 to 20).<br />
*A defined number of agents are created with default probabilityToSearch.<br />
*Optionally, a number of initial Record objects will be created (based on parameter BATCH_UPLOAD_SIZE), and randomly assigned to a random category within the database.<br />
<br />
'''2.Weekly Cycle (One Tick):'''<br />
<br />
*Each week (tick), each agent attempts to prepare an activity.<br />
*Each agent selects a random category.<br />
*Then each agent decides whether to search the database based on their current probabilityToSearch (It was originally designed to be able to dynamicaly calculate probabilityToSearch of agents independently, but for the same reason the recordCreationProb is global to all agents, also this variable was left the same for all agents).<br />
<br />
;Search Behavior:<br />
<br />
*If the agent decides to search, it looks up all records that matches it selected category.<br />
*If records are found, the agents samples without replacement a predefined number of records for evaluation. Each has different probability based on its quality. The more quality it has, the higher the probability to be chosen. (Weights are calculated like this [rec.quality / sum(r.quality for r in records) for rec in records])<br />
*An agent tries to pick for use randomly one record from those records. <br />
*Before the agent uses any of the found records, there has to be checked if they haven't been used in a defined "cooldown period", which is set to 54 weeks. Each agent keeps track of used records and the weeks where they where used.<br />
*If the record the agent tries to pick is on cooldown, the agent proceeds to trying another one from the sampled ones until it finds a cooled down one or until there are no more samples (usually in the beginning of the simulation when there are yot not created record in the db).<br />
*If the record is used, there is a probability of the agent improving the quality of that used record.<br />
<br />
;Record Creation Behavior:<br />
<br />
*If the agent decides not to search or if the search is unsuccessful, it has a chance of creating a new record (based on parameter recordCreationProb).<br />
*If a new record is created, it's assigned a randomly generated initial quality based on the lognormal distribution, and pushed to db under it's selected category.<br />
*Also there is kept record of total number oc record created so far during the simulation and the order number of each record is assigned to the record during its creation as its id. This way its possible to keep track of which records were used before by the given agent.<br />
<br />
'''3.Evaluation'''<br />
*Further the simulation tracks total search attempts and successes. The success is considered only when a record is successfully used for an activity and not when a record is found or searched for.<br />
*At the end of each week, a weekly success rate is calculated by dividing the amount of successful record usages by the number of attempts that were performed.<br />
*The simulation continues until the database has reached "sufficient" usability.<br />
*A database is considered as "sufficiently useful" when success rates in a defined episode length (6 weeks) are over a defined threshold (75%) for a given minimum number of successful weeks (4 out of 6). In other words, when this condition is met within a 3 month timeframe.<br />
<br />
<br />
Detailní popis modelu, včetně parametrů, oborů hodnot, schémat, omezení modelu, apod. Popis musí být natolik detailní, aby podle něj bylo možné experiment zopakovat (a to samozřejmě i bez toho, že by byly k dispozici příslušné soubory s modelem).<br />
<br />
=Results=<br />
In the last section of appended code there was realized an attempt to calculate the results simply by adding new function which whould call the main simulation given number of times and recorded the results so the variability caused by randomness could be viewed. Specifically how the required number of weeks and number of created records varied when running the simulation repeatedly.<br />
<br />
Unfortunately there has been some enexpected and probably undesired patterns occuring in the obtained "multi run" results. Most likely a skillissue on my side. Further elaboration follows.<br />
<br />
Also there is a bug/feature with my function which determines when the search process is successfull enough. Because i require certain amount of time to assess the stability of said successfullness, there is a minimal but fixed timeframe in the begining of the simulation. And because of this when the number of weeks required for the system to be recognized as usefull is measured, its value can not begin earlier than after said timeframe, so that is why the smallest number of weeks in the results are 21.<br />
<br />
Also the counter of created records does not count the records created via batch upload so when reading it needs to be kept in mind.<br />
==Single run==<br />
This means runing the multi run function for single iteration.<br />
<br />
But it was run manually three times.<br />
;batch 0 <br />
:weeks until "usefullness": 82, 51, 69<br />
:records created in db: 44, 40, 55<br />
<br />
;batch 10<br />
:weeks: 21, 33, 21<br />
:records: 21, 26, 19 <br />
<br />
;batch 30<br />
:weeks: 24, 21, 22<br />
:records: 26, 17, 18<br />
<br />
;batch 50<br />
:weeks: 21, 21, 21<br />
:records: 30, 18, 27<br />
<br />
It appears that the batch upload in the beginning realy speeds up the time required for the database to be considered usefull, but unfortunately the implementation can not ends earlier then after at least small fixed timeframe.<br />
Its obvious that the results are heavily influenced by the randomness in the model.<br />
<br />
==Multi run==<br />
;batch 0<br />
:weeks: [55, 72, 70, 78, 94, 114, 126, 120, 135, 140, 152, 156, 180, 161, 167]<br />
:records: [32, 129, 108, 195, 262, 316, 320, 308, 366, 373, 432, 442, 496, 486, 487]<br />
<br />
<br />
;batch 10<br />
:weeks: [35, 99, 99, 189, 249, 291, 298, 413, 413, 426, 452, 433, 471, 520, 564]<br />
:records: [35, 48, 43, 90, 93, 112, 116, 148, 133, 141, 143, 155, 163, 158, 188]<br />
<br />
<br />
;batch 30<br />
:weeks: [21, 67, 79, 105, 99, 97, 115, 132, 137, 149, 160, 158, 170, 178, 181]<br />
:records: [13, 170, 200, 227, 272, 254, 336, 316, 406, 423, 442, 415, 464, 496, 521]<br />
<br />
;batch 50<br />
:weeks: [33, 21, 82, 83, 91, 113, 123, 149, 145, 144, 152, 166, 164, 175, 192]<br />
:records: [58, 42, 187, 247, 271, 306, 331, 365, 397, 413, 468, 502, 495, 507, 540]<br />
<br />
Well, those are here just for fun because there is not much value in such results except for showing something does not work as expected.<br />
<br />
=Discussion=<br />
jak se Vám podařilo definovaný problém vyřešit<br />
<br />
<br />
=Code=<br />
<br />
g<br />
[[User:Tros01|Tros01]] ([[User talk:Tros01|talk]]) 22:19, 19 January 2025 (CET)</div>Tros01http://www.simulace.info/index.php?title=Populating_the_database&diff=26538Populating the database2025-01-19T22:51:44Z<p>Tros01: /* Single run */</p>
<hr />
<div>Úvodní odstavec<br />
<br />
=Problem definition=<br />
==Why?==<br />
Lets say that I have a database containing prepared activities and educational content for boy scouts group. Its purpose is to serve as a source of inspiration and eventually of collection of high quality content appropriate for kids during our weekly meetings or other occasions. From which source should be easy to get precisely only the desired results based on defined properties on each activity (eg. time needed for preparation, minimal number of players, etc.)<br />
<br />
BUT actually its currently more like a proof of concept and not a really operational tool. So accordingly there aren't yet any real records to speak about.<br />
This very early stage of development is exactly the reason why I think it is reasonable to think about how will the database be populated with data. As this will be crucial for its future usability and success. Therefore, the simulation should focus on modeling this data population process.<br />
==What?==<br />
To be precise, the simulation will be concerned with user behavior and related volume of stored records.<br />
<br />
It is important to say that user interface for reading is only the default web gui of the database itself (Neo4j), so the users will have to use the Cypher query language. So after they go through such a way to access the records, there better be some decent amount of useful ones in the database. This is because otherwise their whole effort would be pointless and the user would be discouraged from using the database again.<br />
<br />
Creating the records on the other hand will be easy and accessible as much as possible (user writes to google document in specified folder and with specified structure which enables then loading it programmaticaly into the database). This ease of creation is key to encouraging consistent contributions.<br />
<br />
And here comes the question whether this "natural" way of data population is enough, or rather how long will it take for the database to be able to provide satisfactory results for the user in majority of the cases and as such could be called a useful tool. If the time required would be too long, the users could lose interest of even contributing new content .<br />
Therefore, the simulation will model the rate of content creation and the subsequent impact on database searchability and usability.<br />
<br />
Additionally will be also evaluated the "batch population approach" to see weather it is worth considering to implement. This will involve creating a model of user behavior and content creation, simulating different scenarios, and analyzing the results.<br />
==Objectives==<br />
This simulation aims to predict the growth of the database, determine the feasibility of the current data population strategy and evaluate the alternative.<br />
<br />
#Predict the time needed to reach a critical mass of data sufficient for effective use.<br />
#Evaluate the effectiveness of the current data population method relatively to alternative.<br />
<br />
=Method=<br />
==Agent-based model==<br />
The core method used for this simulation is agent-based modeling (ABM). This approach was selected because it aligns well with the nature of the problem, which involves multiple individual users (agents) interacting with a shared environment (the database). Specifically, it enabled me to simulate:<br />
<br />
*Individual User Behaviors: Each agent acts independently, deciding whether to search the database, create a new record, or improve existing ones, based on their local information and probabilities.<br />
*Heterogeneity (Limited): While the agents initially are identical, they change during the simulation based on their interactions with the database.<br />
*Emergent System Behavior: The overall growth and usability of the database is not programmed directly, but emerges from the accumulation of individual actions.<br />
<br />
Alternatively the system dynamics or simple math equations could be used but neither of them would be more fitting for this usecase.<br />
While system dynamics could model the overall growth of the database as a system, it would not provide the same level of detail regarding individual user actions. System dynamics works well when dealing with aggregate levels and rates of change but isn't great for capturing how each agent behaviour individually impacts the system.<br />
<br />
Just as the equations could model a simplified database growth equation, but it would be extremely difficult to derive a model which includes agents success/fail feedback, record improvement and cooldown and thus it was not considered as applicable for this problem.<br />
==Julia==<br />
Because the ABM approach was chosen the NetLogo was concidered as environment for implemantation of the simulation, but also was the language Julia as it is also often used for simulations. In the end the Julia was chosen because of its more general usability and therefore more usecases when learned to use.<br />
<br />
diskuse možností řešení, výběr metody a prostředku (metod a prostředků) řešení, zdůvodnění výběru (jinými slovy, proč to chcete řešit tak, jak to chcete řešit, jaké jsou jiné alternativy a proč je ta Vámi zvolená pro tuto úlohu nejvhodnější)<br />
<br />
=Model=<br />
<br />
==Entities==<br />
;Database (db):<br />
A dictionary storing Record objects, categorized by integers representing different activity categories.<br />
*The keys of the dictionary are integers representing category id.<br />
*Each category is associated with a vector (array) of Record objects.<br />
*Initially, each category has an empty vector, which can be populated by new records.<br />
<br />
;Record:<br />
A struct containing:<br />
*id (Integer): A unique identifier for the record, auto-incrementing with each creation.<br />
*quality (Float64): Represents the perceived quality or usability of the record. <br />
<br />
(Originally it should more closely resamble the real live improvements by being represented by only range 1-10 as the real live records also can not be improved infinitelly, but in the end there was left simplier implemantation that just has a chance to improve the record during every picked to use event by random value withou top limit.)<br />
<br />
;Agent:<br />
A struct representing a user of the database.<br />
*probabilityToSearch (Float64): The agent's current probability of finding a useful record, it is based on past success of the agent when searching the db. This parameter influences agent's decision whether to search the db or not.<br />
*used (Dict{Int, Vector{Int}}): A dictionary that stores which record IDs have been used by agent and in which week the record has been used, so it won't be used by the same agent during a given cooldown period. Keys are record ids and values are vectors containing week integers in which the record has been used.<br />
<br />
==Variables==<br />
;NUM_AGENTS: <br />
: Integer representing the number of agents (users) participating in the simulation. Value is fixed at 3.<br />
;BATCH_UPLOAD_SIZES:<br />
: Vector of integers representing different sizes of initial record batches uploaded to the database. The values used in simulation are [0, 10].<br />
;initialQualityDist: <br />
: A lognormal distribution (LogNormal(3, 2)) used to generate the initial quality of new records. The mean is set to 3, and the standard deviation is set to 2, meaning the typical quality of created record will be around 3, but there could be some with higher or lower.<br />
;qualityImprovementProb<br />
: Float64 representing the probability that an agent will improve a record's quality after using it. Value is fixed at 0.7 for the sake of simplicity and simulation feasibility.<br />
;recordCreationProb<br />
: Float64 representing the probability that an agent creates a new record when they are preparing an activity and decide not to search the database. Value is fixed at 0.3 for the sake of simplicity and simulation feasibility.<br />
;categories<br />
: Vector of integer representing the category ids of the db records. The vector is generated as range from 1 to 20, [1:20;].<br />
;targetSuccessfulness<br />
: Float64 value, which represents minimum success rate, that needs to be reached for the database to be considered "useful" in a long term. Value is 0.75.<br />
;nSuccessfullFromEpisode<br />
: An integer number representing how many successful searches per episode of the simulation have to occur in order for it to be considered "useful". Value is 4.<br />
;episodeLength<br />
: Integer which represents length of a one "episode" within the simulation, which in this case is a sequence of weeks for which the success rate of the db will be tested if it met required conditions. Value is set to 6, this means 6 weeks.<br />
<br />
==Flow==<br />
'''1.Initialization:'''<br />
<br />
*The database is created with empty vectors of records for each defined category (integer from 1 to 20).<br />
*A defined number of agents are created with default probabilityToSearch.<br />
*Optionally, a number of initial Record objects will be created (based on parameter BATCH_UPLOAD_SIZE), and randomly assigned to a random category within the database.<br />
<br />
'''2.Weekly Cycle (One Tick):'''<br />
<br />
*Each week (tick), each agent attempts to prepare an activity.<br />
*Each agent selects a random category.<br />
*Then each agent decides whether to search the database based on their current probabilityToSearch (It was originally designed to be able to dynamicaly calculate probabilityToSearch of agents independently, but for the same reason the recordCreationProb is global to all agents, also this variable was left the same for all agents).<br />
<br />
;Search Behavior:<br />
<br />
*If the agent decides to search, it looks up all records that matches it selected category.<br />
*If records are found, the agents samples without replacement a predefined number of records for evaluation. Each has different probability based on its quality. The more quality it has, the higher the probability to be chosen. (Weights are calculated like this [rec.quality / sum(r.quality for r in records) for rec in records])<br />
*An agent tries to pick for use randomly one record from those records. <br />
*Before the agent uses any of the found records, there has to be checked if they haven't been used in a defined "cooldown period", which is set to 54 weeks. Each agent keeps track of used records and the weeks where they where used.<br />
*If the record the agent tries to pick is on cooldown, the agent proceeds to trying another one from the sampled ones until it finds a cooled down one or until there are no more samples (usually in the beginning of the simulation when there are yot not created record in the db).<br />
*If the record is used, there is a probability of the agent improving the quality of that used record.<br />
<br />
;Record Creation Behavior:<br />
<br />
*If the agent decides not to search or if the search is unsuccessful, it has a chance of creating a new record (based on parameter recordCreationProb).<br />
*If a new record is created, it's assigned a randomly generated initial quality based on the lognormal distribution, and pushed to db under it's selected category.<br />
*Also there is kept record of total number oc record created so far during the simulation and the order number of each record is assigned to the record during its creation as its id. This way its possible to keep track of which records were used before by the given agent.<br />
<br />
'''3.Evaluation'''<br />
*Further the simulation tracks total search attempts and successes. The success is considered only when a record is successfully used for an activity and not when a record is found or searched for.<br />
*At the end of each week, a weekly success rate is calculated by dividing the amount of successful record usages by the number of attempts that were performed.<br />
*The simulation continues until the database has reached "sufficient" usability.<br />
*A database is considered as "sufficiently useful" when success rates in a defined episode length (6 weeks) are over a defined threshold (75%) for a given minimum number of successful weeks (4 out of 6). In other words, when this condition is met within a 3 month timeframe.<br />
<br />
<br />
Detailní popis modelu, včetně parametrů, oborů hodnot, schémat, omezení modelu, apod. Popis musí být natolik detailní, aby podle něj bylo možné experiment zopakovat (a to samozřejmě i bez toho, že by byly k dispozici příslušné soubory s modelem).<br />
<br />
=Results=<br />
In the last section of appended code there was realized an attempt to calculate the results simply by adding new function which whould call the main simulation given number of times and recorded the results so the variability caused by randomness could be viewed. Specifically how the required number of weeks and number of created records varied when running the simulation repeatedly.<br />
<br />
Unfortunately there has been some enexpected and probably undesired patterns occuring in the obtained "multi run" results. Most likely a skillissue on my side. Further elaboration follows.<br />
<br />
Also there is a bug/feature with my function which determines when the search process is successfull enough. Because i require certain amount of time to assess the stability of said successfullness, there is a minimal but fixed timeframe in the begining of the simulation. And because of this when the number of weeks required for the system to be recognized as usefull is measured, its value can not begin earlier than after said timeframe, so that is why the smallest number of weeks in the results are 21.<br />
<br />
Also the counter of created records does not count the records created via batch upload so when reading it needs to be kept in mind.<br />
==Single run==<br />
This means runing the multi run function for single iteration.<br />
<br />
But it was run manually three times.<br />
;batch 0 <br />
:weeks until "usefullness": 82, 51, 69<br />
:records created in db: 44, 40, 55<br />
<br />
;batch 10<br />
:weeks: 21, 33, 21<br />
:records: 21, 26, 19 <br />
<br />
;batch 30<br />
:weeks: 24, 21, 22<br />
:records: 26, 17, 18<br />
<br />
;batch 50<br />
:weeks: 21, 21, 21<br />
:records: 30, 18, 27<br />
<br />
It appears that the batch upload in the beginning realy speeds up the time required for the database to be considered usefull, but unfortunately<br />
<br />
==Multi run==<br />
;batch 0<br />
[55, 72, 70, 78, 94, 114, 126, 120, 135, 140, 152, 156, 180, 161, 167]<br />
[32, 129, 108, 195, 262, 316, 320, 308, 366, 373, 432, 442, 496, 486, 487]<br />
<br />
<br />
;batch 10<br />
[35, 99, 99, 189, 249, 291, 298, 413, 413, 426, 452, 433, 471, 520, 564]<br />
[35, 48, 43, 90, 93, 112, 116, 148, 133, 141, 143, 155, 163, 158, 188]<br />
<br />
<br />
;batch 30<br />
[21, 67, 79, 105, 99, 97, 115, 132, 137, 149, 160, 158, 170, 178, 181]<br />
[13, 170, 200, 227, 272, 254, 336, 316, 406, 423, 442, 415, 464, 496, 521]<br />
<br />
;batch 50<br />
[33, 21, 82, 83, 91, 113, 123, 149, 145, 144, 152, 166, 164, 175, 192]<br />
[58, 42, 187, 247, 271, 306, 331, 365, 397, 413, 468, 502, 495, 507, 540]<br />
<br />
<br />
výpis výsledků, jejich analýza, interpretace, zhodnocení.<br />
<br />
=Discussion=<br />
jak se Vám podařilo definovaný problém vyřešit<br />
<br />
<br />
=Code=<br />
<br />
g<br />
[[User:Tros01|Tros01]] ([[User talk:Tros01|talk]]) 22:19, 19 January 2025 (CET)</div>Tros01http://www.simulace.info/index.php?title=Populating_the_database&diff=26537Populating the database2025-01-19T22:51:32Z<p>Tros01: /* Results */</p>
<hr />
<div>Úvodní odstavec<br />
<br />
=Problem definition=<br />
==Why?==<br />
Lets say that I have a database containing prepared activities and educational content for boy scouts group. Its purpose is to serve as a source of inspiration and eventually of collection of high quality content appropriate for kids during our weekly meetings or other occasions. From which source should be easy to get precisely only the desired results based on defined properties on each activity (eg. time needed for preparation, minimal number of players, etc.)<br />
<br />
BUT actually its currently more like a proof of concept and not a really operational tool. So accordingly there aren't yet any real records to speak about.<br />
This very early stage of development is exactly the reason why I think it is reasonable to think about how will the database be populated with data. As this will be crucial for its future usability and success. Therefore, the simulation should focus on modeling this data population process.<br />
==What?==<br />
To be precise, the simulation will be concerned with user behavior and related volume of stored records.<br />
<br />
It is important to say that user interface for reading is only the default web gui of the database itself (Neo4j), so the users will have to use the Cypher query language. So after they go through such a way to access the records, there better be some decent amount of useful ones in the database. This is because otherwise their whole effort would be pointless and the user would be discouraged from using the database again.<br />
<br />
Creating the records on the other hand will be easy and accessible as much as possible (user writes to google document in specified folder and with specified structure which enables then loading it programmaticaly into the database). This ease of creation is key to encouraging consistent contributions.<br />
<br />
And here comes the question whether this "natural" way of data population is enough, or rather how long will it take for the database to be able to provide satisfactory results for the user in majority of the cases and as such could be called a useful tool. If the time required would be too long, the users could lose interest of even contributing new content .<br />
Therefore, the simulation will model the rate of content creation and the subsequent impact on database searchability and usability.<br />
<br />
Additionally will be also evaluated the "batch population approach" to see weather it is worth considering to implement. This will involve creating a model of user behavior and content creation, simulating different scenarios, and analyzing the results.<br />
==Objectives==<br />
This simulation aims to predict the growth of the database, determine the feasibility of the current data population strategy and evaluate the alternative.<br />
<br />
#Predict the time needed to reach a critical mass of data sufficient for effective use.<br />
#Evaluate the effectiveness of the current data population method relatively to alternative.<br />
<br />
=Method=<br />
==Agent-based model==<br />
The core method used for this simulation is agent-based modeling (ABM). This approach was selected because it aligns well with the nature of the problem, which involves multiple individual users (agents) interacting with a shared environment (the database). Specifically, it enabled me to simulate:<br />
<br />
*Individual User Behaviors: Each agent acts independently, deciding whether to search the database, create a new record, or improve existing ones, based on their local information and probabilities.<br />
*Heterogeneity (Limited): While the agents initially are identical, they change during the simulation based on their interactions with the database.<br />
*Emergent System Behavior: The overall growth and usability of the database is not programmed directly, but emerges from the accumulation of individual actions.<br />
<br />
Alternatively the system dynamics or simple math equations could be used but neither of them would be more fitting for this usecase.<br />
While system dynamics could model the overall growth of the database as a system, it would not provide the same level of detail regarding individual user actions. System dynamics works well when dealing with aggregate levels and rates of change but isn't great for capturing how each agent behaviour individually impacts the system.<br />
<br />
Just as the equations could model a simplified database growth equation, but it would be extremely difficult to derive a model which includes agents success/fail feedback, record improvement and cooldown and thus it was not considered as applicable for this problem.<br />
==Julia==<br />
Because the ABM approach was chosen the NetLogo was concidered as environment for implemantation of the simulation, but also was the language Julia as it is also often used for simulations. In the end the Julia was chosen because of its more general usability and therefore more usecases when learned to use.<br />
<br />
diskuse možností řešení, výběr metody a prostředku (metod a prostředků) řešení, zdůvodnění výběru (jinými slovy, proč to chcete řešit tak, jak to chcete řešit, jaké jsou jiné alternativy a proč je ta Vámi zvolená pro tuto úlohu nejvhodnější)<br />
<br />
=Model=<br />
<br />
==Entities==<br />
;Database (db):<br />
A dictionary storing Record objects, categorized by integers representing different activity categories.<br />
*The keys of the dictionary are integers representing category id.<br />
*Each category is associated with a vector (array) of Record objects.<br />
*Initially, each category has an empty vector, which can be populated by new records.<br />
<br />
;Record:<br />
A struct containing:<br />
*id (Integer): A unique identifier for the record, auto-incrementing with each creation.<br />
*quality (Float64): Represents the perceived quality or usability of the record. <br />
<br />
(Originally it should more closely resamble the real live improvements by being represented by only range 1-10 as the real live records also can not be improved infinitelly, but in the end there was left simplier implemantation that just has a chance to improve the record during every picked to use event by random value withou top limit.)<br />
<br />
;Agent:<br />
A struct representing a user of the database.<br />
*probabilityToSearch (Float64): The agent's current probability of finding a useful record, it is based on past success of the agent when searching the db. This parameter influences agent's decision whether to search the db or not.<br />
*used (Dict{Int, Vector{Int}}): A dictionary that stores which record IDs have been used by agent and in which week the record has been used, so it won't be used by the same agent during a given cooldown period. Keys are record ids and values are vectors containing week integers in which the record has been used.<br />
<br />
==Variables==<br />
;NUM_AGENTS: <br />
: Integer representing the number of agents (users) participating in the simulation. Value is fixed at 3.<br />
;BATCH_UPLOAD_SIZES:<br />
: Vector of integers representing different sizes of initial record batches uploaded to the database. The values used in simulation are [0, 10].<br />
;initialQualityDist: <br />
: A lognormal distribution (LogNormal(3, 2)) used to generate the initial quality of new records. The mean is set to 3, and the standard deviation is set to 2, meaning the typical quality of created record will be around 3, but there could be some with higher or lower.<br />
;qualityImprovementProb<br />
: Float64 representing the probability that an agent will improve a record's quality after using it. Value is fixed at 0.7 for the sake of simplicity and simulation feasibility.<br />
;recordCreationProb<br />
: Float64 representing the probability that an agent creates a new record when they are preparing an activity and decide not to search the database. Value is fixed at 0.3 for the sake of simplicity and simulation feasibility.<br />
;categories<br />
: Vector of integer representing the category ids of the db records. The vector is generated as range from 1 to 20, [1:20;].<br />
;targetSuccessfulness<br />
: Float64 value, which represents minimum success rate, that needs to be reached for the database to be considered "useful" in a long term. Value is 0.75.<br />
;nSuccessfullFromEpisode<br />
: An integer number representing how many successful searches per episode of the simulation have to occur in order for it to be considered "useful". Value is 4.<br />
;episodeLength<br />
: Integer which represents length of a one "episode" within the simulation, which in this case is a sequence of weeks for which the success rate of the db will be tested if it met required conditions. Value is set to 6, this means 6 weeks.<br />
<br />
==Flow==<br />
'''1.Initialization:'''<br />
<br />
*The database is created with empty vectors of records for each defined category (integer from 1 to 20).<br />
*A defined number of agents are created with default probabilityToSearch.<br />
*Optionally, a number of initial Record objects will be created (based on parameter BATCH_UPLOAD_SIZE), and randomly assigned to a random category within the database.<br />
<br />
'''2.Weekly Cycle (One Tick):'''<br />
<br />
*Each week (tick), each agent attempts to prepare an activity.<br />
*Each agent selects a random category.<br />
*Then each agent decides whether to search the database based on their current probabilityToSearch (It was originally designed to be able to dynamicaly calculate probabilityToSearch of agents independently, but for the same reason the recordCreationProb is global to all agents, also this variable was left the same for all agents).<br />
<br />
;Search Behavior:<br />
<br />
*If the agent decides to search, it looks up all records that matches it selected category.<br />
*If records are found, the agents samples without replacement a predefined number of records for evaluation. Each has different probability based on its quality. The more quality it has, the higher the probability to be chosen. (Weights are calculated like this [rec.quality / sum(r.quality for r in records) for rec in records])<br />
*An agent tries to pick for use randomly one record from those records. <br />
*Before the agent uses any of the found records, there has to be checked if they haven't been used in a defined "cooldown period", which is set to 54 weeks. Each agent keeps track of used records and the weeks where they where used.<br />
*If the record the agent tries to pick is on cooldown, the agent proceeds to trying another one from the sampled ones until it finds a cooled down one or until there are no more samples (usually in the beginning of the simulation when there are yot not created record in the db).<br />
*If the record is used, there is a probability of the agent improving the quality of that used record.<br />
<br />
;Record Creation Behavior:<br />
<br />
*If the agent decides not to search or if the search is unsuccessful, it has a chance of creating a new record (based on parameter recordCreationProb).<br />
*If a new record is created, it's assigned a randomly generated initial quality based on the lognormal distribution, and pushed to db under it's selected category.<br />
*Also there is kept record of total number oc record created so far during the simulation and the order number of each record is assigned to the record during its creation as its id. This way its possible to keep track of which records were used before by the given agent.<br />
<br />
'''3.Evaluation'''<br />
*Further the simulation tracks total search attempts and successes. The success is considered only when a record is successfully used for an activity and not when a record is found or searched for.<br />
*At the end of each week, a weekly success rate is calculated by dividing the amount of successful record usages by the number of attempts that were performed.<br />
*The simulation continues until the database has reached "sufficient" usability.<br />
*A database is considered as "sufficiently useful" when success rates in a defined episode length (6 weeks) are over a defined threshold (75%) for a given minimum number of successful weeks (4 out of 6). In other words, when this condition is met within a 3 month timeframe.<br />
<br />
<br />
Detailní popis modelu, včetně parametrů, oborů hodnot, schémat, omezení modelu, apod. Popis musí být natolik detailní, aby podle něj bylo možné experiment zopakovat (a to samozřejmě i bez toho, že by byly k dispozici příslušné soubory s modelem).<br />
<br />
=Results=<br />
In the last section of appended code there was realized an attempt to calculate the results simply by adding new function which whould call the main simulation given number of times and recorded the results so the variability caused by randomness could be viewed. Specifically how the required number of weeks and number of created records varied when running the simulation repeatedly.<br />
<br />
Unfortunately there has been some enexpected and probably undesired patterns occuring in the obtained "multi run" results. Most likely a skillissue on my side. Further elaboration follows.<br />
<br />
Also there is a bug/feature with my function which determines when the search process is successfull enough. Because i require certain amount of time to assess the stability of said successfullness, there is a minimal but fixed timeframe in the begining of the simulation. And because of this when the number of weeks required for the system to be recognized as usefull is measured, its value can not begin earlier than after said timeframe, so that is why the smallest number of weeks in the results are 21.<br />
<br />
Also the counter of created records does not count the records created via batch upload so when reading it needs to be kept in mind.<br />
==Single run==<br />
This means runing the multi run function for single iteration.<br />
<br />
But it was run manually three times.<br />
;batch 0 <br />
:weeks until "usefullness": 82, 51, 69<br />
:records created in db: 44, 40, 55<br />
<br />
;batch 10<br />
:weeks: 21, 33, 21<br />
:records: 21, 26, 19 <br />
<br />
;batch 30<br />
:weeks: 24, 21, 22<br />
:records: 26, 17, 18<br />
<br />
;batch 50<br />
:weeks: 21, 21, 21<br />
:records: 30, 18, 27<br />
<br />
It appears that the batch upload in the beginning realy speeds up the time required for the database to be considered usefull, but unfortunately<br />
==Multi run==<br />
;batch 0<br />
[55, 72, 70, 78, 94, 114, 126, 120, 135, 140, 152, 156, 180, 161, 167]<br />
[32, 129, 108, 195, 262, 316, 320, 308, 366, 373, 432, 442, 496, 486, 487]<br />
<br />
<br />
;batch 10<br />
[35, 99, 99, 189, 249, 291, 298, 413, 413, 426, 452, 433, 471, 520, 564]<br />
[35, 48, 43, 90, 93, 112, 116, 148, 133, 141, 143, 155, 163, 158, 188]<br />
<br />
<br />
;batch 30<br />
[21, 67, 79, 105, 99, 97, 115, 132, 137, 149, 160, 158, 170, 178, 181]<br />
[13, 170, 200, 227, 272, 254, 336, 316, 406, 423, 442, 415, 464, 496, 521]<br />
<br />
;batch 50<br />
[33, 21, 82, 83, 91, 113, 123, 149, 145, 144, 152, 166, 164, 175, 192]<br />
[58, 42, 187, 247, 271, 306, 331, 365, 397, 413, 468, 502, 495, 507, 540]<br />
<br />
<br />
výpis výsledků, jejich analýza, interpretace, zhodnocení.<br />
<br />
=Discussion=<br />
jak se Vám podařilo definovaný problém vyřešit<br />
<br />
<br />
=Code=<br />
<br />
g<br />
[[User:Tros01|Tros01]] ([[User talk:Tros01|talk]]) 22:19, 19 January 2025 (CET)</div>Tros01http://www.simulace.info/index.php?title=Populating_the_database&diff=26536Populating the database2025-01-19T22:40:44Z<p>Tros01: /* Results */</p>
<hr />
<div>Úvodní odstavec<br />
<br />
=Problem definition=<br />
==Why?==<br />
Lets say that I have a database containing prepared activities and educational content for boy scouts group. Its purpose is to serve as a source of inspiration and eventually of collection of high quality content appropriate for kids during our weekly meetings or other occasions. From which source should be easy to get precisely only the desired results based on defined properties on each activity (eg. time needed for preparation, minimal number of players, etc.)<br />
<br />
BUT actually its currently more like a proof of concept and not a really operational tool. So accordingly there aren't yet any real records to speak about.<br />
This very early stage of development is exactly the reason why I think it is reasonable to think about how will the database be populated with data. As this will be crucial for its future usability and success. Therefore, the simulation should focus on modeling this data population process.<br />
==What?==<br />
To be precise, the simulation will be concerned with user behavior and related volume of stored records.<br />
<br />
It is important to say that user interface for reading is only the default web gui of the database itself (Neo4j), so the users will have to use the Cypher query language. So after they go through such a way to access the records, there better be some decent amount of useful ones in the database. This is because otherwise their whole effort would be pointless and the user would be discouraged from using the database again.<br />
<br />
Creating the records on the other hand will be easy and accessible as much as possible (user writes to google document in specified folder and with specified structure which enables then loading it programmaticaly into the database). This ease of creation is key to encouraging consistent contributions.<br />
<br />
And here comes the question whether this "natural" way of data population is enough, or rather how long will it take for the database to be able to provide satisfactory results for the user in majority of the cases and as such could be called a useful tool. If the time required would be too long, the users could lose interest of even contributing new content .<br />
Therefore, the simulation will model the rate of content creation and the subsequent impact on database searchability and usability.<br />
<br />
Additionally will be also evaluated the "batch population approach" to see weather it is worth considering to implement. This will involve creating a model of user behavior and content creation, simulating different scenarios, and analyzing the results.<br />
==Objectives==<br />
This simulation aims to predict the growth of the database, determine the feasibility of the current data population strategy and evaluate the alternative.<br />
<br />
#Predict the time needed to reach a critical mass of data sufficient for effective use.<br />
#Evaluate the effectiveness of the current data population method relatively to alternative.<br />
<br />
=Method=<br />
==Agent-based model==<br />
The core method used for this simulation is agent-based modeling (ABM). This approach was selected because it aligns well with the nature of the problem, which involves multiple individual users (agents) interacting with a shared environment (the database). Specifically, it enabled me to simulate:<br />
<br />
*Individual User Behaviors: Each agent acts independently, deciding whether to search the database, create a new record, or improve existing ones, based on their local information and probabilities.<br />
*Heterogeneity (Limited): While the agents initially are identical, they change during the simulation based on their interactions with the database.<br />
*Emergent System Behavior: The overall growth and usability of the database is not programmed directly, but emerges from the accumulation of individual actions.<br />
<br />
Alternatively the system dynamics or simple math equations could be used but neither of them would be more fitting for this usecase.<br />
While system dynamics could model the overall growth of the database as a system, it would not provide the same level of detail regarding individual user actions. System dynamics works well when dealing with aggregate levels and rates of change but isn't great for capturing how each agent behaviour individually impacts the system.<br />
<br />
Just as the equations could model a simplified database growth equation, but it would be extremely difficult to derive a model which includes agents success/fail feedback, record improvement and cooldown and thus it was not considered as applicable for this problem.<br />
==Julia==<br />
Because the ABM approach was chosen the NetLogo was concidered as environment for implemantation of the simulation, but also was the language Julia as it is also often used for simulations. In the end the Julia was chosen because of its more general usability and therefore more usecases when learned to use.<br />
<br />
diskuse možností řešení, výběr metody a prostředku (metod a prostředků) řešení, zdůvodnění výběru (jinými slovy, proč to chcete řešit tak, jak to chcete řešit, jaké jsou jiné alternativy a proč je ta Vámi zvolená pro tuto úlohu nejvhodnější)<br />
<br />
=Model=<br />
<br />
==Entities==<br />
;Database (db):<br />
A dictionary storing Record objects, categorized by integers representing different activity categories.<br />
*The keys of the dictionary are integers representing category id.<br />
*Each category is associated with a vector (array) of Record objects.<br />
*Initially, each category has an empty vector, which can be populated by new records.<br />
<br />
;Record:<br />
A struct containing:<br />
*id (Integer): A unique identifier for the record, auto-incrementing with each creation.<br />
*quality (Float64): Represents the perceived quality or usability of the record. <br />
<br />
(Originally it should more closely resamble the real live improvements by being represented by only range 1-10 as the real live records also can not be improved infinitelly, but in the end there was left simplier implemantation that just has a chance to improve the record during every picked to use event by random value withou top limit.)<br />
<br />
;Agent:<br />
A struct representing a user of the database.<br />
*probabilityToSearch (Float64): The agent's current probability of finding a useful record, it is based on past success of the agent when searching the db. This parameter influences agent's decision whether to search the db or not.<br />
*used (Dict{Int, Vector{Int}}): A dictionary that stores which record IDs have been used by agent and in which week the record has been used, so it won't be used by the same agent during a given cooldown period. Keys are record ids and values are vectors containing week integers in which the record has been used.<br />
<br />
==Variables==<br />
;NUM_AGENTS: <br />
: Integer representing the number of agents (users) participating in the simulation. Value is fixed at 3.<br />
;BATCH_UPLOAD_SIZES:<br />
: Vector of integers representing different sizes of initial record batches uploaded to the database. The values used in simulation are [0, 10].<br />
;initialQualityDist: <br />
: A lognormal distribution (LogNormal(3, 2)) used to generate the initial quality of new records. The mean is set to 3, and the standard deviation is set to 2, meaning the typical quality of created record will be around 3, but there could be some with higher or lower.<br />
;qualityImprovementProb<br />
: Float64 representing the probability that an agent will improve a record's quality after using it. Value is fixed at 0.7 for the sake of simplicity and simulation feasibility.<br />
;recordCreationProb<br />
: Float64 representing the probability that an agent creates a new record when they are preparing an activity and decide not to search the database. Value is fixed at 0.3 for the sake of simplicity and simulation feasibility.<br />
;categories<br />
: Vector of integer representing the category ids of the db records. The vector is generated as range from 1 to 20, [1:20;].<br />
;targetSuccessfulness<br />
: Float64 value, which represents minimum success rate, that needs to be reached for the database to be considered "useful" in a long term. Value is 0.75.<br />
;nSuccessfullFromEpisode<br />
: An integer number representing how many successful searches per episode of the simulation have to occur in order for it to be considered "useful". Value is 4.<br />
;episodeLength<br />
: Integer which represents length of a one "episode" within the simulation, which in this case is a sequence of weeks for which the success rate of the db will be tested if it met required conditions. Value is set to 6, this means 6 weeks.<br />
<br />
==Flow==<br />
'''1.Initialization:'''<br />
<br />
*The database is created with empty vectors of records for each defined category (integer from 1 to 20).<br />
*A defined number of agents are created with default probabilityToSearch.<br />
*Optionally, a number of initial Record objects will be created (based on parameter BATCH_UPLOAD_SIZE), and randomly assigned to a random category within the database.<br />
<br />
'''2.Weekly Cycle (One Tick):'''<br />
<br />
*Each week (tick), each agent attempts to prepare an activity.<br />
*Each agent selects a random category.<br />
*Then each agent decides whether to search the database based on their current probabilityToSearch (It was originally designed to be able to dynamicaly calculate probabilityToSearch of agents independently, but for the same reason the recordCreationProb is global to all agents, also this variable was left the same for all agents).<br />
<br />
;Search Behavior:<br />
<br />
*If the agent decides to search, it looks up all records that matches it selected category.<br />
*If records are found, the agents samples without replacement a predefined number of records for evaluation. Each has different probability based on its quality. The more quality it has, the higher the probability to be chosen. (Weights are calculated like this [rec.quality / sum(r.quality for r in records) for rec in records])<br />
*An agent tries to pick for use randomly one record from those records. <br />
*Before the agent uses any of the found records, there has to be checked if they haven't been used in a defined "cooldown period", which is set to 54 weeks. Each agent keeps track of used records and the weeks where they where used.<br />
*If the record the agent tries to pick is on cooldown, the agent proceeds to trying another one from the sampled ones until it finds a cooled down one or until there are no more samples (usually in the beginning of the simulation when there are yot not created record in the db).<br />
*If the record is used, there is a probability of the agent improving the quality of that used record.<br />
<br />
;Record Creation Behavior:<br />
<br />
*If the agent decides not to search or if the search is unsuccessful, it has a chance of creating a new record (based on parameter recordCreationProb).<br />
*If a new record is created, it's assigned a randomly generated initial quality based on the lognormal distribution, and pushed to db under it's selected category.<br />
*Also there is kept record of total number oc record created so far during the simulation and the order number of each record is assigned to the record during its creation as its id. This way its possible to keep track of which records were used before by the given agent.<br />
<br />
'''3.Evaluation'''<br />
*Further the simulation tracks total search attempts and successes. The success is considered only when a record is successfully used for an activity and not when a record is found or searched for.<br />
*At the end of each week, a weekly success rate is calculated by dividing the amount of successful record usages by the number of attempts that were performed.<br />
*The simulation continues until the database has reached "sufficient" usability.<br />
*A database is considered as "sufficiently useful" when success rates in a defined episode length (6 weeks) are over a defined threshold (75%) for a given minimum number of successful weeks (4 out of 6). In other words, when this condition is met within a 3 month timeframe.<br />
<br />
<br />
Detailní popis modelu, včetně parametrů, oborů hodnot, schémat, omezení modelu, apod. Popis musí být natolik detailní, aby podle něj bylo možné experiment zopakovat (a to samozřejmě i bez toho, že by byly k dispozici příslušné soubory s modelem).<br />
<br />
=Results=<br />
In the last section of appended code there was realized an attempt to calculate the results simply by adding new function which whould call the main simulation given number of times and recorded the results so the variability caused by randomness could be viewed. Specifically how the required number of weeks and number of created records varied when running the simulation repeatedly.<br />
<br />
Unfortunately there has been some enexpected and probably undesired patterns occuring in the obtained "multi run" results. Most likely a skillissue on my side. Further elaboration follows.<br />
<br />
Also there is a bug/feature with my function which determines when the search process is successfull enough. Because i require certain amount of time to assess the stability of said successfullness, there is a minimal but fixed timeframe in the begining of the simulation. And because of this when the number of weeks required for the system to be recognized as usefull is measured, its value can not begin earlier than after said timeframe, so that is why the smallest number of weeks in the results are 21.<br />
==Single run==<br />
This means runing the multi run function for single iteration.<br />
<br />
But it was run manually three times.<br />
;batch 0 <br />
:weeks until "usefullness": 82, 51,<br />
:records created in db: 44, 40, <br />
<br />
;batch 10<br />
weeks: 21, 33, <br />
records: 21, 26, <br />
<br />
;batch 30<br />
weeks: 24, 21, <br />
records: 26, 17, <br />
<br />
;batch 50<br />
weeks: 21, 21, <br />
records: 30, 18, <br />
<br />
==Multi run==<br />
===batch 0===<br />
<br />
===batch 10===<br />
<br />
===batch 30===<br />
<br />
===batch 50===<br />
<br />
výpis výsledků, jejich analýza, interpretace, zhodnocení.<br />
<br />
=Discussion=<br />
jak se Vám podařilo definovaný problém vyřešit<br />
<br />
<br />
=Code=<br />
<br />
g<br />
[[User:Tros01|Tros01]] ([[User talk:Tros01|talk]]) 22:19, 19 January 2025 (CET)</div>Tros01http://www.simulace.info/index.php?title=Populating_the_database&diff=26535Populating the database2025-01-19T22:36:44Z<p>Tros01: /* Results */</p>
<hr />
<div>Úvodní odstavec<br />
<br />
=Problem definition=<br />
==Why?==<br />
Lets say that I have a database containing prepared activities and educational content for boy scouts group. Its purpose is to serve as a source of inspiration and eventually of collection of high quality content appropriate for kids during our weekly meetings or other occasions. From which source should be easy to get precisely only the desired results based on defined properties on each activity (eg. time needed for preparation, minimal number of players, etc.)<br />
<br />
BUT actually its currently more like a proof of concept and not a really operational tool. So accordingly there aren't yet any real records to speak about.<br />
This very early stage of development is exactly the reason why I think it is reasonable to think about how will the database be populated with data. As this will be crucial for its future usability and success. Therefore, the simulation should focus on modeling this data population process.<br />
==What?==<br />
To be precise, the simulation will be concerned with user behavior and related volume of stored records.<br />
<br />
It is important to say that user interface for reading is only the default web gui of the database itself (Neo4j), so the users will have to use the Cypher query language. So after they go through such a way to access the records, there better be some decent amount of useful ones in the database. This is because otherwise their whole effort would be pointless and the user would be discouraged from using the database again.<br />
<br />
Creating the records on the other hand will be easy and accessible as much as possible (user writes to google document in specified folder and with specified structure which enables then loading it programmaticaly into the database). This ease of creation is key to encouraging consistent contributions.<br />
<br />
And here comes the question whether this "natural" way of data population is enough, or rather how long will it take for the database to be able to provide satisfactory results for the user in majority of the cases and as such could be called a useful tool. If the time required would be too long, the users could lose interest of even contributing new content .<br />
Therefore, the simulation will model the rate of content creation and the subsequent impact on database searchability and usability.<br />
<br />
Additionally will be also evaluated the "batch population approach" to see weather it is worth considering to implement. This will involve creating a model of user behavior and content creation, simulating different scenarios, and analyzing the results.<br />
==Objectives==<br />
This simulation aims to predict the growth of the database, determine the feasibility of the current data population strategy and evaluate the alternative.<br />
<br />
#Predict the time needed to reach a critical mass of data sufficient for effective use.<br />
#Evaluate the effectiveness of the current data population method relatively to alternative.<br />
<br />
=Method=<br />
==Agent-based model==<br />
The core method used for this simulation is agent-based modeling (ABM). This approach was selected because it aligns well with the nature of the problem, which involves multiple individual users (agents) interacting with a shared environment (the database). Specifically, it enabled me to simulate:<br />
<br />
*Individual User Behaviors: Each agent acts independently, deciding whether to search the database, create a new record, or improve existing ones, based on their local information and probabilities.<br />
*Heterogeneity (Limited): While the agents initially are identical, they change during the simulation based on their interactions with the database.<br />
*Emergent System Behavior: The overall growth and usability of the database is not programmed directly, but emerges from the accumulation of individual actions.<br />
<br />
Alternatively the system dynamics or simple math equations could be used but neither of them would be more fitting for this usecase.<br />
While system dynamics could model the overall growth of the database as a system, it would not provide the same level of detail regarding individual user actions. System dynamics works well when dealing with aggregate levels and rates of change but isn't great for capturing how each agent behaviour individually impacts the system.<br />
<br />
Just as the equations could model a simplified database growth equation, but it would be extremely difficult to derive a model which includes agents success/fail feedback, record improvement and cooldown and thus it was not considered as applicable for this problem.<br />
==Julia==<br />
Because the ABM approach was chosen the NetLogo was concidered as environment for implemantation of the simulation, but also was the language Julia as it is also often used for simulations. In the end the Julia was chosen because of its more general usability and therefore more usecases when learned to use.<br />
<br />
diskuse možností řešení, výběr metody a prostředku (metod a prostředků) řešení, zdůvodnění výběru (jinými slovy, proč to chcete řešit tak, jak to chcete řešit, jaké jsou jiné alternativy a proč je ta Vámi zvolená pro tuto úlohu nejvhodnější)<br />
<br />
=Model=<br />
<br />
==Entities==<br />
;Database (db):<br />
A dictionary storing Record objects, categorized by integers representing different activity categories.<br />
*The keys of the dictionary are integers representing category id.<br />
*Each category is associated with a vector (array) of Record objects.<br />
*Initially, each category has an empty vector, which can be populated by new records.<br />
<br />
;Record:<br />
A struct containing:<br />
*id (Integer): A unique identifier for the record, auto-incrementing with each creation.<br />
*quality (Float64): Represents the perceived quality or usability of the record. <br />
<br />
(Originally it should more closely resamble the real live improvements by being represented by only range 1-10 as the real live records also can not be improved infinitelly, but in the end there was left simplier implemantation that just has a chance to improve the record during every picked to use event by random value withou top limit.)<br />
<br />
;Agent:<br />
A struct representing a user of the database.<br />
*probabilityToSearch (Float64): The agent's current probability of finding a useful record, it is based on past success of the agent when searching the db. This parameter influences agent's decision whether to search the db or not.<br />
*used (Dict{Int, Vector{Int}}): A dictionary that stores which record IDs have been used by agent and in which week the record has been used, so it won't be used by the same agent during a given cooldown period. Keys are record ids and values are vectors containing week integers in which the record has been used.<br />
<br />
==Variables==<br />
;NUM_AGENTS: <br />
: Integer representing the number of agents (users) participating in the simulation. Value is fixed at 3.<br />
;BATCH_UPLOAD_SIZES:<br />
: Vector of integers representing different sizes of initial record batches uploaded to the database. The values used in simulation are [0, 10].<br />
;initialQualityDist: <br />
: A lognormal distribution (LogNormal(3, 2)) used to generate the initial quality of new records. The mean is set to 3, and the standard deviation is set to 2, meaning the typical quality of created record will be around 3, but there could be some with higher or lower.<br />
;qualityImprovementProb<br />
: Float64 representing the probability that an agent will improve a record's quality after using it. Value is fixed at 0.7 for the sake of simplicity and simulation feasibility.<br />
;recordCreationProb<br />
: Float64 representing the probability that an agent creates a new record when they are preparing an activity and decide not to search the database. Value is fixed at 0.3 for the sake of simplicity and simulation feasibility.<br />
;categories<br />
: Vector of integer representing the category ids of the db records. The vector is generated as range from 1 to 20, [1:20;].<br />
;targetSuccessfulness<br />
: Float64 value, which represents minimum success rate, that needs to be reached for the database to be considered "useful" in a long term. Value is 0.75.<br />
;nSuccessfullFromEpisode<br />
: An integer number representing how many successful searches per episode of the simulation have to occur in order for it to be considered "useful". Value is 4.<br />
;episodeLength<br />
: Integer which represents length of a one "episode" within the simulation, which in this case is a sequence of weeks for which the success rate of the db will be tested if it met required conditions. Value is set to 6, this means 6 weeks.<br />
<br />
==Flow==<br />
'''1.Initialization:'''<br />
<br />
*The database is created with empty vectors of records for each defined category (integer from 1 to 20).<br />
*A defined number of agents are created with default probabilityToSearch.<br />
*Optionally, a number of initial Record objects will be created (based on parameter BATCH_UPLOAD_SIZE), and randomly assigned to a random category within the database.<br />
<br />
'''2.Weekly Cycle (One Tick):'''<br />
<br />
*Each week (tick), each agent attempts to prepare an activity.<br />
*Each agent selects a random category.<br />
*Then each agent decides whether to search the database based on their current probabilityToSearch (It was originally designed to be able to dynamicaly calculate probabilityToSearch of agents independently, but for the same reason the recordCreationProb is global to all agents, also this variable was left the same for all agents).<br />
<br />
;Search Behavior:<br />
<br />
*If the agent decides to search, it looks up all records that matches it selected category.<br />
*If records are found, the agents samples without replacement a predefined number of records for evaluation. Each has different probability based on its quality. The more quality it has, the higher the probability to be chosen. (Weights are calculated like this [rec.quality / sum(r.quality for r in records) for rec in records])<br />
*An agent tries to pick for use randomly one record from those records. <br />
*Before the agent uses any of the found records, there has to be checked if they haven't been used in a defined "cooldown period", which is set to 54 weeks. Each agent keeps track of used records and the weeks where they where used.<br />
*If the record the agent tries to pick is on cooldown, the agent proceeds to trying another one from the sampled ones until it finds a cooled down one or until there are no more samples (usually in the beginning of the simulation when there are yot not created record in the db).<br />
*If the record is used, there is a probability of the agent improving the quality of that used record.<br />
<br />
;Record Creation Behavior:<br />
<br />
*If the agent decides not to search or if the search is unsuccessful, it has a chance of creating a new record (based on parameter recordCreationProb).<br />
*If a new record is created, it's assigned a randomly generated initial quality based on the lognormal distribution, and pushed to db under it's selected category.<br />
*Also there is kept record of total number oc record created so far during the simulation and the order number of each record is assigned to the record during its creation as its id. This way its possible to keep track of which records were used before by the given agent.<br />
<br />
'''3.Evaluation'''<br />
*Further the simulation tracks total search attempts and successes. The success is considered only when a record is successfully used for an activity and not when a record is found or searched for.<br />
*At the end of each week, a weekly success rate is calculated by dividing the amount of successful record usages by the number of attempts that were performed.<br />
*The simulation continues until the database has reached "sufficient" usability.<br />
*A database is considered as "sufficiently useful" when success rates in a defined episode length (6 weeks) are over a defined threshold (75%) for a given minimum number of successful weeks (4 out of 6). In other words, when this condition is met within a 3 month timeframe.<br />
<br />
<br />
Detailní popis modelu, včetně parametrů, oborů hodnot, schémat, omezení modelu, apod. Popis musí být natolik detailní, aby podle něj bylo možné experiment zopakovat (a to samozřejmě i bez toho, že by byly k dispozici příslušné soubory s modelem).<br />
<br />
=Results=<br />
In the last section of appended code there was realized an attempt to calculate the results simply by adding new function which whould call the main simulation given number of times and recorded the results so the variability caused by randomness could be viewed. Specifically how the required number of weeks and number of created records varied when running the simulation repeatedly.<br />
<br />
Unfortunately there has been some enexpected and probably undesired patterns occuring in the obtained "multi run" results. Most likely a skillissue on my side. Further elaboration follows.<br />
<br />
Also there is a bug/feature with my function which determines when the search process is successfull enough. Because i require certain amount of time to assess the stability of said successfullness, there is a minimal but fixed timeframe in the begining of the simulation. And because of this when the number of weeks required for the system to be recognized as usefull is measured, its value can not begin earlier than after said timeframe, so that is why the smallest number of weeks in the results are 21.<br />
==Single run==<br />
This means runing the multi run function for single iteration.<br />
<br />
But it was run manually three times.<br />
;batch 0 <br />
:weeks until "usefullness": 82,<br />
:records created in db: 44,<br />
<br />
;batch 10<br />
weeks: 21<br />
records: 21<br />
<br />
;batch 30<br />
weeks:<br />
<br />
;batch 50<br />
<br />
==Multi run==<br />
===batch 0===<br />
<br />
===batch 10===<br />
<br />
===batch 30===<br />
<br />
===batch 50===<br />
<br />
výpis výsledků, jejich analýza, interpretace, zhodnocení.<br />
<br />
=Discussion=<br />
jak se Vám podařilo definovaný problém vyřešit<br />
<br />
<br />
=Code=<br />
<br />
g<br />
[[User:Tros01|Tros01]] ([[User talk:Tros01|talk]]) 22:19, 19 January 2025 (CET)</div>Tros01http://www.simulace.info/index.php?title=Populating_the_database&diff=26534Populating the database2025-01-19T22:30:51Z<p>Tros01: /* Single run */</p>
<hr />
<div>Úvodní odstavec<br />
<br />
=Problem definition=<br />
==Why?==<br />
Lets say that I have a database containing prepared activities and educational content for boy scouts group. Its purpose is to serve as a source of inspiration and eventually of collection of high quality content appropriate for kids during our weekly meetings or other occasions. From which source should be easy to get precisely only the desired results based on defined properties on each activity (eg. time needed for preparation, minimal number of players, etc.)<br />
<br />
BUT actually its currently more like a proof of concept and not a really operational tool. So accordingly there aren't yet any real records to speak about.<br />
This very early stage of development is exactly the reason why I think it is reasonable to think about how will the database be populated with data. As this will be crucial for its future usability and success. Therefore, the simulation should focus on modeling this data population process.<br />
==What?==<br />
To be precise, the simulation will be concerned with user behavior and related volume of stored records.<br />
<br />
It is important to say that user interface for reading is only the default web gui of the database itself (Neo4j), so the users will have to use the Cypher query language. So after they go through such a way to access the records, there better be some decent amount of useful ones in the database. This is because otherwise their whole effort would be pointless and the user would be discouraged from using the database again.<br />
<br />
Creating the records on the other hand will be easy and accessible as much as possible (user writes to google document in specified folder and with specified structure which enables then loading it programmaticaly into the database). This ease of creation is key to encouraging consistent contributions.<br />
<br />
And here comes the question whether this "natural" way of data population is enough, or rather how long will it take for the database to be able to provide satisfactory results for the user in majority of the cases and as such could be called a useful tool. If the time required would be too long, the users could lose interest of even contributing new content .<br />
Therefore, the simulation will model the rate of content creation and the subsequent impact on database searchability and usability.<br />
<br />
Additionally will be also evaluated the "batch population approach" to see weather it is worth considering to implement. This will involve creating a model of user behavior and content creation, simulating different scenarios, and analyzing the results.<br />
==Objectives==<br />
This simulation aims to predict the growth of the database, determine the feasibility of the current data population strategy and evaluate the alternative.<br />
<br />
#Predict the time needed to reach a critical mass of data sufficient for effective use.<br />
#Evaluate the effectiveness of the current data population method relatively to alternative.<br />
<br />
=Method=<br />
==Agent-based model==<br />
The core method used for this simulation is agent-based modeling (ABM). This approach was selected because it aligns well with the nature of the problem, which involves multiple individual users (agents) interacting with a shared environment (the database). Specifically, it enabled me to simulate:<br />
<br />
*Individual User Behaviors: Each agent acts independently, deciding whether to search the database, create a new record, or improve existing ones, based on their local information and probabilities.<br />
*Heterogeneity (Limited): While the agents initially are identical, they change during the simulation based on their interactions with the database.<br />
*Emergent System Behavior: The overall growth and usability of the database is not programmed directly, but emerges from the accumulation of individual actions.<br />
<br />
Alternatively the system dynamics or simple math equations could be used but neither of them would be more fitting for this usecase.<br />
While system dynamics could model the overall growth of the database as a system, it would not provide the same level of detail regarding individual user actions. System dynamics works well when dealing with aggregate levels and rates of change but isn't great for capturing how each agent behaviour individually impacts the system.<br />
<br />
Just as the equations could model a simplified database growth equation, but it would be extremely difficult to derive a model which includes agents success/fail feedback, record improvement and cooldown and thus it was not considered as applicable for this problem.<br />
==Julia==<br />
Because the ABM approach was chosen the NetLogo was concidered as environment for implemantation of the simulation, but also was the language Julia as it is also often used for simulations. In the end the Julia was chosen because of its more general usability and therefore more usecases when learned to use.<br />
<br />
diskuse možností řešení, výběr metody a prostředku (metod a prostředků) řešení, zdůvodnění výběru (jinými slovy, proč to chcete řešit tak, jak to chcete řešit, jaké jsou jiné alternativy a proč je ta Vámi zvolená pro tuto úlohu nejvhodnější)<br />
<br />
=Model=<br />
<br />
==Entities==<br />
;Database (db):<br />
A dictionary storing Record objects, categorized by integers representing different activity categories.<br />
*The keys of the dictionary are integers representing category id.<br />
*Each category is associated with a vector (array) of Record objects.<br />
*Initially, each category has an empty vector, which can be populated by new records.<br />
<br />
;Record:<br />
A struct containing:<br />
*id (Integer): A unique identifier for the record, auto-incrementing with each creation.<br />
*quality (Float64): Represents the perceived quality or usability of the record. <br />
<br />
(Originally it should more closely resamble the real live improvements by being represented by only range 1-10 as the real live records also can not be improved infinitelly, but in the end there was left simplier implemantation that just has a chance to improve the record during every picked to use event by random value withou top limit.)<br />
<br />
;Agent:<br />
A struct representing a user of the database.<br />
*probabilityToSearch (Float64): The agent's current probability of finding a useful record, it is based on past success of the agent when searching the db. This parameter influences agent's decision whether to search the db or not.<br />
*used (Dict{Int, Vector{Int}}): A dictionary that stores which record IDs have been used by agent and in which week the record has been used, so it won't be used by the same agent during a given cooldown period. Keys are record ids and values are vectors containing week integers in which the record has been used.<br />
<br />
==Variables==<br />
;NUM_AGENTS: <br />
: Integer representing the number of agents (users) participating in the simulation. Value is fixed at 3.<br />
;BATCH_UPLOAD_SIZES:<br />
: Vector of integers representing different sizes of initial record batches uploaded to the database. The values used in simulation are [0, 10].<br />
;initialQualityDist: <br />
: A lognormal distribution (LogNormal(3, 2)) used to generate the initial quality of new records. The mean is set to 3, and the standard deviation is set to 2, meaning the typical quality of created record will be around 3, but there could be some with higher or lower.<br />
;qualityImprovementProb<br />
: Float64 representing the probability that an agent will improve a record's quality after using it. Value is fixed at 0.7 for the sake of simplicity and simulation feasibility.<br />
;recordCreationProb<br />
: Float64 representing the probability that an agent creates a new record when they are preparing an activity and decide not to search the database. Value is fixed at 0.3 for the sake of simplicity and simulation feasibility.<br />
;categories<br />
: Vector of integer representing the category ids of the db records. The vector is generated as range from 1 to 20, [1:20;].<br />
;targetSuccessfulness<br />
: Float64 value, which represents minimum success rate, that needs to be reached for the database to be considered "useful" in a long term. Value is 0.75.<br />
;nSuccessfullFromEpisode<br />
: An integer number representing how many successful searches per episode of the simulation have to occur in order for it to be considered "useful". Value is 4.<br />
;episodeLength<br />
: Integer which represents length of a one "episode" within the simulation, which in this case is a sequence of weeks for which the success rate of the db will be tested if it met required conditions. Value is set to 6, this means 6 weeks.<br />
<br />
==Flow==<br />
'''1.Initialization:'''<br />
<br />
*The database is created with empty vectors of records for each defined category (integer from 1 to 20).<br />
*A defined number of agents are created with default probabilityToSearch.<br />
*Optionally, a number of initial Record objects will be created (based on parameter BATCH_UPLOAD_SIZE), and randomly assigned to a random category within the database.<br />
<br />
'''2.Weekly Cycle (One Tick):'''<br />
<br />
*Each week (tick), each agent attempts to prepare an activity.<br />
*Each agent selects a random category.<br />
*Then each agent decides whether to search the database based on their current probabilityToSearch (It was originally designed to be able to dynamicaly calculate probabilityToSearch of agents independently, but for the same reason the recordCreationProb is global to all agents, also this variable was left the same for all agents).<br />
<br />
;Search Behavior:<br />
<br />
*If the agent decides to search, it looks up all records that matches it selected category.<br />
*If records are found, the agents samples without replacement a predefined number of records for evaluation. Each has different probability based on its quality. The more quality it has, the higher the probability to be chosen. (Weights are calculated like this [rec.quality / sum(r.quality for r in records) for rec in records])<br />
*An agent tries to pick for use randomly one record from those records. <br />
*Before the agent uses any of the found records, there has to be checked if they haven't been used in a defined "cooldown period", which is set to 54 weeks. Each agent keeps track of used records and the weeks where they where used.<br />
*If the record the agent tries to pick is on cooldown, the agent proceeds to trying another one from the sampled ones until it finds a cooled down one or until there are no more samples (usually in the beginning of the simulation when there are yot not created record in the db).<br />
*If the record is used, there is a probability of the agent improving the quality of that used record.<br />
<br />
;Record Creation Behavior:<br />
<br />
*If the agent decides not to search or if the search is unsuccessful, it has a chance of creating a new record (based on parameter recordCreationProb).<br />
*If a new record is created, it's assigned a randomly generated initial quality based on the lognormal distribution, and pushed to db under it's selected category.<br />
*Also there is kept record of total number oc record created so far during the simulation and the order number of each record is assigned to the record during its creation as its id. This way its possible to keep track of which records were used before by the given agent.<br />
<br />
'''3.Evaluation'''<br />
*Further the simulation tracks total search attempts and successes. The success is considered only when a record is successfully used for an activity and not when a record is found or searched for.<br />
*At the end of each week, a weekly success rate is calculated by dividing the amount of successful record usages by the number of attempts that were performed.<br />
*The simulation continues until the database has reached "sufficient" usability.<br />
*A database is considered as "sufficiently useful" when success rates in a defined episode length (6 weeks) are over a defined threshold (75%) for a given minimum number of successful weeks (4 out of 6). In other words, when this condition is met within a 3 month timeframe.<br />
<br />
<br />
Detailní popis modelu, včetně parametrů, oborů hodnot, schémat, omezení modelu, apod. Popis musí být natolik detailní, aby podle něj bylo možné experiment zopakovat (a to samozřejmě i bez toho, že by byly k dispozici příslušné soubory s modelem).<br />
<br />
=Results=<br />
In the last section of appended code there was realized an attempt to calculate the results simply by adding new function which whould call the main simulation given number of times and recorded the results so the variability caused by randomness could be viewed. Specifically how the required number of weeks and number of created records varied when running the simulation repeatedly.<br />
<br />
Unfortunately there has been some enexpected and probably undesired patterns occuring in the obtained "multi run" results. Most likely a skillissue on my side. Further elaboration follows.<br />
==Single run==<br />
This means runing the multi run function for single iteration.<br />
<br />
But it was run manually three times.<br />
;batch 0 <br />
:weeks until "usefullness": 82,<br />
:records created in db: 44,<br />
<br />
;batch 10<br />
weeks: 21<br />
records: 21<br />
<br />
;batch 30<br />
weeks:<br />
<br />
;batch 50<br />
<br />
==Multi run==<br />
===batch 0===<br />
<br />
===batch 10===<br />
<br />
===batch 30===<br />
<br />
===batch 50===<br />
<br />
výpis výsledků, jejich analýza, interpretace, zhodnocení.<br />
<br />
=Discussion=<br />
jak se Vám podařilo definovaný problém vyřešit<br />
<br />
<br />
=Code=<br />
<br />
g<br />
[[User:Tros01|Tros01]] ([[User talk:Tros01|talk]]) 22:19, 19 January 2025 (CET)</div>Tros01http://www.simulace.info/index.php?title=Populating_the_database&diff=26533Populating the database2025-01-19T22:25:06Z<p>Tros01: /* Entities */</p>
<hr />
<div>Úvodní odstavec<br />
<br />
=Problem definition=<br />
==Why?==<br />
Lets say that I have a database containing prepared activities and educational content for boy scouts group. Its purpose is to serve as a source of inspiration and eventually of collection of high quality content appropriate for kids during our weekly meetings or other occasions. From which source should be easy to get precisely only the desired results based on defined properties on each activity (eg. time needed for preparation, minimal number of players, etc.)<br />
<br />
BUT actually its currently more like a proof of concept and not a really operational tool. So accordingly there aren't yet any real records to speak about.<br />
This very early stage of development is exactly the reason why I think it is reasonable to think about how will the database be populated with data. As this will be crucial for its future usability and success. Therefore, the simulation should focus on modeling this data population process.<br />
==What?==<br />
To be precise, the simulation will be concerned with user behavior and related volume of stored records.<br />
<br />
It is important to say that user interface for reading is only the default web gui of the database itself (Neo4j), so the users will have to use the Cypher query language. So after they go through such a way to access the records, there better be some decent amount of useful ones in the database. This is because otherwise their whole effort would be pointless and the user would be discouraged from using the database again.<br />
<br />
Creating the records on the other hand will be easy and accessible as much as possible (user writes to google document in specified folder and with specified structure which enables then loading it programmaticaly into the database). This ease of creation is key to encouraging consistent contributions.<br />
<br />
And here comes the question whether this "natural" way of data population is enough, or rather how long will it take for the database to be able to provide satisfactory results for the user in majority of the cases and as such could be called a useful tool. If the time required would be too long, the users could lose interest of even contributing new content .<br />
Therefore, the simulation will model the rate of content creation and the subsequent impact on database searchability and usability.<br />
<br />
Additionally will be also evaluated the "batch population approach" to see weather it is worth considering to implement. This will involve creating a model of user behavior and content creation, simulating different scenarios, and analyzing the results.<br />
==Objectives==<br />
This simulation aims to predict the growth of the database, determine the feasibility of the current data population strategy and evaluate the alternative.<br />
<br />
#Predict the time needed to reach a critical mass of data sufficient for effective use.<br />
#Evaluate the effectiveness of the current data population method relatively to alternative.<br />
<br />
=Method=<br />
==Agent-based model==<br />
The core method used for this simulation is agent-based modeling (ABM). This approach was selected because it aligns well with the nature of the problem, which involves multiple individual users (agents) interacting with a shared environment (the database). Specifically, it enabled me to simulate:<br />
<br />
*Individual User Behaviors: Each agent acts independently, deciding whether to search the database, create a new record, or improve existing ones, based on their local information and probabilities.<br />
*Heterogeneity (Limited): While the agents initially are identical, they change during the simulation based on their interactions with the database.<br />
*Emergent System Behavior: The overall growth and usability of the database is not programmed directly, but emerges from the accumulation of individual actions.<br />
<br />
Alternatively the system dynamics or simple math equations could be used but neither of them would be more fitting for this usecase.<br />
While system dynamics could model the overall growth of the database as a system, it would not provide the same level of detail regarding individual user actions. System dynamics works well when dealing with aggregate levels and rates of change but isn't great for capturing how each agent behaviour individually impacts the system.<br />
<br />
Just as the equations could model a simplified database growth equation, but it would be extremely difficult to derive a model which includes agents success/fail feedback, record improvement and cooldown and thus it was not considered as applicable for this problem.<br />
==Julia==<br />
Because the ABM approach was chosen the NetLogo was concidered as environment for implemantation of the simulation, but also was the language Julia as it is also often used for simulations. In the end the Julia was chosen because of its more general usability and therefore more usecases when learned to use.<br />
<br />
diskuse možností řešení, výběr metody a prostředku (metod a prostředků) řešení, zdůvodnění výběru (jinými slovy, proč to chcete řešit tak, jak to chcete řešit, jaké jsou jiné alternativy a proč je ta Vámi zvolená pro tuto úlohu nejvhodnější)<br />
<br />
=Model=<br />
<br />
==Entities==<br />
;Database (db):<br />
A dictionary storing Record objects, categorized by integers representing different activity categories.<br />
*The keys of the dictionary are integers representing category id.<br />
*Each category is associated with a vector (array) of Record objects.<br />
*Initially, each category has an empty vector, which can be populated by new records.<br />
<br />
;Record:<br />
A struct containing:<br />
*id (Integer): A unique identifier for the record, auto-incrementing with each creation.<br />
*quality (Float64): Represents the perceived quality or usability of the record. <br />
<br />
(Originally it should more closely resamble the real live improvements by being represented by only range 1-10 as the real live records also can not be improved infinitelly, but in the end there was left simplier implemantation that just has a chance to improve the record during every picked to use event by random value withou top limit.)<br />
<br />
;Agent:<br />
A struct representing a user of the database.<br />
*probabilityToSearch (Float64): The agent's current probability of finding a useful record, it is based on past success of the agent when searching the db. This parameter influences agent's decision whether to search the db or not.<br />
*used (Dict{Int, Vector{Int}}): A dictionary that stores which record IDs have been used by agent and in which week the record has been used, so it won't be used by the same agent during a given cooldown period. Keys are record ids and values are vectors containing week integers in which the record has been used.<br />
<br />
==Variables==<br />
;NUM_AGENTS: <br />
: Integer representing the number of agents (users) participating in the simulation. Value is fixed at 3.<br />
;BATCH_UPLOAD_SIZES:<br />
: Vector of integers representing different sizes of initial record batches uploaded to the database. The values used in simulation are [0, 10].<br />
;initialQualityDist: <br />
: A lognormal distribution (LogNormal(3, 2)) used to generate the initial quality of new records. The mean is set to 3, and the standard deviation is set to 2, meaning the typical quality of created record will be around 3, but there could be some with higher or lower.<br />
;qualityImprovementProb<br />
: Float64 representing the probability that an agent will improve a record's quality after using it. Value is fixed at 0.7 for the sake of simplicity and simulation feasibility.<br />
;recordCreationProb<br />
: Float64 representing the probability that an agent creates a new record when they are preparing an activity and decide not to search the database. Value is fixed at 0.3 for the sake of simplicity and simulation feasibility.<br />
;categories<br />
: Vector of integer representing the category ids of the db records. The vector is generated as range from 1 to 20, [1:20;].<br />
;targetSuccessfulness<br />
: Float64 value, which represents minimum success rate, that needs to be reached for the database to be considered "useful" in a long term. Value is 0.75.<br />
;nSuccessfullFromEpisode<br />
: An integer number representing how many successful searches per episode of the simulation have to occur in order for it to be considered "useful". Value is 4.<br />
;episodeLength<br />
: Integer which represents length of a one "episode" within the simulation, which in this case is a sequence of weeks for which the success rate of the db will be tested if it met required conditions. Value is set to 6, this means 6 weeks.<br />
<br />
==Flow==<br />
'''1.Initialization:'''<br />
<br />
*The database is created with empty vectors of records for each defined category (integer from 1 to 20).<br />
*A defined number of agents are created with default probabilityToSearch.<br />
*Optionally, a number of initial Record objects will be created (based on parameter BATCH_UPLOAD_SIZE), and randomly assigned to a random category within the database.<br />
<br />
'''2.Weekly Cycle (One Tick):'''<br />
<br />
*Each week (tick), each agent attempts to prepare an activity.<br />
*Each agent selects a random category.<br />
*Then each agent decides whether to search the database based on their current probabilityToSearch (It was originally designed to be able to dynamicaly calculate probabilityToSearch of agents independently, but for the same reason the recordCreationProb is global to all agents, also this variable was left the same for all agents).<br />
<br />
;Search Behavior:<br />
<br />
*If the agent decides to search, it looks up all records that matches it selected category.<br />
*If records are found, the agents samples without replacement a predefined number of records for evaluation. Each has different probability based on its quality. The more quality it has, the higher the probability to be chosen. (Weights are calculated like this [rec.quality / sum(r.quality for r in records) for rec in records])<br />
*An agent tries to pick for use randomly one record from those records. <br />
*Before the agent uses any of the found records, there has to be checked if they haven't been used in a defined "cooldown period", which is set to 54 weeks. Each agent keeps track of used records and the weeks where they where used.<br />
*If the record the agent tries to pick is on cooldown, the agent proceeds to trying another one from the sampled ones until it finds a cooled down one or until there are no more samples (usually in the beginning of the simulation when there are yot not created record in the db).<br />
*If the record is used, there is a probability of the agent improving the quality of that used record.<br />
<br />
;Record Creation Behavior:<br />
<br />
*If the agent decides not to search or if the search is unsuccessful, it has a chance of creating a new record (based on parameter recordCreationProb).<br />
*If a new record is created, it's assigned a randomly generated initial quality based on the lognormal distribution, and pushed to db under it's selected category.<br />
*Also there is kept record of total number oc record created so far during the simulation and the order number of each record is assigned to the record during its creation as its id. This way its possible to keep track of which records were used before by the given agent.<br />
<br />
'''3.Evaluation'''<br />
*Further the simulation tracks total search attempts and successes. The success is considered only when a record is successfully used for an activity and not when a record is found or searched for.<br />
*At the end of each week, a weekly success rate is calculated by dividing the amount of successful record usages by the number of attempts that were performed.<br />
*The simulation continues until the database has reached "sufficient" usability.<br />
*A database is considered as "sufficiently useful" when success rates in a defined episode length (6 weeks) are over a defined threshold (75%) for a given minimum number of successful weeks (4 out of 6). In other words, when this condition is met within a 3 month timeframe.<br />
<br />
<br />
Detailní popis modelu, včetně parametrů, oborů hodnot, schémat, omezení modelu, apod. Popis musí být natolik detailní, aby podle něj bylo možné experiment zopakovat (a to samozřejmě i bez toho, že by byly k dispozici příslušné soubory s modelem).<br />
<br />
=Results=<br />
In the last section of appended code there was realized an attempt to calculate the results simply by adding new function which whould call the main simulation given number of times and recorded the results so the variability caused by randomness could be viewed. Specifically how the required number of weeks and number of created records varied when running the simulation repeatedly.<br />
<br />
Unfortunately there has been some enexpected and probably undesired patterns occuring in the obtained "multi run" results. Most likely a skillissue on my side. Further elaboration follows.<br />
==Single run==<br />
This means runing the multi run function for single iteration.<br />
===batch 0===<br />
<br />
===batch 10===<br />
<br />
===batch 30===<br />
<br />
===batch 50===<br />
<br />
<br />
==Multi run==<br />
===batch 0===<br />
<br />
===batch 10===<br />
<br />
===batch 30===<br />
<br />
===batch 50===<br />
<br />
výpis výsledků, jejich analýza, interpretace, zhodnocení.<br />
<br />
=Discussion=<br />
jak se Vám podařilo definovaný problém vyřešit<br />
<br />
<br />
=Code=<br />
<br />
g<br />
[[User:Tros01|Tros01]] ([[User talk:Tros01|talk]]) 22:19, 19 January 2025 (CET)</div>Tros01http://www.simulace.info/index.php?title=Populating_the_database&diff=26532Populating the database2025-01-19T22:24:50Z<p>Tros01: /* Entities */</p>
<hr />
<div>Úvodní odstavec<br />
<br />
=Problem definition=<br />
==Why?==<br />
Lets say that I have a database containing prepared activities and educational content for boy scouts group. Its purpose is to serve as a source of inspiration and eventually of collection of high quality content appropriate for kids during our weekly meetings or other occasions. From which source should be easy to get precisely only the desired results based on defined properties on each activity (eg. time needed for preparation, minimal number of players, etc.)<br />
<br />
BUT actually its currently more like a proof of concept and not a really operational tool. So accordingly there aren't yet any real records to speak about.<br />
This very early stage of development is exactly the reason why I think it is reasonable to think about how will the database be populated with data. As this will be crucial for its future usability and success. Therefore, the simulation should focus on modeling this data population process.<br />
==What?==<br />
To be precise, the simulation will be concerned with user behavior and related volume of stored records.<br />
<br />
It is important to say that user interface for reading is only the default web gui of the database itself (Neo4j), so the users will have to use the Cypher query language. So after they go through such a way to access the records, there better be some decent amount of useful ones in the database. This is because otherwise their whole effort would be pointless and the user would be discouraged from using the database again.<br />
<br />
Creating the records on the other hand will be easy and accessible as much as possible (user writes to google document in specified folder and with specified structure which enables then loading it programmaticaly into the database). This ease of creation is key to encouraging consistent contributions.<br />
<br />
And here comes the question whether this "natural" way of data population is enough, or rather how long will it take for the database to be able to provide satisfactory results for the user in majority of the cases and as such could be called a useful tool. If the time required would be too long, the users could lose interest of even contributing new content .<br />
Therefore, the simulation will model the rate of content creation and the subsequent impact on database searchability and usability.<br />
<br />
Additionally will be also evaluated the "batch population approach" to see weather it is worth considering to implement. This will involve creating a model of user behavior and content creation, simulating different scenarios, and analyzing the results.<br />
==Objectives==<br />
This simulation aims to predict the growth of the database, determine the feasibility of the current data population strategy and evaluate the alternative.<br />
<br />
#Predict the time needed to reach a critical mass of data sufficient for effective use.<br />
#Evaluate the effectiveness of the current data population method relatively to alternative.<br />
<br />
=Method=<br />
==Agent-based model==<br />
The core method used for this simulation is agent-based modeling (ABM). This approach was selected because it aligns well with the nature of the problem, which involves multiple individual users (agents) interacting with a shared environment (the database). Specifically, it enabled me to simulate:<br />
<br />
*Individual User Behaviors: Each agent acts independently, deciding whether to search the database, create a new record, or improve existing ones, based on their local information and probabilities.<br />
*Heterogeneity (Limited): While the agents initially are identical, they change during the simulation based on their interactions with the database.<br />
*Emergent System Behavior: The overall growth and usability of the database is not programmed directly, but emerges from the accumulation of individual actions.<br />
<br />
Alternatively the system dynamics or simple math equations could be used but neither of them would be more fitting for this usecase.<br />
While system dynamics could model the overall growth of the database as a system, it would not provide the same level of detail regarding individual user actions. System dynamics works well when dealing with aggregate levels and rates of change but isn't great for capturing how each agent behaviour individually impacts the system.<br />
<br />
Just as the equations could model a simplified database growth equation, but it would be extremely difficult to derive a model which includes agents success/fail feedback, record improvement and cooldown and thus it was not considered as applicable for this problem.<br />
==Julia==<br />
Because the ABM approach was chosen the NetLogo was concidered as environment for implemantation of the simulation, but also was the language Julia as it is also often used for simulations. In the end the Julia was chosen because of its more general usability and therefore more usecases when learned to use.<br />
<br />
diskuse možností řešení, výběr metody a prostředku (metod a prostředků) řešení, zdůvodnění výběru (jinými slovy, proč to chcete řešit tak, jak to chcete řešit, jaké jsou jiné alternativy a proč je ta Vámi zvolená pro tuto úlohu nejvhodnější)<br />
<br />
=Model=<br />
<br />
==Entities==<br />
;Database (db):<br />
A dictionary storing Record objects, categorized by integers representing different activity categories.<br />
*The keys of the dictionary are integers representing category id.<br />
*Each category is associated with a vector (array) of Record objects.<br />
*Initially, each category has an empty vector, which can be populated by new records.<br />
<br />
;Record:<br />
A struct containing:<br />
*id (Integer): A unique identifier for the record, auto-incrementing with each creation.<br />
*quality (Float64): Represents the perceived quality or usability of the record. (Originally it should more closely resamble the real live improvements by being represented by only range 1-10 as the real live records also can not be improved infinitelly, but in the end there was left simplier implemantation that just has a chance to improve the record during every picked to use event by random value withou top limit.)<br />
<br />
;Agent:<br />
A struct representing a user of the database.<br />
*probabilityToSearch (Float64): The agent's current probability of finding a useful record, it is based on past success of the agent when searching the db. This parameter influences agent's decision whether to search the db or not.<br />
*used (Dict{Int, Vector{Int}}): A dictionary that stores which record IDs have been used by agent and in which week the record has been used, so it won't be used by the same agent during a given cooldown period. Keys are record ids and values are vectors containing week integers in which the record has been used.<br />
<br />
==Variables==<br />
;NUM_AGENTS: <br />
: Integer representing the number of agents (users) participating in the simulation. Value is fixed at 3.<br />
;BATCH_UPLOAD_SIZES:<br />
: Vector of integers representing different sizes of initial record batches uploaded to the database. The values used in simulation are [0, 10].<br />
;initialQualityDist: <br />
: A lognormal distribution (LogNormal(3, 2)) used to generate the initial quality of new records. The mean is set to 3, and the standard deviation is set to 2, meaning the typical quality of created record will be around 3, but there could be some with higher or lower.<br />
;qualityImprovementProb<br />
: Float64 representing the probability that an agent will improve a record's quality after using it. Value is fixed at 0.7 for the sake of simplicity and simulation feasibility.<br />
;recordCreationProb<br />
: Float64 representing the probability that an agent creates a new record when they are preparing an activity and decide not to search the database. Value is fixed at 0.3 for the sake of simplicity and simulation feasibility.<br />
;categories<br />
: Vector of integer representing the category ids of the db records. The vector is generated as range from 1 to 20, [1:20;].<br />
;targetSuccessfulness<br />
: Float64 value, which represents minimum success rate, that needs to be reached for the database to be considered "useful" in a long term. Value is 0.75.<br />
;nSuccessfullFromEpisode<br />
: An integer number representing how many successful searches per episode of the simulation have to occur in order for it to be considered "useful". Value is 4.<br />
;episodeLength<br />
: Integer which represents length of a one "episode" within the simulation, which in this case is a sequence of weeks for which the success rate of the db will be tested if it met required conditions. Value is set to 6, this means 6 weeks.<br />
<br />
==Flow==<br />
'''1.Initialization:'''<br />
<br />
*The database is created with empty vectors of records for each defined category (integer from 1 to 20).<br />
*A defined number of agents are created with default probabilityToSearch.<br />
*Optionally, a number of initial Record objects will be created (based on parameter BATCH_UPLOAD_SIZE), and randomly assigned to a random category within the database.<br />
<br />
'''2.Weekly Cycle (One Tick):'''<br />
<br />
*Each week (tick), each agent attempts to prepare an activity.<br />
*Each agent selects a random category.<br />
*Then each agent decides whether to search the database based on their current probabilityToSearch (It was originally designed to be able to dynamicaly calculate probabilityToSearch of agents independently, but for the same reason the recordCreationProb is global to all agents, also this variable was left the same for all agents).<br />
<br />
;Search Behavior:<br />
<br />
*If the agent decides to search, it looks up all records that matches it selected category.<br />
*If records are found, the agents samples without replacement a predefined number of records for evaluation. Each has different probability based on its quality. The more quality it has, the higher the probability to be chosen. (Weights are calculated like this [rec.quality / sum(r.quality for r in records) for rec in records])<br />
*An agent tries to pick for use randomly one record from those records. <br />
*Before the agent uses any of the found records, there has to be checked if they haven't been used in a defined "cooldown period", which is set to 54 weeks. Each agent keeps track of used records and the weeks where they where used.<br />
*If the record the agent tries to pick is on cooldown, the agent proceeds to trying another one from the sampled ones until it finds a cooled down one or until there are no more samples (usually in the beginning of the simulation when there are yot not created record in the db).<br />
*If the record is used, there is a probability of the agent improving the quality of that used record.<br />
<br />
;Record Creation Behavior:<br />
<br />
*If the agent decides not to search or if the search is unsuccessful, it has a chance of creating a new record (based on parameter recordCreationProb).<br />
*If a new record is created, it's assigned a randomly generated initial quality based on the lognormal distribution, and pushed to db under it's selected category.<br />
*Also there is kept record of total number oc record created so far during the simulation and the order number of each record is assigned to the record during its creation as its id. This way its possible to keep track of which records were used before by the given agent.<br />
<br />
'''3.Evaluation'''<br />
*Further the simulation tracks total search attempts and successes. The success is considered only when a record is successfully used for an activity and not when a record is found or searched for.<br />
*At the end of each week, a weekly success rate is calculated by dividing the amount of successful record usages by the number of attempts that were performed.<br />
*The simulation continues until the database has reached "sufficient" usability.<br />
*A database is considered as "sufficiently useful" when success rates in a defined episode length (6 weeks) are over a defined threshold (75%) for a given minimum number of successful weeks (4 out of 6). In other words, when this condition is met within a 3 month timeframe.<br />
<br />
<br />
Detailní popis modelu, včetně parametrů, oborů hodnot, schémat, omezení modelu, apod. Popis musí být natolik detailní, aby podle něj bylo možné experiment zopakovat (a to samozřejmě i bez toho, že by byly k dispozici příslušné soubory s modelem).<br />
<br />
=Results=<br />
In the last section of appended code there was realized an attempt to calculate the results simply by adding new function which whould call the main simulation given number of times and recorded the results so the variability caused by randomness could be viewed. Specifically how the required number of weeks and number of created records varied when running the simulation repeatedly.<br />
<br />
Unfortunately there has been some enexpected and probably undesired patterns occuring in the obtained "multi run" results. Most likely a skillissue on my side. Further elaboration follows.<br />
==Single run==<br />
This means runing the multi run function for single iteration.<br />
===batch 0===<br />
<br />
===batch 10===<br />
<br />
===batch 30===<br />
<br />
===batch 50===<br />
<br />
<br />
==Multi run==<br />
===batch 0===<br />
<br />
===batch 10===<br />
<br />
===batch 30===<br />
<br />
===batch 50===<br />
<br />
výpis výsledků, jejich analýza, interpretace, zhodnocení.<br />
<br />
=Discussion=<br />
jak se Vám podařilo definovaný problém vyřešit<br />
<br />
<br />
=Code=<br />
<br />
g<br />
[[User:Tros01|Tros01]] ([[User talk:Tros01|talk]]) 22:19, 19 January 2025 (CET)</div>Tros01http://www.simulace.info/index.php?title=Populating_the_database&diff=26531Populating the database2025-01-19T22:20:12Z<p>Tros01: /* Results */</p>
<hr />
<div>Úvodní odstavec<br />
<br />
=Problem definition=<br />
==Why?==<br />
Lets say that I have a database containing prepared activities and educational content for boy scouts group. Its purpose is to serve as a source of inspiration and eventually of collection of high quality content appropriate for kids during our weekly meetings or other occasions. From which source should be easy to get precisely only the desired results based on defined properties on each activity (eg. time needed for preparation, minimal number of players, etc.)<br />
<br />
BUT actually its currently more like a proof of concept and not a really operational tool. So accordingly there aren't yet any real records to speak about.<br />
This very early stage of development is exactly the reason why I think it is reasonable to think about how will the database be populated with data. As this will be crucial for its future usability and success. Therefore, the simulation should focus on modeling this data population process.<br />
==What?==<br />
To be precise, the simulation will be concerned with user behavior and related volume of stored records.<br />
<br />
It is important to say that user interface for reading is only the default web gui of the database itself (Neo4j), so the users will have to use the Cypher query language. So after they go through such a way to access the records, there better be some decent amount of useful ones in the database. This is because otherwise their whole effort would be pointless and the user would be discouraged from using the database again.<br />
<br />
Creating the records on the other hand will be easy and accessible as much as possible (user writes to google document in specified folder and with specified structure which enables then loading it programmaticaly into the database). This ease of creation is key to encouraging consistent contributions.<br />
<br />
And here comes the question whether this "natural" way of data population is enough, or rather how long will it take for the database to be able to provide satisfactory results for the user in majority of the cases and as such could be called a useful tool. If the time required would be too long, the users could lose interest of even contributing new content .<br />
Therefore, the simulation will model the rate of content creation and the subsequent impact on database searchability and usability.<br />
<br />
Additionally will be also evaluated the "batch population approach" to see weather it is worth considering to implement. This will involve creating a model of user behavior and content creation, simulating different scenarios, and analyzing the results.<br />
==Objectives==<br />
This simulation aims to predict the growth of the database, determine the feasibility of the current data population strategy and evaluate the alternative.<br />
<br />
#Predict the time needed to reach a critical mass of data sufficient for effective use.<br />
#Evaluate the effectiveness of the current data population method relatively to alternative.<br />
<br />
=Method=<br />
==Agent-based model==<br />
The core method used for this simulation is agent-based modeling (ABM). This approach was selected because it aligns well with the nature of the problem, which involves multiple individual users (agents) interacting with a shared environment (the database). Specifically, it enabled me to simulate:<br />
<br />
*Individual User Behaviors: Each agent acts independently, deciding whether to search the database, create a new record, or improve existing ones, based on their local information and probabilities.<br />
*Heterogeneity (Limited): While the agents initially are identical, they change during the simulation based on their interactions with the database.<br />
*Emergent System Behavior: The overall growth and usability of the database is not programmed directly, but emerges from the accumulation of individual actions.<br />
<br />
Alternatively the system dynamics or simple math equations could be used but neither of them would be more fitting for this usecase.<br />
While system dynamics could model the overall growth of the database as a system, it would not provide the same level of detail regarding individual user actions. System dynamics works well when dealing with aggregate levels and rates of change but isn't great for capturing how each agent behaviour individually impacts the system.<br />
<br />
Just as the equations could model a simplified database growth equation, but it would be extremely difficult to derive a model which includes agents success/fail feedback, record improvement and cooldown and thus it was not considered as applicable for this problem.<br />
==Julia==<br />
Because the ABM approach was chosen the NetLogo was concidered as environment for implemantation of the simulation, but also was the language Julia as it is also often used for simulations. In the end the Julia was chosen because of its more general usability and therefore more usecases when learned to use.<br />
<br />
diskuse možností řešení, výběr metody a prostředku (metod a prostředků) řešení, zdůvodnění výběru (jinými slovy, proč to chcete řešit tak, jak to chcete řešit, jaké jsou jiné alternativy a proč je ta Vámi zvolená pro tuto úlohu nejvhodnější)<br />
<br />
=Model=<br />
<br />
==Entities==<br />
;Database (db):<br />
A dictionary storing Record objects, categorized by integers representing different activity categories.<br />
*The keys of the dictionary are integers representing category id.<br />
*Each category is associated with a vector (array) of Record objects.<br />
*Initially, each category has an empty vector, which can be populated by new records.<br />
<br />
;Record:<br />
A struct containing:<br />
*id (Integer): A unique identifier for the record, auto-incrementing with each creation.<br />
*quality (Float64): Represents the perceived quality or usability of the record.<br />
<br />
;Agent:<br />
A struct representing a user of the database.<br />
*probabilityToSearch (Float64): The agent's current probability of finding a useful record, it is based on past success of the agent when searching the db. This parameter influences agent's decision whether to search the db or not.<br />
*used (Dict{Int, Vector{Int}}): A dictionary that stores which record IDs have been used by agent and in which week the record has been used, so it won't be used by the same agent during a given cooldown period. Keys are record ids and values are vectors containing week integers in which the record has been used.<br />
<br />
==Variables==<br />
;NUM_AGENTS: <br />
: Integer representing the number of agents (users) participating in the simulation. Value is fixed at 3.<br />
;BATCH_UPLOAD_SIZES:<br />
: Vector of integers representing different sizes of initial record batches uploaded to the database. The values used in simulation are [0, 10].<br />
;initialQualityDist: <br />
: A lognormal distribution (LogNormal(3, 2)) used to generate the initial quality of new records. The mean is set to 3, and the standard deviation is set to 2, meaning the typical quality of created record will be around 3, but there could be some with higher or lower.<br />
;qualityImprovementProb<br />
: Float64 representing the probability that an agent will improve a record's quality after using it. Value is fixed at 0.7 for the sake of simplicity and simulation feasibility.<br />
;recordCreationProb<br />
: Float64 representing the probability that an agent creates a new record when they are preparing an activity and decide not to search the database. Value is fixed at 0.3 for the sake of simplicity and simulation feasibility.<br />
;categories<br />
: Vector of integer representing the category ids of the db records. The vector is generated as range from 1 to 20, [1:20;].<br />
;targetSuccessfulness<br />
: Float64 value, which represents minimum success rate, that needs to be reached for the database to be considered "useful" in a long term. Value is 0.75.<br />
;nSuccessfullFromEpisode<br />
: An integer number representing how many successful searches per episode of the simulation have to occur in order for it to be considered "useful". Value is 4.<br />
;episodeLength<br />
: Integer which represents length of a one "episode" within the simulation, which in this case is a sequence of weeks for which the success rate of the db will be tested if it met required conditions. Value is set to 6, this means 6 weeks.<br />
<br />
==Flow==<br />
'''1.Initialization:'''<br />
<br />
*The database is created with empty vectors of records for each defined category (integer from 1 to 20).<br />
*A defined number of agents are created with default probabilityToSearch.<br />
*Optionally, a number of initial Record objects will be created (based on parameter BATCH_UPLOAD_SIZE), and randomly assigned to a random category within the database.<br />
<br />
'''2.Weekly Cycle (One Tick):'''<br />
<br />
*Each week (tick), each agent attempts to prepare an activity.<br />
*Each agent selects a random category.<br />
*Then each agent decides whether to search the database based on their current probabilityToSearch (It was originally designed to be able to dynamicaly calculate probabilityToSearch of agents independently, but for the same reason the recordCreationProb is global to all agents, also this variable was left the same for all agents).<br />
<br />
;Search Behavior:<br />
<br />
*If the agent decides to search, it looks up all records that matches it selected category.<br />
*If records are found, the agents samples without replacement a predefined number of records for evaluation. Each has different probability based on its quality. The more quality it has, the higher the probability to be chosen. (Weights are calculated like this [rec.quality / sum(r.quality for r in records) for rec in records])<br />
*An agent tries to pick for use randomly one record from those records. <br />
*Before the agent uses any of the found records, there has to be checked if they haven't been used in a defined "cooldown period", which is set to 54 weeks. Each agent keeps track of used records and the weeks where they where used.<br />
*If the record the agent tries to pick is on cooldown, the agent proceeds to trying another one from the sampled ones until it finds a cooled down one or until there are no more samples (usually in the beginning of the simulation when there are yot not created record in the db).<br />
*If the record is used, there is a probability of the agent improving the quality of that used record.<br />
<br />
;Record Creation Behavior:<br />
<br />
*If the agent decides not to search or if the search is unsuccessful, it has a chance of creating a new record (based on parameter recordCreationProb).<br />
*If a new record is created, it's assigned a randomly generated initial quality based on the lognormal distribution, and pushed to db under it's selected category.<br />
*Also there is kept record of total number oc record created so far during the simulation and the order number of each record is assigned to the record during its creation as its id. This way its possible to keep track of which records were used before by the given agent.<br />
<br />
'''3.Evaluation'''<br />
*Further the simulation tracks total search attempts and successes. The success is considered only when a record is successfully used for an activity and not when a record is found or searched for.<br />
*At the end of each week, a weekly success rate is calculated by dividing the amount of successful record usages by the number of attempts that were performed.<br />
*The simulation continues until the database has reached "sufficient" usability.<br />
*A database is considered as "sufficiently useful" when success rates in a defined episode length (6 weeks) are over a defined threshold (75%) for a given minimum number of successful weeks (4 out of 6). In other words, when this condition is met within a 3 month timeframe.<br />
<br />
<br />
Detailní popis modelu, včetně parametrů, oborů hodnot, schémat, omezení modelu, apod. Popis musí být natolik detailní, aby podle něj bylo možné experiment zopakovat (a to samozřejmě i bez toho, že by byly k dispozici příslušné soubory s modelem).<br />
<br />
=Results=<br />
In the last section of appended code there was realized an attempt to calculate the results simply by adding new function which whould call the main simulation given number of times and recorded the results so the variability caused by randomness could be viewed. Specifically how the required number of weeks and number of created records varied when running the simulation repeatedly.<br />
<br />
Unfortunately there has been some enexpected and probably undesired patterns occuring in the obtained "multi run" results. Most likely a skillissue on my side. Further elaboration follows.<br />
==Single run==<br />
This means runing the multi run function for single iteration.<br />
===batch 0===<br />
<br />
===batch 10===<br />
<br />
===batch 30===<br />
<br />
===batch 50===<br />
<br />
<br />
==Multi run==<br />
===batch 0===<br />
<br />
===batch 10===<br />
<br />
===batch 30===<br />
<br />
===batch 50===<br />
<br />
výpis výsledků, jejich analýza, interpretace, zhodnocení.<br />
<br />
=Discussion=<br />
jak se Vám podařilo definovaný problém vyřešit<br />
<br />
<br />
=Code=<br />
<br />
g<br />
[[User:Tros01|Tros01]] ([[User talk:Tros01|talk]]) 22:19, 19 January 2025 (CET)</div>Tros01http://www.simulace.info/index.php?title=Populating_the_database&diff=26530Populating the database2025-01-19T22:06:35Z<p>Tros01: /* Flow */</p>
<hr />
<div>Úvodní odstavec<br />
<br />
=Problem definition=<br />
==Why?==<br />
Lets say that I have a database containing prepared activities and educational content for boy scouts group. Its purpose is to serve as a source of inspiration and eventually of collection of high quality content appropriate for kids during our weekly meetings or other occasions. From which source should be easy to get precisely only the desired results based on defined properties on each activity (eg. time needed for preparation, minimal number of players, etc.)<br />
<br />
BUT actually its currently more like a proof of concept and not a really operational tool. So accordingly there aren't yet any real records to speak about.<br />
This very early stage of development is exactly the reason why I think it is reasonable to think about how will the database be populated with data. As this will be crucial for its future usability and success. Therefore, the simulation should focus on modeling this data population process.<br />
==What?==<br />
To be precise, the simulation will be concerned with user behavior and related volume of stored records.<br />
<br />
It is important to say that user interface for reading is only the default web gui of the database itself (Neo4j), so the users will have to use the Cypher query language. So after they go through such a way to access the records, there better be some decent amount of useful ones in the database. This is because otherwise their whole effort would be pointless and the user would be discouraged from using the database again.<br />
<br />
Creating the records on the other hand will be easy and accessible as much as possible (user writes to google document in specified folder and with specified structure which enables then loading it programmaticaly into the database). This ease of creation is key to encouraging consistent contributions.<br />
<br />
And here comes the question whether this "natural" way of data population is enough, or rather how long will it take for the database to be able to provide satisfactory results for the user in majority of the cases and as such could be called a useful tool. If the time required would be too long, the users could lose interest of even contributing new content .<br />
Therefore, the simulation will model the rate of content creation and the subsequent impact on database searchability and usability.<br />
<br />
Additionally will be also evaluated the "batch population approach" to see weather it is worth considering to implement. This will involve creating a model of user behavior and content creation, simulating different scenarios, and analyzing the results.<br />
==Objectives==<br />
This simulation aims to predict the growth of the database, determine the feasibility of the current data population strategy and evaluate the alternative.<br />
<br />
#Predict the time needed to reach a critical mass of data sufficient for effective use.<br />
#Evaluate the effectiveness of the current data population method relatively to alternative.<br />
<br />
=Method=<br />
==Agent-based model==<br />
The core method used for this simulation is agent-based modeling (ABM). This approach was selected because it aligns well with the nature of the problem, which involves multiple individual users (agents) interacting with a shared environment (the database). Specifically, it enabled me to simulate:<br />
<br />
*Individual User Behaviors: Each agent acts independently, deciding whether to search the database, create a new record, or improve existing ones, based on their local information and probabilities.<br />
*Heterogeneity (Limited): While the agents initially are identical, they change during the simulation based on their interactions with the database.<br />
*Emergent System Behavior: The overall growth and usability of the database is not programmed directly, but emerges from the accumulation of individual actions.<br />
<br />
Alternatively the system dynamics or simple math equations could be used but neither of them would be more fitting for this usecase.<br />
While system dynamics could model the overall growth of the database as a system, it would not provide the same level of detail regarding individual user actions. System dynamics works well when dealing with aggregate levels and rates of change but isn't great for capturing how each agent behaviour individually impacts the system.<br />
<br />
Just as the equations could model a simplified database growth equation, but it would be extremely difficult to derive a model which includes agents success/fail feedback, record improvement and cooldown and thus it was not considered as applicable for this problem.<br />
==Julia==<br />
Because the ABM approach was chosen the NetLogo was concidered as environment for implemantation of the simulation, but also was the language Julia as it is also often used for simulations. In the end the Julia was chosen because of its more general usability and therefore more usecases when learned to use.<br />
<br />
diskuse možností řešení, výběr metody a prostředku (metod a prostředků) řešení, zdůvodnění výběru (jinými slovy, proč to chcete řešit tak, jak to chcete řešit, jaké jsou jiné alternativy a proč je ta Vámi zvolená pro tuto úlohu nejvhodnější)<br />
<br />
=Model=<br />
<br />
==Entities==<br />
;Database (db):<br />
A dictionary storing Record objects, categorized by integers representing different activity categories.<br />
*The keys of the dictionary are integers representing category id.<br />
*Each category is associated with a vector (array) of Record objects.<br />
*Initially, each category has an empty vector, which can be populated by new records.<br />
<br />
;Record:<br />
A struct containing:<br />
*id (Integer): A unique identifier for the record, auto-incrementing with each creation.<br />
*quality (Float64): Represents the perceived quality or usability of the record.<br />
<br />
;Agent:<br />
A struct representing a user of the database.<br />
*probabilityToSearch (Float64): The agent's current probability of finding a useful record, it is based on past success of the agent when searching the db. This parameter influences agent's decision whether to search the db or not.<br />
*used (Dict{Int, Vector{Int}}): A dictionary that stores which record IDs have been used by agent and in which week the record has been used, so it won't be used by the same agent during a given cooldown period. Keys are record ids and values are vectors containing week integers in which the record has been used.<br />
<br />
==Variables==<br />
;NUM_AGENTS: <br />
: Integer representing the number of agents (users) participating in the simulation. Value is fixed at 3.<br />
;BATCH_UPLOAD_SIZES:<br />
: Vector of integers representing different sizes of initial record batches uploaded to the database. The values used in simulation are [0, 10].<br />
;initialQualityDist: <br />
: A lognormal distribution (LogNormal(3, 2)) used to generate the initial quality of new records. The mean is set to 3, and the standard deviation is set to 2, meaning the typical quality of created record will be around 3, but there could be some with higher or lower.<br />
;qualityImprovementProb<br />
: Float64 representing the probability that an agent will improve a record's quality after using it. Value is fixed at 0.7 for the sake of simplicity and simulation feasibility.<br />
;recordCreationProb<br />
: Float64 representing the probability that an agent creates a new record when they are preparing an activity and decide not to search the database. Value is fixed at 0.3 for the sake of simplicity and simulation feasibility.<br />
;categories<br />
: Vector of integer representing the category ids of the db records. The vector is generated as range from 1 to 20, [1:20;].<br />
;targetSuccessfulness<br />
: Float64 value, which represents minimum success rate, that needs to be reached for the database to be considered "useful" in a long term. Value is 0.75.<br />
;nSuccessfullFromEpisode<br />
: An integer number representing how many successful searches per episode of the simulation have to occur in order for it to be considered "useful". Value is 4.<br />
;episodeLength<br />
: Integer which represents length of a one "episode" within the simulation, which in this case is a sequence of weeks for which the success rate of the db will be tested if it met required conditions. Value is set to 6, this means 6 weeks.<br />
<br />
==Flow==<br />
'''1.Initialization:'''<br />
<br />
*The database is created with empty vectors of records for each defined category (integer from 1 to 20).<br />
*A defined number of agents are created with default probabilityToSearch.<br />
*Optionally, a number of initial Record objects will be created (based on parameter BATCH_UPLOAD_SIZE), and randomly assigned to a random category within the database.<br />
<br />
'''2.Weekly Cycle (One Tick):'''<br />
<br />
*Each week (tick), each agent attempts to prepare an activity.<br />
*Each agent selects a random category.<br />
*Then each agent decides whether to search the database based on their current probabilityToSearch (It was originally designed to be able to dynamicaly calculate probabilityToSearch of agents independently, but for the same reason the recordCreationProb is global to all agents, also this variable was left the same for all agents).<br />
<br />
;Search Behavior:<br />
<br />
*If the agent decides to search, it looks up all records that matches it selected category.<br />
*If records are found, the agents samples without replacement a predefined number of records for evaluation. Each has different probability based on its quality. The more quality it has, the higher the probability to be chosen. (Weights are calculated like this [rec.quality / sum(r.quality for r in records) for rec in records])<br />
*An agent tries to pick for use randomly one record from those records. <br />
*Before the agent uses any of the found records, there has to be checked if they haven't been used in a defined "cooldown period", which is set to 54 weeks. Each agent keeps track of used records and the weeks where they where used.<br />
*If the record the agent tries to pick is on cooldown, the agent proceeds to trying another one from the sampled ones until it finds a cooled down one or until there are no more samples (usually in the beginning of the simulation when there are yot not created record in the db).<br />
*If the record is used, there is a probability of the agent improving the quality of that used record.<br />
<br />
;Record Creation Behavior:<br />
<br />
*If the agent decides not to search or if the search is unsuccessful, it has a chance of creating a new record (based on parameter recordCreationProb).<br />
*If a new record is created, it's assigned a randomly generated initial quality based on the lognormal distribution, and pushed to db under it's selected category.<br />
*Also there is kept record of total number oc record created so far during the simulation and the order number of each record is assigned to the record during its creation as its id. This way its possible to keep track of which records were used before by the given agent.<br />
<br />
'''3.Evaluation'''<br />
*Further the simulation tracks total search attempts and successes. The success is considered only when a record is successfully used for an activity and not when a record is found or searched for.<br />
*At the end of each week, a weekly success rate is calculated by dividing the amount of successful record usages by the number of attempts that were performed.<br />
*The simulation continues until the database has reached "sufficient" usability.<br />
*A database is considered as "sufficiently useful" when success rates in a defined episode length (6 weeks) are over a defined threshold (75%) for a given minimum number of successful weeks (4 out of 6). In other words, when this condition is met within a 3 month timeframe.<br />
<br />
<br />
Detailní popis modelu, včetně parametrů, oborů hodnot, schémat, omezení modelu, apod. Popis musí být natolik detailní, aby podle něj bylo možné experiment zopakovat (a to samozřejmě i bez toho, že by byly k dispozici příslušné soubory s modelem).<br />
<br />
=Results=<br />
==Single run==<br />
<br />
==Multi run==<br />
<br />
<br />
výpis výsledků, jejich analýza, interpretace, zhodnocení.<br />
<br />
=Discussion=<br />
jak se Vám podařilo definovaný problém vyřešit<br />
<br />
<br />
=Code=<br />
<br />
g<br />
[[User:Tros01|Tros01]] ([[User talk:Tros01|talk]]) 22:19, 19 January 2025 (CET)</div>Tros01http://www.simulace.info/index.php?title=Populating_the_database&diff=26529Populating the database2025-01-19T21:40:49Z<p>Tros01: /* Flow */</p>
<hr />
<div>Úvodní odstavec<br />
<br />
=Problem definition=<br />
==Why?==<br />
Lets say that I have a database containing prepared activities and educational content for boy scouts group. Its purpose is to serve as a source of inspiration and eventually of collection of high quality content appropriate for kids during our weekly meetings or other occasions. From which source should be easy to get precisely only the desired results based on defined properties on each activity (eg. time needed for preparation, minimal number of players, etc.)<br />
<br />
BUT actually its currently more like a proof of concept and not a really operational tool. So accordingly there aren't yet any real records to speak about.<br />
This very early stage of development is exactly the reason why I think it is reasonable to think about how will the database be populated with data. As this will be crucial for its future usability and success. Therefore, the simulation should focus on modeling this data population process.<br />
==What?==<br />
To be precise, the simulation will be concerned with user behavior and related volume of stored records.<br />
<br />
It is important to say that user interface for reading is only the default web gui of the database itself (Neo4j), so the users will have to use the Cypher query language. So after they go through such a way to access the records, there better be some decent amount of useful ones in the database. This is because otherwise their whole effort would be pointless and the user would be discouraged from using the database again.<br />
<br />
Creating the records on the other hand will be easy and accessible as much as possible (user writes to google document in specified folder and with specified structure which enables then loading it programmaticaly into the database). This ease of creation is key to encouraging consistent contributions.<br />
<br />
And here comes the question whether this "natural" way of data population is enough, or rather how long will it take for the database to be able to provide satisfactory results for the user in majority of the cases and as such could be called a useful tool. If the time required would be too long, the users could lose interest of even contributing new content .<br />
Therefore, the simulation will model the rate of content creation and the subsequent impact on database searchability and usability.<br />
<br />
Additionally will be also evaluated the "batch population approach" to see weather it is worth considering to implement. This will involve creating a model of user behavior and content creation, simulating different scenarios, and analyzing the results.<br />
==Objectives==<br />
This simulation aims to predict the growth of the database, determine the feasibility of the current data population strategy and evaluate the alternative.<br />
<br />
#Predict the time needed to reach a critical mass of data sufficient for effective use.<br />
#Evaluate the effectiveness of the current data population method relatively to alternative.<br />
<br />
=Method=<br />
==Agent-based model==<br />
The core method used for this simulation is agent-based modeling (ABM). This approach was selected because it aligns well with the nature of the problem, which involves multiple individual users (agents) interacting with a shared environment (the database). Specifically, it enabled me to simulate:<br />
<br />
*Individual User Behaviors: Each agent acts independently, deciding whether to search the database, create a new record, or improve existing ones, based on their local information and probabilities.<br />
*Heterogeneity (Limited): While the agents initially are identical, they change during the simulation based on their interactions with the database.<br />
*Emergent System Behavior: The overall growth and usability of the database is not programmed directly, but emerges from the accumulation of individual actions.<br />
<br />
Alternatively the system dynamics or simple math equations could be used but neither of them would be more fitting for this usecase.<br />
While system dynamics could model the overall growth of the database as a system, it would not provide the same level of detail regarding individual user actions. System dynamics works well when dealing with aggregate levels and rates of change but isn't great for capturing how each agent behaviour individually impacts the system.<br />
<br />
Just as the equations could model a simplified database growth equation, but it would be extremely difficult to derive a model which includes agents success/fail feedback, record improvement and cooldown and thus it was not considered as applicable for this problem.<br />
==Julia==<br />
Because the ABM approach was chosen the NetLogo was concidered as environment for implemantation of the simulation, but also was the language Julia as it is also often used for simulations. In the end the Julia was chosen because of its more general usability and therefore more usecases when learned to use.<br />
<br />
diskuse možností řešení, výběr metody a prostředku (metod a prostředků) řešení, zdůvodnění výběru (jinými slovy, proč to chcete řešit tak, jak to chcete řešit, jaké jsou jiné alternativy a proč je ta Vámi zvolená pro tuto úlohu nejvhodnější)<br />
<br />
=Model=<br />
<br />
==Entities==<br />
;Database (db):<br />
A dictionary storing Record objects, categorized by integers representing different activity categories.<br />
*The keys of the dictionary are integers representing category id.<br />
*Each category is associated with a vector (array) of Record objects.<br />
*Initially, each category has an empty vector, which can be populated by new records.<br />
<br />
;Record:<br />
A struct containing:<br />
*id (Integer): A unique identifier for the record, auto-incrementing with each creation.<br />
*quality (Float64): Represents the perceived quality or usability of the record.<br />
<br />
;Agent:<br />
A struct representing a user of the database.<br />
*probabilityToSearch (Float64): The agent's current probability of finding a useful record, it is based on past success of the agent when searching the db. This parameter influences agent's decision whether to search the db or not.<br />
*used (Dict{Int, Vector{Int}}): A dictionary that stores which record IDs have been used by agent and in which week the record has been used, so it won't be used by the same agent during a given cooldown period. Keys are record ids and values are vectors containing week integers in which the record has been used.<br />
<br />
==Variables==<br />
;NUM_AGENTS: <br />
: Integer representing the number of agents (users) participating in the simulation. Value is fixed at 3.<br />
;BATCH_UPLOAD_SIZES:<br />
: Vector of integers representing different sizes of initial record batches uploaded to the database. The values used in simulation are [0, 10].<br />
;initialQualityDist: <br />
: A lognormal distribution (LogNormal(3, 2)) used to generate the initial quality of new records. The mean is set to 3, and the standard deviation is set to 2, meaning the typical quality of created record will be around 3, but there could be some with higher or lower.<br />
;qualityImprovementProb<br />
: Float64 representing the probability that an agent will improve a record's quality after using it. Value is fixed at 0.7 for the sake of simplicity and simulation feasibility.<br />
;recordCreationProb<br />
: Float64 representing the probability that an agent creates a new record when they are preparing an activity and decide not to search the database. Value is fixed at 0.3 for the sake of simplicity and simulation feasibility.<br />
;categories<br />
: Vector of integer representing the category ids of the db records. The vector is generated as range from 1 to 20, [1:20;].<br />
;targetSuccessfulness<br />
: Float64 value, which represents minimum success rate, that needs to be reached for the database to be considered "useful" in a long term. Value is 0.75.<br />
;nSuccessfullFromEpisode<br />
: An integer number representing how many successful searches per episode of the simulation have to occur in order for it to be considered "useful". Value is 4.<br />
;episodeLength<br />
: Integer which represents length of a one "episode" within the simulation, which in this case is a sequence of weeks for which the success rate of the db will be tested if it met required conditions. Value is set to 6, this means 6 weeks.<br />
<br />
==Flow==<br />
'''1.Initialization:'''<br />
<br />
*The database is created with empty vectors of records for each defined category (integer from 1 to 20).<br />
*A defined number of agents are created with default probabilityToSearch.<br />
*Optionally, a number of initial Record objects will be created (based on parameter BATCH_UPLOAD_SIZE), and randomly assigned to a random category within the database.<br />
<br />
'''2.Weekly Cycle (One Tick):'''<br />
<br />
*Each week (tick), each agent attempts to prepare an activity.<br />
*Each agent selects a random category.<br />
*Then each agent decides whether to search the database based on their current probabilityToSearch (It was originally designed to be able to dynamicaly calculate probabilityToSearch of agents independently, but for the same reason the recordCreationProb is global to all agents, also this variable was left the same for all agents).<br />
<br />
;Search Behavior:<br />
<br />
If the agent decides to search, it looks up all records that matches it selected category.<br />
<br />
If records are found, the agents samples a predefined number of records for evaluation. Each has different probability based on its quality. The more quality it has, the higher the probability to be chosen.<br />
<br />
An agent tries to use (for it's activity preparation) randomly one record from those records. The probability of each record to be selected to be used is based on its quality.<br />
<br />
Before the agent uses any of the found records, there has to be checked if they haven't been used in a defined "cooldown period", which is set to 54 weeks. Each agent keeps track of used records and the weeks where they where used.<br />
<br />
If the record is used, there is a probability of the agent improving the quality of that used record. If record isn't used it also improves a record (newly recorded), to indicate some minor change in activity record during preparation.<br />
<br />
;Record Creation Behavior:<br />
<br />
If the agent decides not to search or if the search is unsuccessful, it has a chance of creating a new record (based on parameter recordCreationProb).<br />
<br />
If a new record is created, it's assigned a randomly generated initial quality based on the lognormal distribution, and pushed to db under it's selected category.<br />
<br />
The simulation tracks total search attempts and successes. The success is considered only when a record is successfully used for an activity and not when a record is found or searched for.<br />
<br />
'''3.Success Rate Calculation:'''<br />
<br />
At the end of each week, a weekly success rate is calculated by dividing the amount of successful record usages by the number of attempts that were performed.<br />
<br />
'''4.Simulation Termination:'''<br />
<br />
The simulation continues until the database has reached "sufficient" usability.<br />
<br />
A database is considered as "sufficiently useful" when success rates in a defined episode length (6 weeks) are over a defined threshold (75%) for a given minimum number of successful weeks (4 out of 6). In other words, when this condition is met within a 3 month timeframe.<br />
<br />
<br />
Detailní popis modelu, včetně parametrů, oborů hodnot, schémat, omezení modelu, apod. Popis musí být natolik detailní, aby podle něj bylo možné experiment zopakovat (a to samozřejmě i bez toho, že by byly k dispozici příslušné soubory s modelem).<br />
<br />
=Results=<br />
==Single run==<br />
<br />
==Multi run==<br />
<br />
<br />
výpis výsledků, jejich analýza, interpretace, zhodnocení.<br />
<br />
=Discussion=<br />
jak se Vám podařilo definovaný problém vyřešit<br />
<br />
<br />
=Code=<br />
<br />
g<br />
[[User:Tros01|Tros01]] ([[User talk:Tros01|talk]]) 22:19, 19 January 2025 (CET)</div>Tros01http://www.simulace.info/index.php?title=Populating_the_database&diff=26528Populating the database2025-01-19T21:38:10Z<p>Tros01: /* Variables */</p>
<hr />
<div>Úvodní odstavec<br />
<br />
=Problem definition=<br />
==Why?==<br />
Lets say that I have a database containing prepared activities and educational content for boy scouts group. Its purpose is to serve as a source of inspiration and eventually of collection of high quality content appropriate for kids during our weekly meetings or other occasions. From which source should be easy to get precisely only the desired results based on defined properties on each activity (eg. time needed for preparation, minimal number of players, etc.)<br />
<br />
BUT actually its currently more like a proof of concept and not a really operational tool. So accordingly there aren't yet any real records to speak about.<br />
This very early stage of development is exactly the reason why I think it is reasonable to think about how will the database be populated with data. As this will be crucial for its future usability and success. Therefore, the simulation should focus on modeling this data population process.<br />
==What?==<br />
To be precise, the simulation will be concerned with user behavior and related volume of stored records.<br />
<br />
It is important to say that user interface for reading is only the default web gui of the database itself (Neo4j), so the users will have to use the Cypher query language. So after they go through such a way to access the records, there better be some decent amount of useful ones in the database. This is because otherwise their whole effort would be pointless and the user would be discouraged from using the database again.<br />
<br />
Creating the records on the other hand will be easy and accessible as much as possible (user writes to google document in specified folder and with specified structure which enables then loading it programmaticaly into the database). This ease of creation is key to encouraging consistent contributions.<br />
<br />
And here comes the question whether this "natural" way of data population is enough, or rather how long will it take for the database to be able to provide satisfactory results for the user in majority of the cases and as such could be called a useful tool. If the time required would be too long, the users could lose interest of even contributing new content .<br />
Therefore, the simulation will model the rate of content creation and the subsequent impact on database searchability and usability.<br />
<br />
Additionally will be also evaluated the "batch population approach" to see weather it is worth considering to implement. This will involve creating a model of user behavior and content creation, simulating different scenarios, and analyzing the results.<br />
==Objectives==<br />
This simulation aims to predict the growth of the database, determine the feasibility of the current data population strategy and evaluate the alternative.<br />
<br />
#Predict the time needed to reach a critical mass of data sufficient for effective use.<br />
#Evaluate the effectiveness of the current data population method relatively to alternative.<br />
<br />
=Method=<br />
==Agent-based model==<br />
The core method used for this simulation is agent-based modeling (ABM). This approach was selected because it aligns well with the nature of the problem, which involves multiple individual users (agents) interacting with a shared environment (the database). Specifically, it enabled me to simulate:<br />
<br />
*Individual User Behaviors: Each agent acts independently, deciding whether to search the database, create a new record, or improve existing ones, based on their local information and probabilities.<br />
*Heterogeneity (Limited): While the agents initially are identical, they change during the simulation based on their interactions with the database.<br />
*Emergent System Behavior: The overall growth and usability of the database is not programmed directly, but emerges from the accumulation of individual actions.<br />
<br />
Alternatively the system dynamics or simple math equations could be used but neither of them would be more fitting for this usecase.<br />
While system dynamics could model the overall growth of the database as a system, it would not provide the same level of detail regarding individual user actions. System dynamics works well when dealing with aggregate levels and rates of change but isn't great for capturing how each agent behaviour individually impacts the system.<br />
<br />
Just as the equations could model a simplified database growth equation, but it would be extremely difficult to derive a model which includes agents success/fail feedback, record improvement and cooldown and thus it was not considered as applicable for this problem.<br />
==Julia==<br />
Because the ABM approach was chosen the NetLogo was concidered as environment for implemantation of the simulation, but also was the language Julia as it is also often used for simulations. In the end the Julia was chosen because of its more general usability and therefore more usecases when learned to use.<br />
<br />
diskuse možností řešení, výběr metody a prostředku (metod a prostředků) řešení, zdůvodnění výběru (jinými slovy, proč to chcete řešit tak, jak to chcete řešit, jaké jsou jiné alternativy a proč je ta Vámi zvolená pro tuto úlohu nejvhodnější)<br />
<br />
=Model=<br />
<br />
==Entities==<br />
;Database (db):<br />
A dictionary storing Record objects, categorized by integers representing different activity categories.<br />
*The keys of the dictionary are integers representing category id.<br />
*Each category is associated with a vector (array) of Record objects.<br />
*Initially, each category has an empty vector, which can be populated by new records.<br />
<br />
;Record:<br />
A struct containing:<br />
*id (Integer): A unique identifier for the record, auto-incrementing with each creation.<br />
*quality (Float64): Represents the perceived quality or usability of the record.<br />
<br />
;Agent:<br />
A struct representing a user of the database.<br />
*probabilityToSearch (Float64): The agent's current probability of finding a useful record, it is based on past success of the agent when searching the db. This parameter influences agent's decision whether to search the db or not.<br />
*used (Dict{Int, Vector{Int}}): A dictionary that stores which record IDs have been used by agent and in which week the record has been used, so it won't be used by the same agent during a given cooldown period. Keys are record ids and values are vectors containing week integers in which the record has been used.<br />
<br />
==Variables==<br />
;NUM_AGENTS: <br />
: Integer representing the number of agents (users) participating in the simulation. Value is fixed at 3.<br />
;BATCH_UPLOAD_SIZES:<br />
: Vector of integers representing different sizes of initial record batches uploaded to the database. The values used in simulation are [0, 10].<br />
;initialQualityDist: <br />
: A lognormal distribution (LogNormal(3, 2)) used to generate the initial quality of new records. The mean is set to 3, and the standard deviation is set to 2, meaning the typical quality of created record will be around 3, but there could be some with higher or lower.<br />
;qualityImprovementProb<br />
: Float64 representing the probability that an agent will improve a record's quality after using it. Value is fixed at 0.7 for the sake of simplicity and simulation feasibility.<br />
;recordCreationProb<br />
: Float64 representing the probability that an agent creates a new record when they are preparing an activity and decide not to search the database. Value is fixed at 0.3 for the sake of simplicity and simulation feasibility.<br />
;categories<br />
: Vector of integer representing the category ids of the db records. The vector is generated as range from 1 to 20, [1:20;].<br />
;targetSuccessfulness<br />
: Float64 value, which represents minimum success rate, that needs to be reached for the database to be considered "useful" in a long term. Value is 0.75.<br />
;nSuccessfullFromEpisode<br />
: An integer number representing how many successful searches per episode of the simulation have to occur in order for it to be considered "useful". Value is 4.<br />
;episodeLength<br />
: Integer which represents length of a one "episode" within the simulation, which in this case is a sequence of weeks for which the success rate of the db will be tested if it met required conditions. Value is set to 6, this means 6 weeks.<br />
<br />
==Flow==<br />
'''1.Initialization:'''<br />
<br />
*The database is created with empty vectors of records for each defined category (integer from 1 to 20).<br />
*A defined number of agents are created with default probabilityToSearch.<br />
*Optionally, a number of initial Record objects will be created (based on parameter BATCH_UPLOAD_SIZE), and randomly assigned to a random category within the database.<br />
<br />
'''2.Weekly Cycle (One Tick):'''<br />
<br />
*Each week (tick), each agent attempts to prepare an activity.<br />
*Each agent selects a random category.<br />
*Database Search Decision: An agent decides whether to search the database based on their current probabilityToSearch (It was originally designed to be able to dynamicaly calculate probabilityToSearch of agents independently, but for the same reason the recordCreationProb is global to all agents, also this variable was left the same for all agents).<br />
<br />
Search Behavior:<br />
<br />
If the agent decides to search, it looks up all records that matches it selected category.<br />
<br />
If records are found, the agents samples a predefined number of records for evaluation. Each has different probability based on its quality. The more quality it has, the higher the probability to be chosen.<br />
<br />
An agent tries to use (for it's activity preparation) randomly one record from those records. The probability of each record to be selected to be used is based on its quality.<br />
<br />
Before the agent uses any of the found records, there has to be checked if they haven't been used in a defined "cooldown period", which is set to 54 weeks. Each agent keeps track of used records and the weeks where they where used.<br />
<br />
If the record is used, there is a probability of the agent improving the quality of that used record. If record isn't used it also improves a record (newly recorded), to indicate some minor change in activity record during preparation.<br />
<br />
Record Creation Behavior:<br />
<br />
If the agent decides not to search or if the search is unsuccessful, it has a chance of creating a new record (based on parameter recordCreationProb).<br />
<br />
If a new record is created, it's assigned a randomly generated initial quality based on the lognormal distribution, and pushed to db under it's selected category.<br />
<br />
The simulation tracks total search attempts and successes. The success is considered only when a record is successfully used for an activity and not when a record is found or searched for.<br />
<br />
#Success Rate Calculation:<br />
<br />
At the end of each week, a weekly success rate is calculated by dividing the amount of successful record usages by the number of attempts that were performed.<br />
<br />
#Simulation Termination:<br />
<br />
The simulation continues until the database has reached "sufficient" usability.<br />
<br />
A database is considered as "sufficiently useful" when success rates in a defined episode length (6 weeks) are over a defined threshold (75%) for a given minimum number of successful weeks (4 out of 6). In other words, when this condition is met within a 3 month timeframe.<br />
<br />
<br />
Detailní popis modelu, včetně parametrů, oborů hodnot, schémat, omezení modelu, apod. Popis musí být natolik detailní, aby podle něj bylo možné experiment zopakovat (a to samozřejmě i bez toho, že by byly k dispozici příslušné soubory s modelem).<br />
<br />
=Results=<br />
==Single run==<br />
<br />
==Multi run==<br />
<br />
<br />
výpis výsledků, jejich analýza, interpretace, zhodnocení.<br />
<br />
=Discussion=<br />
jak se Vám podařilo definovaný problém vyřešit<br />
<br />
<br />
=Code=<br />
<br />
g<br />
[[User:Tros01|Tros01]] ([[User talk:Tros01|talk]]) 22:19, 19 January 2025 (CET)</div>Tros01http://www.simulace.info/index.php?title=Populating_the_database&diff=26527Populating the database2025-01-19T21:37:03Z<p>Tros01: /* Flow */</p>
<hr />
<div>Úvodní odstavec<br />
<br />
=Problem definition=<br />
==Why?==<br />
Lets say that I have a database containing prepared activities and educational content for boy scouts group. Its purpose is to serve as a source of inspiration and eventually of collection of high quality content appropriate for kids during our weekly meetings or other occasions. From which source should be easy to get precisely only the desired results based on defined properties on each activity (eg. time needed for preparation, minimal number of players, etc.)<br />
<br />
BUT actually its currently more like a proof of concept and not a really operational tool. So accordingly there aren't yet any real records to speak about.<br />
This very early stage of development is exactly the reason why I think it is reasonable to think about how will the database be populated with data. As this will be crucial for its future usability and success. Therefore, the simulation should focus on modeling this data population process.<br />
==What?==<br />
To be precise, the simulation will be concerned with user behavior and related volume of stored records.<br />
<br />
It is important to say that user interface for reading is only the default web gui of the database itself (Neo4j), so the users will have to use the Cypher query language. So after they go through such a way to access the records, there better be some decent amount of useful ones in the database. This is because otherwise their whole effort would be pointless and the user would be discouraged from using the database again.<br />
<br />
Creating the records on the other hand will be easy and accessible as much as possible (user writes to google document in specified folder and with specified structure which enables then loading it programmaticaly into the database). This ease of creation is key to encouraging consistent contributions.<br />
<br />
And here comes the question whether this "natural" way of data population is enough, or rather how long will it take for the database to be able to provide satisfactory results for the user in majority of the cases and as such could be called a useful tool. If the time required would be too long, the users could lose interest of even contributing new content .<br />
Therefore, the simulation will model the rate of content creation and the subsequent impact on database searchability and usability.<br />
<br />
Additionally will be also evaluated the "batch population approach" to see weather it is worth considering to implement. This will involve creating a model of user behavior and content creation, simulating different scenarios, and analyzing the results.<br />
==Objectives==<br />
This simulation aims to predict the growth of the database, determine the feasibility of the current data population strategy and evaluate the alternative.<br />
<br />
#Predict the time needed to reach a critical mass of data sufficient for effective use.<br />
#Evaluate the effectiveness of the current data population method relatively to alternative.<br />
<br />
=Method=<br />
==Agent-based model==<br />
The core method used for this simulation is agent-based modeling (ABM). This approach was selected because it aligns well with the nature of the problem, which involves multiple individual users (agents) interacting with a shared environment (the database). Specifically, it enabled me to simulate:<br />
<br />
*Individual User Behaviors: Each agent acts independently, deciding whether to search the database, create a new record, or improve existing ones, based on their local information and probabilities.<br />
*Heterogeneity (Limited): While the agents initially are identical, they change during the simulation based on their interactions with the database.<br />
*Emergent System Behavior: The overall growth and usability of the database is not programmed directly, but emerges from the accumulation of individual actions.<br />
<br />
Alternatively the system dynamics or simple math equations could be used but neither of them would be more fitting for this usecase.<br />
While system dynamics could model the overall growth of the database as a system, it would not provide the same level of detail regarding individual user actions. System dynamics works well when dealing with aggregate levels and rates of change but isn't great for capturing how each agent behaviour individually impacts the system.<br />
<br />
Just as the equations could model a simplified database growth equation, but it would be extremely difficult to derive a model which includes agents success/fail feedback, record improvement and cooldown and thus it was not considered as applicable for this problem.<br />
==Julia==<br />
Because the ABM approach was chosen the NetLogo was concidered as environment for implemantation of the simulation, but also was the language Julia as it is also often used for simulations. In the end the Julia was chosen because of its more general usability and therefore more usecases when learned to use.<br />
<br />
diskuse možností řešení, výběr metody a prostředku (metod a prostředků) řešení, zdůvodnění výběru (jinými slovy, proč to chcete řešit tak, jak to chcete řešit, jaké jsou jiné alternativy a proč je ta Vámi zvolená pro tuto úlohu nejvhodnější)<br />
<br />
=Model=<br />
<br />
==Entities==<br />
;Database (db):<br />
A dictionary storing Record objects, categorized by integers representing different activity categories.<br />
*The keys of the dictionary are integers representing category id.<br />
*Each category is associated with a vector (array) of Record objects.<br />
*Initially, each category has an empty vector, which can be populated by new records.<br />
<br />
;Record:<br />
A struct containing:<br />
*id (Integer): A unique identifier for the record, auto-incrementing with each creation.<br />
*quality (Float64): Represents the perceived quality or usability of the record.<br />
<br />
;Agent:<br />
A struct representing a user of the database.<br />
*probabilityToSearch (Float64): The agent's current probability of finding a useful record, it is based on past success of the agent when searching the db. This parameter influences agent's decision whether to search the db or not.<br />
*used (Dict{Int, Vector{Int}}): A dictionary that stores which record IDs have been used by agent and in which week the record has been used, so it won't be used by the same agent during a given cooldown period. Keys are record ids and values are vectors containing week integers in which the record has been used.<br />
<br />
==Variables==<br />
;NUM_AGENTS: <br />
: Integer representing the number of agents (users) participating in the simulation. Value is fixed at 3.<br />
;BATCH_UPLOAD_SIZES:<br />
: Vector of integers representing different sizes of initial record batches uploaded to the database. The values used in simulation are [0, 10].<br />
;initialQualityDist: <br />
: A lognormal distribution (LogNormal(3, 2)) used to generate the initial quality of new records. The mean is set to 3, and the standard deviation is set to 2, meaning the typical quality of created record will be around 3, but there could be some with higher or lower.<br />
;qualityImprovementProb<br />
: Float64 representing the probability that an agent will improve a record's quality after using it. Value is fixed at 0.7.<br />
;recordCreationProb<br />
: Float64 representing the probability that an agent creates a new record when they are preparing an activity and decide not to search the database. Value is fixed at 0.3.<br />
;categories<br />
: Vector of integer representing the category ids of the db records. The vector is generated as range from 1 to 20, [1:20;].<br />
;targetSuccessfulness<br />
: Float64 value, which represents minimum success rate, that needs to be reached for the database to be considered "useful" in a long term. Value is 0.75.<br />
;nSuccessfullFromEpisode<br />
: An integer number representing how many successful searches per episode of the simulation have to occur in order for it to be considered "useful". Value is 4.<br />
;episodeLength<br />
: Integer which represents length of a one "episode" within the simulation, which in this case is a sequence of weeks for which the success rate of the db will be tested if it met required conditions. Value is set to 6, this means 6 weeks.<br />
<br />
==Flow==<br />
'''1.Initialization:'''<br />
<br />
*The database is created with empty vectors of records for each defined category (integer from 1 to 20).<br />
*A defined number of agents are created with default probabilityToSearch.<br />
*Optionally, a number of initial Record objects will be created (based on parameter BATCH_UPLOAD_SIZE), and randomly assigned to a random category within the database.<br />
<br />
'''2.Weekly Cycle (One Tick):'''<br />
<br />
*Each week (tick), each agent attempts to prepare an activity.<br />
*Each agent selects a random category.<br />
*Database Search Decision: An agent decides whether to search the database based on their current probabilityToSearch (It was originally designed to be able to dynamicaly calculate probabilityToSearch of agents independently, but for the same reason the recordCreationProb is global to all agents, also this variable was left the same for all agents).<br />
<br />
Search Behavior:<br />
<br />
If the agent decides to search, it looks up all records that matches it selected category.<br />
<br />
If records are found, the agents samples a predefined number of records for evaluation. Each has different probability based on its quality. The more quality it has, the higher the probability to be chosen.<br />
<br />
An agent tries to use (for it's activity preparation) randomly one record from those records. The probability of each record to be selected to be used is based on its quality.<br />
<br />
Before the agent uses any of the found records, there has to be checked if they haven't been used in a defined "cooldown period", which is set to 54 weeks. Each agent keeps track of used records and the weeks where they where used.<br />
<br />
If the record is used, there is a probability of the agent improving the quality of that used record. If record isn't used it also improves a record (newly recorded), to indicate some minor change in activity record during preparation.<br />
<br />
Record Creation Behavior:<br />
<br />
If the agent decides not to search or if the search is unsuccessful, it has a chance of creating a new record (based on parameter recordCreationProb).<br />
<br />
If a new record is created, it's assigned a randomly generated initial quality based on the lognormal distribution, and pushed to db under it's selected category.<br />
<br />
The simulation tracks total search attempts and successes. The success is considered only when a record is successfully used for an activity and not when a record is found or searched for.<br />
<br />
#Success Rate Calculation:<br />
<br />
At the end of each week, a weekly success rate is calculated by dividing the amount of successful record usages by the number of attempts that were performed.<br />
<br />
#Simulation Termination:<br />
<br />
The simulation continues until the database has reached "sufficient" usability.<br />
<br />
A database is considered as "sufficiently useful" when success rates in a defined episode length (6 weeks) are over a defined threshold (75%) for a given minimum number of successful weeks (4 out of 6). In other words, when this condition is met within a 3 month timeframe.<br />
<br />
<br />
Detailní popis modelu, včetně parametrů, oborů hodnot, schémat, omezení modelu, apod. Popis musí být natolik detailní, aby podle něj bylo možné experiment zopakovat (a to samozřejmě i bez toho, že by byly k dispozici příslušné soubory s modelem).<br />
<br />
=Results=<br />
==Single run==<br />
<br />
==Multi run==<br />
<br />
<br />
výpis výsledků, jejich analýza, interpretace, zhodnocení.<br />
<br />
=Discussion=<br />
jak se Vám podařilo definovaný problém vyřešit<br />
<br />
<br />
=Code=<br />
<br />
g<br />
[[User:Tros01|Tros01]] ([[User talk:Tros01|talk]]) 22:19, 19 January 2025 (CET)</div>Tros01http://www.simulace.info/index.php?title=Populating_the_database&diff=26526Populating the database2025-01-19T21:27:51Z<p>Tros01: /* Variables */</p>
<hr />
<div>Úvodní odstavec<br />
<br />
=Problem definition=<br />
==Why?==<br />
Lets say that I have a database containing prepared activities and educational content for boy scouts group. Its purpose is to serve as a source of inspiration and eventually of collection of high quality content appropriate for kids during our weekly meetings or other occasions. From which source should be easy to get precisely only the desired results based on defined properties on each activity (eg. time needed for preparation, minimal number of players, etc.)<br />
<br />
BUT actually its currently more like a proof of concept and not a really operational tool. So accordingly there aren't yet any real records to speak about.<br />
This very early stage of development is exactly the reason why I think it is reasonable to think about how will the database be populated with data. As this will be crucial for its future usability and success. Therefore, the simulation should focus on modeling this data population process.<br />
==What?==<br />
To be precise, the simulation will be concerned with user behavior and related volume of stored records.<br />
<br />
It is important to say that user interface for reading is only the default web gui of the database itself (Neo4j), so the users will have to use the Cypher query language. So after they go through such a way to access the records, there better be some decent amount of useful ones in the database. This is because otherwise their whole effort would be pointless and the user would be discouraged from using the database again.<br />
<br />
Creating the records on the other hand will be easy and accessible as much as possible (user writes to google document in specified folder and with specified structure which enables then loading it programmaticaly into the database). This ease of creation is key to encouraging consistent contributions.<br />
<br />
And here comes the question whether this "natural" way of data population is enough, or rather how long will it take for the database to be able to provide satisfactory results for the user in majority of the cases and as such could be called a useful tool. If the time required would be too long, the users could lose interest of even contributing new content .<br />
Therefore, the simulation will model the rate of content creation and the subsequent impact on database searchability and usability.<br />
<br />
Additionally will be also evaluated the "batch population approach" to see weather it is worth considering to implement. This will involve creating a model of user behavior and content creation, simulating different scenarios, and analyzing the results.<br />
==Objectives==<br />
This simulation aims to predict the growth of the database, determine the feasibility of the current data population strategy and evaluate the alternative.<br />
<br />
#Predict the time needed to reach a critical mass of data sufficient for effective use.<br />
#Evaluate the effectiveness of the current data population method relatively to alternative.<br />
<br />
=Method=<br />
==Agent-based model==<br />
The core method used for this simulation is agent-based modeling (ABM). This approach was selected because it aligns well with the nature of the problem, which involves multiple individual users (agents) interacting with a shared environment (the database). Specifically, it enabled me to simulate:<br />
<br />
*Individual User Behaviors: Each agent acts independently, deciding whether to search the database, create a new record, or improve existing ones, based on their local information and probabilities.<br />
*Heterogeneity (Limited): While the agents initially are identical, they change during the simulation based on their interactions with the database.<br />
*Emergent System Behavior: The overall growth and usability of the database is not programmed directly, but emerges from the accumulation of individual actions.<br />
<br />
Alternatively the system dynamics or simple math equations could be used but neither of them would be more fitting for this usecase.<br />
While system dynamics could model the overall growth of the database as a system, it would not provide the same level of detail regarding individual user actions. System dynamics works well when dealing with aggregate levels and rates of change but isn't great for capturing how each agent behaviour individually impacts the system.<br />
<br />
Just as the equations could model a simplified database growth equation, but it would be extremely difficult to derive a model which includes agents success/fail feedback, record improvement and cooldown and thus it was not considered as applicable for this problem.<br />
==Julia==<br />
Because the ABM approach was chosen the NetLogo was concidered as environment for implemantation of the simulation, but also was the language Julia as it is also often used for simulations. In the end the Julia was chosen because of its more general usability and therefore more usecases when learned to use.<br />
<br />
diskuse možností řešení, výběr metody a prostředku (metod a prostředků) řešení, zdůvodnění výběru (jinými slovy, proč to chcete řešit tak, jak to chcete řešit, jaké jsou jiné alternativy a proč je ta Vámi zvolená pro tuto úlohu nejvhodnější)<br />
<br />
=Model=<br />
<br />
==Entities==<br />
;Database (db):<br />
A dictionary storing Record objects, categorized by integers representing different activity categories.<br />
*The keys of the dictionary are integers representing category id.<br />
*Each category is associated with a vector (array) of Record objects.<br />
*Initially, each category has an empty vector, which can be populated by new records.<br />
<br />
;Record:<br />
A struct containing:<br />
*id (Integer): A unique identifier for the record, auto-incrementing with each creation.<br />
*quality (Float64): Represents the perceived quality or usability of the record.<br />
<br />
;Agent:<br />
A struct representing a user of the database.<br />
*probabilityToSearch (Float64): The agent's current probability of finding a useful record, it is based on past success of the agent when searching the db. This parameter influences agent's decision whether to search the db or not.<br />
*used (Dict{Int, Vector{Int}}): A dictionary that stores which record IDs have been used by agent and in which week the record has been used, so it won't be used by the same agent during a given cooldown period. Keys are record ids and values are vectors containing week integers in which the record has been used.<br />
<br />
==Variables==<br />
;NUM_AGENTS: <br />
: Integer representing the number of agents (users) participating in the simulation. Value is fixed at 3.<br />
;BATCH_UPLOAD_SIZES:<br />
: Vector of integers representing different sizes of initial record batches uploaded to the database. The values used in simulation are [0, 10].<br />
;initialQualityDist: <br />
: A lognormal distribution (LogNormal(3, 2)) used to generate the initial quality of new records. The mean is set to 3, and the standard deviation is set to 2, meaning the typical quality of created record will be around 3, but there could be some with higher or lower.<br />
;qualityImprovementProb<br />
: Float64 representing the probability that an agent will improve a record's quality after using it. Value is fixed at 0.7.<br />
;recordCreationProb<br />
: Float64 representing the probability that an agent creates a new record when they are preparing an activity and decide not to search the database. Value is fixed at 0.3.<br />
;categories<br />
: Vector of integer representing the category ids of the db records. The vector is generated as range from 1 to 20, [1:20;].<br />
;targetSuccessfulness<br />
: Float64 value, which represents minimum success rate, that needs to be reached for the database to be considered "useful" in a long term. Value is 0.75.<br />
;nSuccessfullFromEpisode<br />
: An integer number representing how many successful searches per episode of the simulation have to occur in order for it to be considered "useful". Value is 4.<br />
;episodeLength<br />
: Integer which represents length of a one "episode" within the simulation, which in this case is a sequence of weeks for which the success rate of the db will be tested if it met required conditions. Value is set to 6, this means 6 weeks.<br />
<br />
==Flow==<br />
<br />
Detailní popis modelu, včetně parametrů, oborů hodnot, schémat, omezení modelu, apod. Popis musí být natolik detailní, aby podle něj bylo možné experiment zopakovat (a to samozřejmě i bez toho, že by byly k dispozici příslušné soubory s modelem).<br />
<br />
=Results=<br />
==Single run==<br />
<br />
==Multi run==<br />
<br />
<br />
výpis výsledků, jejich analýza, interpretace, zhodnocení.<br />
<br />
=Discussion=<br />
jak se Vám podařilo definovaný problém vyřešit<br />
<br />
<br />
=Code=<br />
<br />
g<br />
[[User:Tros01|Tros01]] ([[User talk:Tros01|talk]]) 22:19, 19 January 2025 (CET)</div>Tros01http://www.simulace.info/index.php?title=Populating_the_database&diff=26525Populating the database2025-01-19T21:27:12Z<p>Tros01: /* Variables */</p>
<hr />
<div>Úvodní odstavec<br />
<br />
=Problem definition=<br />
==Why?==<br />
Lets say that I have a database containing prepared activities and educational content for boy scouts group. Its purpose is to serve as a source of inspiration and eventually of collection of high quality content appropriate for kids during our weekly meetings or other occasions. From which source should be easy to get precisely only the desired results based on defined properties on each activity (eg. time needed for preparation, minimal number of players, etc.)<br />
<br />
BUT actually its currently more like a proof of concept and not a really operational tool. So accordingly there aren't yet any real records to speak about.<br />
This very early stage of development is exactly the reason why I think it is reasonable to think about how will the database be populated with data. As this will be crucial for its future usability and success. Therefore, the simulation should focus on modeling this data population process.<br />
==What?==<br />
To be precise, the simulation will be concerned with user behavior and related volume of stored records.<br />
<br />
It is important to say that user interface for reading is only the default web gui of the database itself (Neo4j), so the users will have to use the Cypher query language. So after they go through such a way to access the records, there better be some decent amount of useful ones in the database. This is because otherwise their whole effort would be pointless and the user would be discouraged from using the database again.<br />
<br />
Creating the records on the other hand will be easy and accessible as much as possible (user writes to google document in specified folder and with specified structure which enables then loading it programmaticaly into the database). This ease of creation is key to encouraging consistent contributions.<br />
<br />
And here comes the question whether this "natural" way of data population is enough, or rather how long will it take for the database to be able to provide satisfactory results for the user in majority of the cases and as such could be called a useful tool. If the time required would be too long, the users could lose interest of even contributing new content .<br />
Therefore, the simulation will model the rate of content creation and the subsequent impact on database searchability and usability.<br />
<br />
Additionally will be also evaluated the "batch population approach" to see weather it is worth considering to implement. This will involve creating a model of user behavior and content creation, simulating different scenarios, and analyzing the results.<br />
==Objectives==<br />
This simulation aims to predict the growth of the database, determine the feasibility of the current data population strategy and evaluate the alternative.<br />
<br />
#Predict the time needed to reach a critical mass of data sufficient for effective use.<br />
#Evaluate the effectiveness of the current data population method relatively to alternative.<br />
<br />
=Method=<br />
==Agent-based model==<br />
The core method used for this simulation is agent-based modeling (ABM). This approach was selected because it aligns well with the nature of the problem, which involves multiple individual users (agents) interacting with a shared environment (the database). Specifically, it enabled me to simulate:<br />
<br />
*Individual User Behaviors: Each agent acts independently, deciding whether to search the database, create a new record, or improve existing ones, based on their local information and probabilities.<br />
*Heterogeneity (Limited): While the agents initially are identical, they change during the simulation based on their interactions with the database.<br />
*Emergent System Behavior: The overall growth and usability of the database is not programmed directly, but emerges from the accumulation of individual actions.<br />
<br />
Alternatively the system dynamics or simple math equations could be used but neither of them would be more fitting for this usecase.<br />
While system dynamics could model the overall growth of the database as a system, it would not provide the same level of detail regarding individual user actions. System dynamics works well when dealing with aggregate levels and rates of change but isn't great for capturing how each agent behaviour individually impacts the system.<br />
<br />
Just as the equations could model a simplified database growth equation, but it would be extremely difficult to derive a model which includes agents success/fail feedback, record improvement and cooldown and thus it was not considered as applicable for this problem.<br />
==Julia==<br />
Because the ABM approach was chosen the NetLogo was concidered as environment for implemantation of the simulation, but also was the language Julia as it is also often used for simulations. In the end the Julia was chosen because of its more general usability and therefore more usecases when learned to use.<br />
<br />
diskuse možností řešení, výběr metody a prostředku (metod a prostředků) řešení, zdůvodnění výběru (jinými slovy, proč to chcete řešit tak, jak to chcete řešit, jaké jsou jiné alternativy a proč je ta Vámi zvolená pro tuto úlohu nejvhodnější)<br />
<br />
=Model=<br />
<br />
==Entities==<br />
;Database (db):<br />
A dictionary storing Record objects, categorized by integers representing different activity categories.<br />
*The keys of the dictionary are integers representing category id.<br />
*Each category is associated with a vector (array) of Record objects.<br />
*Initially, each category has an empty vector, which can be populated by new records.<br />
<br />
;Record:<br />
A struct containing:<br />
*id (Integer): A unique identifier for the record, auto-incrementing with each creation.<br />
*quality (Float64): Represents the perceived quality or usability of the record.<br />
<br />
;Agent:<br />
A struct representing a user of the database.<br />
*probabilityToSearch (Float64): The agent's current probability of finding a useful record, it is based on past success of the agent when searching the db. This parameter influences agent's decision whether to search the db or not.<br />
*used (Dict{Int, Vector{Int}}): A dictionary that stores which record IDs have been used by agent and in which week the record has been used, so it won't be used by the same agent during a given cooldown period. Keys are record ids and values are vectors containing week integers in which the record has been used.<br />
<br />
==Variables==<br />
;NUM_AGENTS: <br />
Integer representing the number of agents (users) participating in the simulation. Value is fixed at 3.<br />
;BATCH_UPLOAD_SIZES:<br />
Vector of integers representing different sizes of initial record batches uploaded to the database. The values used in simulation are [0, 10].<br />
;initialQualityDist: <br />
A lognormal distribution (LogNormal(3, 2)) used to generate the initial quality of new records. The mean is set to 3, and the standard deviation is set to 2, meaning the typical quality of created record will be around 3, but there could be some with higher or lower.<br />
;qualityImprovementProb<br />
: Float64 representing the probability that an agent will improve a record's quality after using it. Value is fixed at 0.7.<br />
;recordCreationProb<br />
: Float64 representing the probability that an agent creates a new record when they are preparing an activity and decide not to search the database. Value is fixed at 0.3.<br />
;categories<br />
: Vector of integer representing the category ids of the db records. The vector is generated as range from 1 to 20, [1:20;].<br />
<br />
targetSuccessfulness: Float64 value, which represents minimum success rate, that needs to be reached for the database to be considered "useful" in a long term. Value is 0.75.<br />
<br />
nSuccessfullFromEpisode: An integer number representing how many successful searches per episode of the simulation have to occur in order for it to be considered "useful". Value is 4.<br />
<br />
episodeLength: Integer which represents length of a one "episode" within the simulation, which in this case is a sequence of weeks for which the success rate of the db will be tested if it met required conditions. Value is set to 6, this means 6 weeks.<br />
<br />
==Flow==<br />
<br />
Detailní popis modelu, včetně parametrů, oborů hodnot, schémat, omezení modelu, apod. Popis musí být natolik detailní, aby podle něj bylo možné experiment zopakovat (a to samozřejmě i bez toho, že by byly k dispozici příslušné soubory s modelem).<br />
<br />
=Results=<br />
==Single run==<br />
<br />
==Multi run==<br />
<br />
<br />
výpis výsledků, jejich analýza, interpretace, zhodnocení.<br />
<br />
=Discussion=<br />
jak se Vám podařilo definovaný problém vyřešit<br />
<br />
<br />
=Code=<br />
<br />
g<br />
[[User:Tros01|Tros01]] ([[User talk:Tros01|talk]]) 22:19, 19 January 2025 (CET)</div>Tros01http://www.simulace.info/index.php?title=Populating_the_database&diff=26524Populating the database2025-01-19T21:25:13Z<p>Tros01: /* Entities */</p>
<hr />
<div>Úvodní odstavec<br />
<br />
=Problem definition=<br />
==Why?==<br />
Lets say that I have a database containing prepared activities and educational content for boy scouts group. Its purpose is to serve as a source of inspiration and eventually of collection of high quality content appropriate for kids during our weekly meetings or other occasions. From which source should be easy to get precisely only the desired results based on defined properties on each activity (eg. time needed for preparation, minimal number of players, etc.)<br />
<br />
BUT actually its currently more like a proof of concept and not a really operational tool. So accordingly there aren't yet any real records to speak about.<br />
This very early stage of development is exactly the reason why I think it is reasonable to think about how will the database be populated with data. As this will be crucial for its future usability and success. Therefore, the simulation should focus on modeling this data population process.<br />
==What?==<br />
To be precise, the simulation will be concerned with user behavior and related volume of stored records.<br />
<br />
It is important to say that user interface for reading is only the default web gui of the database itself (Neo4j), so the users will have to use the Cypher query language. So after they go through such a way to access the records, there better be some decent amount of useful ones in the database. This is because otherwise their whole effort would be pointless and the user would be discouraged from using the database again.<br />
<br />
Creating the records on the other hand will be easy and accessible as much as possible (user writes to google document in specified folder and with specified structure which enables then loading it programmaticaly into the database). This ease of creation is key to encouraging consistent contributions.<br />
<br />
And here comes the question whether this "natural" way of data population is enough, or rather how long will it take for the database to be able to provide satisfactory results for the user in majority of the cases and as such could be called a useful tool. If the time required would be too long, the users could lose interest of even contributing new content .<br />
Therefore, the simulation will model the rate of content creation and the subsequent impact on database searchability and usability.<br />
<br />
Additionally will be also evaluated the "batch population approach" to see weather it is worth considering to implement. This will involve creating a model of user behavior and content creation, simulating different scenarios, and analyzing the results.<br />
==Objectives==<br />
This simulation aims to predict the growth of the database, determine the feasibility of the current data population strategy and evaluate the alternative.<br />
<br />
#Predict the time needed to reach a critical mass of data sufficient for effective use.<br />
#Evaluate the effectiveness of the current data population method relatively to alternative.<br />
<br />
=Method=<br />
==Agent-based model==<br />
The core method used for this simulation is agent-based modeling (ABM). This approach was selected because it aligns well with the nature of the problem, which involves multiple individual users (agents) interacting with a shared environment (the database). Specifically, it enabled me to simulate:<br />
<br />
*Individual User Behaviors: Each agent acts independently, deciding whether to search the database, create a new record, or improve existing ones, based on their local information and probabilities.<br />
*Heterogeneity (Limited): While the agents initially are identical, they change during the simulation based on their interactions with the database.<br />
*Emergent System Behavior: The overall growth and usability of the database is not programmed directly, but emerges from the accumulation of individual actions.<br />
<br />
Alternatively the system dynamics or simple math equations could be used but neither of them would be more fitting for this usecase.<br />
While system dynamics could model the overall growth of the database as a system, it would not provide the same level of detail regarding individual user actions. System dynamics works well when dealing with aggregate levels and rates of change but isn't great for capturing how each agent behaviour individually impacts the system.<br />
<br />
Just as the equations could model a simplified database growth equation, but it would be extremely difficult to derive a model which includes agents success/fail feedback, record improvement and cooldown and thus it was not considered as applicable for this problem.<br />
==Julia==<br />
Because the ABM approach was chosen the NetLogo was concidered as environment for implemantation of the simulation, but also was the language Julia as it is also often used for simulations. In the end the Julia was chosen because of its more general usability and therefore more usecases when learned to use.<br />
<br />
diskuse možností řešení, výběr metody a prostředku (metod a prostředků) řešení, zdůvodnění výběru (jinými slovy, proč to chcete řešit tak, jak to chcete řešit, jaké jsou jiné alternativy a proč je ta Vámi zvolená pro tuto úlohu nejvhodnější)<br />
<br />
=Model=<br />
<br />
==Entities==<br />
;Database (db):<br />
A dictionary storing Record objects, categorized by integers representing different activity categories.<br />
*The keys of the dictionary are integers representing category id.<br />
*Each category is associated with a vector (array) of Record objects.<br />
*Initially, each category has an empty vector, which can be populated by new records.<br />
<br />
;Record:<br />
A struct containing:<br />
*id (Integer): A unique identifier for the record, auto-incrementing with each creation.<br />
*quality (Float64): Represents the perceived quality or usability of the record.<br />
<br />
;Agent:<br />
A struct representing a user of the database.<br />
*probabilityToSearch (Float64): The agent's current probability of finding a useful record, it is based on past success of the agent when searching the db. This parameter influences agent's decision whether to search the db or not.<br />
*used (Dict{Int, Vector{Int}}): A dictionary that stores which record IDs have been used by agent and in which week the record has been used, so it won't be used by the same agent during a given cooldown period. Keys are record ids and values are vectors containing week integers in which the record has been used.<br />
<br />
==Variables==<br />
<br />
==Flow==<br />
<br />
Detailní popis modelu, včetně parametrů, oborů hodnot, schémat, omezení modelu, apod. Popis musí být natolik detailní, aby podle něj bylo možné experiment zopakovat (a to samozřejmě i bez toho, že by byly k dispozici příslušné soubory s modelem).<br />
<br />
=Results=<br />
==Single run==<br />
<br />
==Multi run==<br />
<br />
<br />
výpis výsledků, jejich analýza, interpretace, zhodnocení.<br />
<br />
=Discussion=<br />
jak se Vám podařilo definovaný problém vyřešit<br />
<br />
<br />
=Code=<br />
<br />
g<br />
[[User:Tros01|Tros01]] ([[User talk:Tros01|talk]]) 22:19, 19 January 2025 (CET)</div>Tros01http://www.simulace.info/index.php?title=Populating_the_database&diff=26523Populating the database2025-01-19T21:23:47Z<p>Tros01: </p>
<hr />
<div>Úvodní odstavec<br />
<br />
=Problem definition=<br />
==Why?==<br />
Lets say that I have a database containing prepared activities and educational content for boy scouts group. Its purpose is to serve as a source of inspiration and eventually of collection of high quality content appropriate for kids during our weekly meetings or other occasions. From which source should be easy to get precisely only the desired results based on defined properties on each activity (eg. time needed for preparation, minimal number of players, etc.)<br />
<br />
BUT actually its currently more like a proof of concept and not a really operational tool. So accordingly there aren't yet any real records to speak about.<br />
This very early stage of development is exactly the reason why I think it is reasonable to think about how will the database be populated with data. As this will be crucial for its future usability and success. Therefore, the simulation should focus on modeling this data population process.<br />
==What?==<br />
To be precise, the simulation will be concerned with user behavior and related volume of stored records.<br />
<br />
It is important to say that user interface for reading is only the default web gui of the database itself (Neo4j), so the users will have to use the Cypher query language. So after they go through such a way to access the records, there better be some decent amount of useful ones in the database. This is because otherwise their whole effort would be pointless and the user would be discouraged from using the database again.<br />
<br />
Creating the records on the other hand will be easy and accessible as much as possible (user writes to google document in specified folder and with specified structure which enables then loading it programmaticaly into the database). This ease of creation is key to encouraging consistent contributions.<br />
<br />
And here comes the question whether this "natural" way of data population is enough, or rather how long will it take for the database to be able to provide satisfactory results for the user in majority of the cases and as such could be called a useful tool. If the time required would be too long, the users could lose interest of even contributing new content .<br />
Therefore, the simulation will model the rate of content creation and the subsequent impact on database searchability and usability.<br />
<br />
Additionally will be also evaluated the "batch population approach" to see weather it is worth considering to implement. This will involve creating a model of user behavior and content creation, simulating different scenarios, and analyzing the results.<br />
==Objectives==<br />
This simulation aims to predict the growth of the database, determine the feasibility of the current data population strategy and evaluate the alternative.<br />
<br />
#Predict the time needed to reach a critical mass of data sufficient for effective use.<br />
#Evaluate the effectiveness of the current data population method relatively to alternative.<br />
<br />
=Method=<br />
==Agent-based model==<br />
The core method used for this simulation is agent-based modeling (ABM). This approach was selected because it aligns well with the nature of the problem, which involves multiple individual users (agents) interacting with a shared environment (the database). Specifically, it enabled me to simulate:<br />
<br />
*Individual User Behaviors: Each agent acts independently, deciding whether to search the database, create a new record, or improve existing ones, based on their local information and probabilities.<br />
*Heterogeneity (Limited): While the agents initially are identical, they change during the simulation based on their interactions with the database.<br />
*Emergent System Behavior: The overall growth and usability of the database is not programmed directly, but emerges from the accumulation of individual actions.<br />
<br />
Alternatively the system dynamics or simple math equations could be used but neither of them would be more fitting for this usecase.<br />
While system dynamics could model the overall growth of the database as a system, it would not provide the same level of detail regarding individual user actions. System dynamics works well when dealing with aggregate levels and rates of change but isn't great for capturing how each agent behaviour individually impacts the system.<br />
<br />
Just as the equations could model a simplified database growth equation, but it would be extremely difficult to derive a model which includes agents success/fail feedback, record improvement and cooldown and thus it was not considered as applicable for this problem.<br />
==Julia==<br />
Because the ABM approach was chosen the NetLogo was concidered as environment for implemantation of the simulation, but also was the language Julia as it is also often used for simulations. In the end the Julia was chosen because of its more general usability and therefore more usecases when learned to use.<br />
<br />
diskuse možností řešení, výběr metody a prostředku (metod a prostředků) řešení, zdůvodnění výběru (jinými slovy, proč to chcete řešit tak, jak to chcete řešit, jaké jsou jiné alternativy a proč je ta Vámi zvolená pro tuto úlohu nejvhodnější)<br />
<br />
=Model=<br />
<br />
==Entities==<br />
;Database (db):<br />
*A dictionary storing Record objects, categorized by integers representing different activity categories.<br />
*The keys of the dictionary are integers representing category id.<br />
*Each category is associated with a vector (array) of Record objects.<br />
*Initially, each category has an empty vector, which can be populated by new records.<br />
<br />
;Record:<br />
A struct containing:<br />
id (Integer): A unique identifier for the record, auto-incrementing with each creation.<br />
quality (Float64): Represents the perceived quality or usability of the record.<br />
<br />
;Agent:<br />
A struct representing a user of the database.<br />
past_success_rate (Float64): The agent's current probability of finding a useful record, it is based on past success of the agent when searching the db. This parameter influences agent's decision whether to search the db or not.<br />
used (Dict{Int, Vector{Int}}): A dictionary that stores which record IDs have been used by agent and in which week the record has been used, so it won't be used by the same agent during a given cooldown period. Keys are record ids and values are vectors containing week integers in which the record has been used.<br />
<br />
==Variables==<br />
<br />
==Flow==<br />
<br />
Detailní popis modelu, včetně parametrů, oborů hodnot, schémat, omezení modelu, apod. Popis musí být natolik detailní, aby podle něj bylo možné experiment zopakovat (a to samozřejmě i bez toho, že by byly k dispozici příslušné soubory s modelem).<br />
<br />
=Results=<br />
==Single run==<br />
<br />
==Multi run==<br />
<br />
<br />
výpis výsledků, jejich analýza, interpretace, zhodnocení.<br />
<br />
=Discussion=<br />
jak se Vám podařilo definovaný problém vyřešit<br />
<br />
<br />
=Code=<br />
<br />
g<br />
[[User:Tros01|Tros01]] ([[User talk:Tros01|talk]]) 22:19, 19 January 2025 (CET)</div>Tros01http://www.simulace.info/index.php?title=Populating_the_database&diff=26522Populating the database2025-01-19T21:20:16Z<p>Tros01: /* Code */</p>
<hr />
<div>Úvodní odstavec<br />
<br />
=Problem definition=<br />
==Why?==<br />
Lets say that I have a database containing prepared activities and educational content for boy scouts group. Its purpose is to serve as a source of inspiration and eventually of collection of high quality content appropriate for kids during our weekly meetings or other occasions. From which source should be easy to get precisely only the desired results based on defined properties on each activity (eg. time needed for preparation, minimal number of players, etc.)<br />
<br />
BUT actually its currently more like a proof of concept and not a really operational tool. So accordingly there aren't yet any real records to speak about.<br />
This very early stage of development is exactly the reason why I think it is reasonable to think about how will the database be populated with data. As this will be crucial for its future usability and success. Therefore, the simulation should focus on modeling this data population process.<br />
==What?==<br />
To be precise, the simulation will be concerned with user behavior and related volume of stored records.<br />
<br />
It is important to say that user interface for reading is only the default web gui of the database itself (Neo4j), so the users will have to use the Cypher query language. So after they go through such a way to access the records, there better be some decent amount of useful ones in the database. This is because otherwise their whole effort would be pointless and the user would be discouraged from using the database again.<br />
<br />
Creating the records on the other hand will be easy and accessible as much as possible (user writes to google document in specified folder and with specified structure which enables then loading it programmaticaly into the database). This ease of creation is key to encouraging consistent contributions.<br />
<br />
And here comes the question whether this "natural" way of data population is enough, or rather how long will it take for the database to be able to provide satisfactory results for the user in majority of the cases and as such could be called a useful tool. If the time required would be too long, the users could lose interest of even contributing new content .<br />
Therefore, the simulation will model the rate of content creation and the subsequent impact on database searchability and usability.<br />
<br />
Additionally will be also evaluated the "batch population approach" to see weather it is worth considering to implement. This will involve creating a model of user behavior and content creation, simulating different scenarios, and analyzing the results.<br />
==Objectives==<br />
This simulation aims to predict the growth of the database, determine the feasibility of the current data population strategy and evaluate the alternative.<br />
<br />
#Predict the time needed to reach a critical mass of data sufficient for effective use.<br />
#Evaluate the effectiveness of the current data population method relatively to alternative.<br />
<br />
=Method=<br />
==Agent-based model==<br />
The core method used for this simulation is agent-based modeling (ABM). This approach was selected because it aligns well with the nature of the problem, which involves multiple individual users (agents) interacting with a shared environment (the database). Specifically, it enabled me to simulate:<br />
<br />
*Individual User Behaviors: Each agent acts independently, deciding whether to search the database, create a new record, or improve existing ones, based on their local information and probabilities.<br />
*Heterogeneity (Limited): While the agents initially are identical, they change during the simulation based on their interactions with the database.<br />
*Emergent System Behavior: The overall growth and usability of the database is not programmed directly, but emerges from the accumulation of individual actions.<br />
<br />
Alternatively the system dynamics or simple math equations could be used but neither of them would be more fitting for this usecase.<br />
While system dynamics could model the overall growth of the database as a system, it would not provide the same level of detail regarding individual user actions. System dynamics works well when dealing with aggregate levels and rates of change but isn't great for capturing how each agent behaviour individually impacts the system.<br />
<br />
Just as the equations could model a simplified database growth equation, but it would be extremely difficult to derive a model which includes agents success/fail feedback, record improvement and cooldown and thus it was not considered as applicable for this problem.<br />
==Julia==<br />
Because the ABM approach was chosen the NetLogo was concidered as environment for implemantation of the simulation, but also was the language Julia as it is also often used for simulations. In the end the Julia was chosen because of its more general usability and therefore more usecases when learned to use.<br />
<br />
diskuse možností řešení, výběr metody a prostředku (metod a prostředků) řešení, zdůvodnění výběru (jinými slovy, proč to chcete řešit tak, jak to chcete řešit, jaké jsou jiné alternativy a proč je ta Vámi zvolená pro tuto úlohu nejvhodnější)<br />
<br />
=Model=<br />
<br />
==Entities==<br />
<br />
==Variables==<br />
<br />
==Flow==<br />
<br />
Detailní popis modelu, včetně parametrů, oborů hodnot, schémat, omezení modelu, apod. Popis musí být natolik detailní, aby podle něj bylo možné experiment zopakovat (a to samozřejmě i bez toho, že by byly k dispozici příslušné soubory s modelem).<br />
<br />
=Results=<br />
==Single run==<br />
<br />
==Multi run==<br />
<br />
<br />
výpis výsledků, jejich analýza, interpretace, zhodnocení.<br />
<br />
=Discussion=<br />
jak se Vám podařilo definovaný problém vyřešit<br />
<br />
<br />
=Code=<br />
<br />
g<br />
[[User:Tros01|Tros01]] ([[User talk:Tros01|talk]]) 22:19, 19 January 2025 (CET)</div>Tros01http://www.simulace.info/index.php?title=Populating_the_database&diff=26521Populating the database2025-01-19T21:19:58Z<p>Tros01: </p>
<hr />
<div>Úvodní odstavec<br />
<br />
=Problem definition=<br />
==Why?==<br />
Lets say that I have a database containing prepared activities and educational content for boy scouts group. Its purpose is to serve as a source of inspiration and eventually of collection of high quality content appropriate for kids during our weekly meetings or other occasions. From which source should be easy to get precisely only the desired results based on defined properties on each activity (eg. time needed for preparation, minimal number of players, etc.)<br />
<br />
BUT actually its currently more like a proof of concept and not a really operational tool. So accordingly there aren't yet any real records to speak about.<br />
This very early stage of development is exactly the reason why I think it is reasonable to think about how will the database be populated with data. As this will be crucial for its future usability and success. Therefore, the simulation should focus on modeling this data population process.<br />
==What?==<br />
To be precise, the simulation will be concerned with user behavior and related volume of stored records.<br />
<br />
It is important to say that user interface for reading is only the default web gui of the database itself (Neo4j), so the users will have to use the Cypher query language. So after they go through such a way to access the records, there better be some decent amount of useful ones in the database. This is because otherwise their whole effort would be pointless and the user would be discouraged from using the database again.<br />
<br />
Creating the records on the other hand will be easy and accessible as much as possible (user writes to google document in specified folder and with specified structure which enables then loading it programmaticaly into the database). This ease of creation is key to encouraging consistent contributions.<br />
<br />
And here comes the question whether this "natural" way of data population is enough, or rather how long will it take for the database to be able to provide satisfactory results for the user in majority of the cases and as such could be called a useful tool. If the time required would be too long, the users could lose interest of even contributing new content .<br />
Therefore, the simulation will model the rate of content creation and the subsequent impact on database searchability and usability.<br />
<br />
Additionally will be also evaluated the "batch population approach" to see weather it is worth considering to implement. This will involve creating a model of user behavior and content creation, simulating different scenarios, and analyzing the results.<br />
==Objectives==<br />
This simulation aims to predict the growth of the database, determine the feasibility of the current data population strategy and evaluate the alternative.<br />
<br />
#Predict the time needed to reach a critical mass of data sufficient for effective use.<br />
#Evaluate the effectiveness of the current data population method relatively to alternative.<br />
<br />
=Method=<br />
==Agent-based model==<br />
The core method used for this simulation is agent-based modeling (ABM). This approach was selected because it aligns well with the nature of the problem, which involves multiple individual users (agents) interacting with a shared environment (the database). Specifically, it enabled me to simulate:<br />
<br />
*Individual User Behaviors: Each agent acts independently, deciding whether to search the database, create a new record, or improve existing ones, based on their local information and probabilities.<br />
*Heterogeneity (Limited): While the agents initially are identical, they change during the simulation based on their interactions with the database.<br />
*Emergent System Behavior: The overall growth and usability of the database is not programmed directly, but emerges from the accumulation of individual actions.<br />
<br />
Alternatively the system dynamics or simple math equations could be used but neither of them would be more fitting for this usecase.<br />
While system dynamics could model the overall growth of the database as a system, it would not provide the same level of detail regarding individual user actions. System dynamics works well when dealing with aggregate levels and rates of change but isn't great for capturing how each agent behaviour individually impacts the system.<br />
<br />
Just as the equations could model a simplified database growth equation, but it would be extremely difficult to derive a model which includes agents success/fail feedback, record improvement and cooldown and thus it was not considered as applicable for this problem.<br />
==Julia==<br />
Because the ABM approach was chosen the NetLogo was concidered as environment for implemantation of the simulation, but also was the language Julia as it is also often used for simulations. In the end the Julia was chosen because of its more general usability and therefore more usecases when learned to use.<br />
<br />
diskuse možností řešení, výběr metody a prostředku (metod a prostředků) řešení, zdůvodnění výběru (jinými slovy, proč to chcete řešit tak, jak to chcete řešit, jaké jsou jiné alternativy a proč je ta Vámi zvolená pro tuto úlohu nejvhodnější)<br />
<br />
=Model=<br />
<br />
==Entities==<br />
<br />
==Variables==<br />
<br />
==Flow==<br />
<br />
Detailní popis modelu, včetně parametrů, oborů hodnot, schémat, omezení modelu, apod. Popis musí být natolik detailní, aby podle něj bylo možné experiment zopakovat (a to samozřejmě i bez toho, že by byly k dispozici příslušné soubory s modelem).<br />
<br />
=Results=<br />
==Single run==<br />
<br />
==Multi run==<br />
<br />
<br />
výpis výsledků, jejich analýza, interpretace, zhodnocení.<br />
<br />
=Discussion=<br />
jak se Vám podařilo definovaný problém vyřešit<br />
<br />
<br />
=Code=<br />
<br />
<br />
[[User:Tros01|Tros01]] ([[User talk:Tros01|talk]]) 22:19, 19 January 2025 (CET)</div>Tros01http://www.simulace.info/index.php?title=Populating_the_database&diff=26520Populating the database2025-01-19T21:19:21Z<p>Tros01: </p>
<hr />
<div>Úvodní odstavec<br />
<br />
=Problem definition=<br />
==Why?==<br />
Lets say that I have a database containing prepared activities and educational content for boy scouts group. Its purpose is to serve as a source of inspiration and eventually of collection of high quality content appropriate for kids during our weekly meetings or other occasions. From which source should be easy to get precisely only the desired results based on defined properties on each activity (eg. time needed for preparation, minimal number of players, etc.)<br />
<br />
BUT actually its currently more like a proof of concept and not a really operational tool. So accordingly there aren't yet any real records to speak about.<br />
This very early stage of development is exactly the reason why I think it is reasonable to think about how will the database be populated with data. As this will be crucial for its future usability and success. Therefore, the simulation should focus on modeling this data population process.<br />
==What?==<br />
To be precise, the simulation will be concerned with user behavior and related volume of stored records.<br />
<br />
It is important to say that user interface for reading is only the default web gui of the database itself (Neo4j), so the users will have to use the Cypher query language. So after they go through such a way to access the records, there better be some decent amount of useful ones in the database. This is because otherwise their whole effort would be pointless and the user would be discouraged from using the database again.<br />
<br />
Creating the records on the other hand will be easy and accessible as much as possible (user writes to google document in specified folder and with specified structure which enables then loading it programmaticaly into the database). This ease of creation is key to encouraging consistent contributions.<br />
<br />
And here comes the question whether this "natural" way of data population is enough, or rather how long will it take for the database to be able to provide satisfactory results for the user in majority of the cases and as such could be called a useful tool. If the time required would be too long, the users could lose interest of even contributing new content .<br />
Therefore, the simulation will model the rate of content creation and the subsequent impact on database searchability and usability.<br />
<br />
Additionally will be also evaluated the "batch population approach" to see weather it is worth considering to implement. This will involve creating a model of user behavior and content creation, simulating different scenarios, and analyzing the results.<br />
==Objectives==<br />
This simulation aims to predict the growth of the database, determine the feasibility of the current data population strategy and evaluate the alternative.<br />
<br />
#Predict the time needed to reach a critical mass of data sufficient for effective use.<br />
#Evaluate the effectiveness of the current data population method relatively to alternative.<br />
<br />
=Method=<br />
==Agent-based model==<br />
The core method used for this simulation is agent-based modeling (ABM). This approach was selected because it aligns well with the nature of the problem, which involves multiple individual users (agents) interacting with a shared environment (the database). Specifically, it enabled me to simulate:<br />
<br />
*Individual User Behaviors: Each agent acts independently, deciding whether to search the database, create a new record, or improve existing ones, based on their local information and probabilities.<br />
*Heterogeneity (Limited): While the agents initially are identical, they change during the simulation based on their interactions with the database.<br />
*Emergent System Behavior: The overall growth and usability of the database is not programmed directly, but emerges from the accumulation of individual actions.<br />
<br />
Alternatively the system dynamics or simple math equations could be used but neither of them would be more fitting for this usecase.<br />
While system dynamics could model the overall growth of the database as a system, it would not provide the same level of detail regarding individual user actions. System dynamics works well when dealing with aggregate levels and rates of change but isn't great for capturing how each agent behaviour individually impacts the system.<br />
<br />
Just as the equations could model a simplified database growth equation, but it would be extremely difficult to derive a model which includes agents success/fail feedback, record improvement and cooldown and thus it was not considered as applicable for this problem.<br />
==Julia==<br />
Because the ABM approach was chosen the NetLogo was concidered as environment for implemantation of the simulation, but also was the language Julia as it is also often used for simulations. In the end the Julia was chosen because of its more general usability and therefore more usecases when learned to use.<br />
<br />
diskuse možností řešení, výběr metody a prostředku (metod a prostředků) řešení, zdůvodnění výběru (jinými slovy, proč to chcete řešit tak, jak to chcete řešit, jaké jsou jiné alternativy a proč je ta Vámi zvolená pro tuto úlohu nejvhodnější)<br />
<br />
=Model=<br />
<br />
==Entities==<br />
<br />
==Variables==<br />
<br />
==Flow==<br />
<br />
Detailní popis modelu, včetně parametrů, oborů hodnot, schémat, omezení modelu, apod. Popis musí být natolik detailní, aby podle něj bylo možné experiment zopakovat (a to samozřejmě i bez toho, že by byly k dispozici příslušné soubory s modelem).<br />
<br />
=Results=<br />
==Single run==<br />
<br />
==Multi run==<br />
<br />
<br />
výpis výsledků, jejich analýza, interpretace, zhodnocení.<br />
<br />
=Discussion=<br />
jak se Vám podařilo definovaný problém vyřešit<br />
<br />
<br />
=Code=</div>Tros01http://www.simulace.info/index.php?title=Populating_the_database&diff=26519Populating the database2025-01-19T20:39:24Z<p>Tros01: Created page with "Úvodní odstavec =Problem definition= ==Why?== Lets say that I have a database containing prepared activities and educational content for boy scouts group. Its purpose is to..."</p>
<hr />
<div>Úvodní odstavec<br />
<br />
=Problem definition=<br />
==Why?==<br />
Lets say that I have a database containing prepared activities and educational content for boy scouts group. Its purpose is to serve as a source of inspiration and eventually of collection of high quality content appropriate for kids during our weekly meetings or other occasions. From which source should be easy to get precisely only the desired results based on defined properties on each activity (eg. time needed for preparation, minimal number of players, etc.)<br />
<br />
BUT actually its currently more like a proof of concept and not a really operational tool. So accordingly there aren't yet any real records to speak about.<br />
This very early stage of development is exactly the reason why I think it is reasonable to think about how will the database be populated with data. As this will be crucial for its future usability and success. Therefore, the simulation should focus on modeling this data population process.<br />
==What?==<br />
To be precise, the simulation will be concerned with user behavior and related volume of stored records.<br />
<br />
It is important to say that user interface for reading is only the default web gui of the database itself (Neo4j), so the users will have to use the Cypher query language. So after they go through such a way to access the records, there better be some decent amount of useful ones in the database. This is because otherwise their whole effort would be pointless and the user would be discouraged from using the database again.<br />
<br />
Creating the records on the other hand will be easy and accessible as much as possible (user writes to google document in specified folder and with specified structure which enables then loading it programmaticaly into the database). This ease of creation is key to encouraging consistent contributions.<br />
<br />
And here comes the question whether this "natural" way of data population is enough, or rather how long will it take for the database to be able to provide satisfactory results for the user in majority of the cases and as such could be called a useful tool. If the time required would be too long, the users could lose interest of even contributing new content .<br />
Therefore, the simulation will model the rate of content creation and the subsequent impact on database searchability and usability.<br />
<br />
Additionally will be also evaluated the "batch population approach" to see weather it is worth considering to implement. This will involve creating a model of user behavior and content creation, simulating different scenarios, and analyzing the results.<br />
==Objectives==<br />
This simulation aims to predict the growth of the database, determine the feasibility of the current data population strategy and evaluate the alternative.<br />
<br />
#Predict the time needed to reach a critical mass of data sufficient for effective use.<br />
#Evaluate the effectiveness of the current data population method relatively to alternative.<br />
<br />
=Method=<br />
==Agent-based model==<br />
<br />
==Julia==<br />
<br />
diskuse možností řešení, výběr metody a prostředku (metod a prostředků) řešení, zdůvodnění výběru (jinými slovy, proč to chcete řešit tak, jak to chcete řešit, jaké jsou jiné alternativy a proč je ta Vámi zvolená pro tuto úlohu nejvhodnější)<br />
<br />
=Model=<br />
<br />
==Entities==<br />
<br />
==Variables==<br />
<br />
==Flow==<br />
<br />
Detailní popis modelu, včetně parametrů, oborů hodnot, schémat, omezení modelu, apod. Popis musí být natolik detailní, aby podle něj bylo možné experiment zopakovat (a to samozřejmě i bez toho, že by byly k dispozici příslušné soubory s modelem).<br />
<br />
=Results=<br />
==Single run==<br />
<br />
==Multi run==<br />
<br />
<br />
výpis výsledků, jejich analýza, interpretace, zhodnocení.<br />
<br />
=Discussion=<br />
jak se Vám podařilo definovaný problém vyřešit<br />
<br />
<br />
=Code=<br />
[[File:Příklad.jpg]]</div>Tros01http://www.simulace.info/index.php?title=WS_2024/2025&diff=26518WS 2024/20252025-01-19T20:18:52Z<p>Tros01: </p>
<hr />
<div>Semestral papers from winter term 2023/2024. Please, put here links to the pages with your paper. First you need to have your [[Assignments WS 2024/2025|assignment approved]]<br><br />
<br />
==Simulations==<br />
<br />
--[[User:Filip Simulátor|Filip Simulátor]] ([[User talk:Filip Simulátor|talk]]) 21:37, 3 January 2025 (CET) Lightning Network Channel Dynamics Simulation (NetLogo): [[Lightning Network Channel Dynamics Simulation (NetLogo)]]<br />
<br />
--[[User:Matj27|Matj27]] ([[User talk:Matj27|talk]]) 16:06, 2 January 2025 (CET) Performance of Solar Power Plant Based on ERA5 Data: [[Performance of Solar Power Plant Based on ERA5 Data]]<br />
<br />
--[[User:Cesj05|Cesj05]] ([[User talk:Cesj05|talk]]) 11:05, 1 January 2025 (CET) Garden simulation:[[Garden simulation]]<br />
<br />
--[[User:Tara04|Tara04]] ([[User talk:Tara04|talk]]) 20:24, 9 January 2025 (CET) Hybrid Work Dynamics: [[Hybrid Work Dynamics]]<br />
<br />
--[[User:Omaj01|Omaj01]] ([[User talk:Omaj01|talk]]) 20:55, 9 January 2025 (CET) Simulation of pension reform in the Czech Republic: Analysis of long-term sustainability: [[Pension System Czech Republic]]<br />
<br />
-- [[User:Sim timm03|Sim timm03]] ([[User talk:Sim timm03|talk]]) 19:36, 10 January 2025 (CET) Traffic Accident Risk Analysis: [[Traffic Accident Risk Analysis]]<br />
<br />
-- [[User:Stej34|Stej34]] ([[User talk:Stej34|talk]]) 20:46, 10 January 2025 (CET) Urban Traffic Flow Optimization: [[Urban Traffic Flow Optimization]]<br />
<br />
--[[User:Lozd00|Lozd00]] ([[User talk:Lozd00|talk]]) 20:57, 10 January 2025 (CET) Bee Foraging Behavior: [[Bee Foraging Behavior]]<br />
<br />
-- [[User:Holp11|Holp11]] ([[User talk:Holp11|talk]]) 22:46, 10 January 2025 (CET) Simulation of Security Efficiency in a Store: Analyzing Optimal Guard Allocation Based on Obstruction and Escape Dynamics : [[Simulation of Security Efficiency in a Store: Analyzing Optimal Guard Allocation Based on Obstruction and Escape Dynamics]]<br />
<br />
-- [[User:Misd01|Misd01]] ([[User talk:Misd01|talk]]) 22:14, 10 January 2025 (CET) Birds Beahvior Simulation [[Birds behavior]]<br />
<br />
-- [[User:Rysc00|Rysc00]] ([[User talk:Rysc00|talk]]) 23:04, 10 January 2025 (CET) Supermarket checkout process simulation [[Supermarket checkout process simulation]]<br />
<br />
-- [[User:Lanm14|Lanm14]] ([[User talk:Lanm14|talk]]) 0:40, 11 January 2025 (CET) Snowing simulation [[Simulace zasněžování]]<br />
<br />
-- [[User:Spis03|Spis03]] ([[User talk:Spis03|talk]]) 22:11, 11 January 2025 (CET) Ant Colony simulation: [[Ant Colony]]<br />
<br />
-- [[User:Sedp11|Sedp11]] ([[User talk:Sedp11|talk]]) 16:05, 17 January 2025 (CET) Simulation of traffic flow efficiency on highway D1: [[Simulation of traffic flow efficiency on highway D1]]<br />
<br />
[[User:Tros01|Tros01]] ([[User talk:Tros01|talk]]) 21:18, 19 January 2025 (CET) Populating the database: [[Populating the database]]</div>Tros01http://www.simulace.info/index.php?title=Assignments_WS_2024/2025&diff=26503Assignments WS 2024/20252025-01-11T23:33:47Z<p>Tros01: added sim concept tros01</p>
<hr />
<div>{{Ambox<br />
| text = <div><br />
Please, put here your assignments. Do not forget to sign them. You can use <nowiki>~~~~</nowiki> (four tildas) for an automatic signature. Use Show preview in order to check the result before your final sumbition.<br />
</div><br />
}}<br />
<br />
{{Ambox<br />
| text = <div><br />
Please, strive to formulate your assignment carefully. We expect an adequate effort to formulate the assignment as it is your semestral paper. Do not forget that your main goal is a research paper. It means your simulation model must generate the results that are specific, measurable and verifiable. Think twice how you will develop your model, which entities you will use, draw a model diagram, consider what you will measure. No sooner than when you have a good idea about the model, submit your assignment. And of course, read [[How to deal with the simulation assignment|How to deal with the simulation assignment]].<br />
</div><br />
}}<br />
<br />
{{Ambox<br />
| text = <div><br />
Topics on gambling, cards, etc. are not welcome.<br />
</div><br />
}}<br />
<br />
{{Ambox<br />
| type = content<br />
| text = <div><br />
In order to avoid possible confusion, please, check if you have added '''approved''' in bold somewhere in our comment under your submission. If there is no '''approved''', it means the assignment was not approved yet.<br />
</div><br />
}}<br />
<br />
{{Ambox<br />
| text = <div><br />
'''Criteria for evaluation of the simulation proposal'''<br />
<br />
The proposal must contain:<br />
*What you will simulate<br />
*The goal of the simulation (what you analyze - i.e. not "to simulate balloon factory", but what problem should the simulation solve).<br />
*Who would actually use such simulation (example of such user) and how would it help him<br />
*What method and simulation environment you plan to use. Choose only from the development environments that we have used in the course.<br />
*What variables will be incorporated<br />
*What variables will be random<br />
*What exact data you will base values of your variables on<br />
*(In case of Monte Carlo) What exact data you will base your determination of probability distribution of your random variables on<br />
*What exact data you will base your formulas in the simulation (simulation behavior) on <br />
<br />
'''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).'''<br />
<br />
# Is it clear from the proposed assignment how the simulation will work?<br />
# Does the simulation make sense?<br />
# Is the simulation model complex enough to simulate credibly the real-world phenomenon that the simulation tries to simulate?<br />
# Is the data used real and relevant for the real-world phenomenon that the simulation tries to simulate?<br />
# Is the simulation feasible? (in given time by the course)<br />
<br />
'''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.'''<br />
<br />
</div><br />
}}<br />
<br />
==Ant Colony==<br />
<br />
'''What will be simulated:'''<br />
*Ant colony growth<br />
<br />
'''Goal of the simulation:'''<br />
*The simulation aims to demonstrate how the complex, organized behaviors of an ant colony emerge from simple, decentralized rules followed by individual ants.<br />
<br />
'''Who would use the simulation and how it helps them:'''<br />
*There is a diverse list of potential users of this simulation.<br />
**Biologists can use the simulation to study and analyze the behavior of individual ants, their collective actions, and the emergent behavior of the ant colony.<br />
**Biology educators can use this simulation as an engaging, interactive tool to demonstrate how the complex, organized behaviors of an ant colony emerge from simple, decentralized rules followed by individual ants.<br />
**Exotic cuisine chefs can use this simulation to predict and optimize ant colony growth. This allows them to manage colonies sustainably and maximize the yield of their unique ingredient.<br />
<br />
'''Method and simulation environment:'''<br />
*Method: Multiagent simulation<br />
*Simulation environment: NetLogo<br />
<br />
'''Variables in the model:'''<br />
*Deterministic Variables:<br />
**Queen's Egg-Laying Rate<br />
**Egg Development Time<br />
**Worker Task Allocation<br />
**Environmental Constants<br />
*Random Variables:<br />
**Egg Survival Rate<br />
**Worker Behavior<br />
**Worker Lifespan<br />
**Environmental Threats<br />
<br />
'''Data sources:'''<br />
*Observational data<br />
*Research articles<br />
<br />
[[User:Spis03|Spis03]] ([[User talk:Spis03|talk]]) 14:33, 9 December 2024 (CET)<br />
<br />
'''APPROVED''' [[User:Tomáš|Tomáš]] ([[User talk:Tomáš|talk]]) 16:28, 17 December 2024 (CET)<br />
----<br />
<br />
<br />
'''Assignment Proposal (Draft) Title:'''<br />
*Simulation of pension reform in the Czech Republic: Analysis of long-term sustainability<br />
<br />
'''What will be simulated:'''<br />
*A system dynamics model of the Czech pension system that simulates the long-term financial sustainability under varying demographic, economic, and policy scenarios. The simulation will project future balances of the pension system, incorporating the flows of revenues (social insurance contributions) and expenditures (pension payouts)<br />
<br />
'''Goal of the simulation (What problem should the simulation solve):'''<br />
*The main goal is to analyze how different pension reform strategies (e.g., adjusting retirement age, altering contribution rates, changing the indexation formula of pensions) will affect the long-term stability of the Czech pension system. The simulation aims to identify specific policy levers and thresholds that ensure the pension system’s financial equilibrium over a multi-decade horizon, despite changing demographic and economic conditions.<br />
<br />
'''Who would use the simulation and how it helps them:'''<br />
*The potential users include not only the Ministry of Finance, the Ministry of Labour and Social Affairs, but also the general public and the media. Although the model does not simulate the pension system in complete detail, it provides a general overview and helps users understand the basic mechanisms and trends that will shape the future of the pension system. In this way, users can:<br />
**Gain a preliminary orientation and inspiration: By experimenting with simple scenarios (e.g., raising the retirement age or altering contribution rates), users can gain a clearer picture of how different reform steps could influence the stability of the pension system.<br />
**Provide context for public debate: The model can assist citizens, journalists, and non-profit organizations in better understanding the issues surrounding pension reform. This allows them to critically evaluate political proposals or expert recommendations.<br />
**Lead to more informed decision-making: While this is not a tool for detailed macroeconomic forecasting, the simulation provides a general insight into potential long-term trends. This can contribute to a broader understanding of the necessity for reforms and their impact on future generations.<br />
<br />
'''Method and simulation environment:'''<br />
<br />
*Method: System Dynamics<br />
*Simulation environment: Vensim PLE (freely available for academic use)<br />
<br />
'''Variables in the model (deterministic and random):'''<br />
<br />
*Core Population Variables:<br />
**Number of children (new entrants to future workforce)<br />
**Number of working-age population (workers contributing to the system)<br />
**Number of pensioners (beneficiaries)<br />
<br />
*Policy Variables:<br />
**Statutory retirement age<br />
**Contribution rate to social insurance (percentage of wage)<br />
**Pension benefit formula and indexation mechanism<br />
<br />
*Economic Variables:<br />
**Average wage (influences contributions)<br />
**Inflation rate (influences indexation of pensions and wage growth)<br />
<br />
*Fiscal Variables:<br />
**Total contributions collected (based on number of workers, contribution rate, and average wage)<br />
**Total pension expenditure (based on number of pensioners and average pension)<br />
**Pension system reserve fund (if applicable) and its depletion or accumulation<br />
<br />
*Random Variables:<br />
**The model will incorporate stochastic elements through probability distributions derived from historical data and OECD/EUROSTAT projections to reflect uncertainty in:<br />
***Fertility rate (affects future workforce size; random from projected distribution)<br />
***Mortality rate / Life expectancy changes (stochastic variation around central OECD forecasts)<br />
***Inflation rate (stochastic variation around central forecast from CNB/OECD data)<br />
***Retirement rate (number of people retire each year +-)<br />
<br />
'''Data sources (for deterministic baseline and to derive distributions):'''<br />
*Czech Statistical Office (ČSÚ) for historical demographic data<br />
*OECD demographic and economic projections for Czech Republic<br />
*Eurostat long-term demographic projections for EU countries<br />
<br />
'''Formulas in the simulation (examples):'''<br />
*Pension Expenditure: Total Pension Expenditure = Number of Pensioners * Average Pension<br />
*Average Pension Calculation: Average Pension(t+1) = Average Pension(t) * (1 + InflationIndex)<br />
*Contribution Revenue: Total Contributions = Number of Workers * Average Wage * Contribution Rate<br />
*System Balance: Annual Balance = Total Contributions - Total Pension Expenditure<br />
*Accumulation or depletion of the pension reserve fund is then modeled as a stock: Reserve(t+1) = Reserve(t) + Annual Balance.<br />
<br />
'''Model complexity and data linking:'''<br />
*'''Causal loop diagrams (CLD):''' Will illustrate feedback loops such as how employment and wage growth influence contributions, and how demographic changes influence the ratio of workers to retirees.<br />
*'''Stock and Flow Diagrams:''' Will detail population stocks (children, workers, retirees), and financial stocks (pension fund reserves), along with flows (entrants to workforce, retirees, death rates, pension contributions, and payouts).<br />
<br />
'''Specific, measurable, and verifiable results:'''<br />
*Specificity: The model will project the pension system’s financial status from year X to year X+50 under various reform scenarios, providing exact quantitative outcomes (e.g., fund balance in billions CZK, pension-to-wage ratio).<br />
<br />
*Measurable metrics:<br />
**Dependency ratio (number of pensioners per 100 workers)<br />
**Pension system annual balance (CZK) and cumulative reserves over time<br />
**Average replacement rate (pension/average wage ratio)<br />
**Sensitivity of sustainability gap to changes in retirement age or contribution rate<br />
<br />
*Verifiability: The initial model run will be calibrated against historical data for the past decade. Adjustments to parameters and comparison with known OECD and ČSÚ forecasts will verify the model’s credibility.<br />
<br />
[[User:Omaj01|Omaj01]] ([[User talk:Omaj01|talk]])<br />
::'''APPROVED'''[[User:Oleg.Svatos|Oleg.Svatos]] ([[User talk:Oleg.Svatos|talk]]) 17:57, 6 December 2024 (CET)<br />
<br />
<br />
----<br />
<br />
<br />
==Simulation concept – Invasive Plant Species vs. Native Plants vs. Herbivores Jan César (cesj05)==<br />
<br />
''' Objectives: '''<br />
<br />
Understand the dynamics of competition between invasive plant species and native plants in a shared environment<br />
<br />
Explore the conditions under which either the invasive species dominates, coexists, or fails to establish.<br />
<br />
''' Environment: '''<br />
<br />
Each patch represents a piece of land that can grow either a natrive or invasive plant (or remain empty)<br />
<br />
Plants compete for resources on each path<br />
<br />
''' Agents: '''<br />
<br />
Native Plants: Slower growth but more resistant to herbivores or harsh conditions.<br />
<br />
Invasive Plants: Faster growth and higher seed dispersal rate but less resistant to herbivores.<br />
<br />
Herbivores: Agents that eat plants, with a preference for invasive or native species (modifiable by the user).<br />
<br />
''' Methods '''<br />
<br />
Initialization:<br />
<br />
Randomly populate the grid with a mix of invasive and native plants.<br />
<br />
Set up resource levels for each patch.<br />
<br />
Place herbivores randomly across the grid.<br />
<br />
<br />
''' Simulation Steps (Turtles/Agents): '''<br />
<br />
Each plant (agent) checks:<br />
<br />
Whether it has resources to grow or reproduce.<br />
<br />
If conditions are favorable, it spreads seeds to nearby patches.<br />
<br />
Herbivores move and consume plants on the patches they visit.<br />
<br />
Competition between plants on shared patches determines which survives.<br />
<br />
<br />
Interaction Dynamics: Modify the probability of herbivory or the effectiveness of seed dispersal as sliders to explore different scenarios.<br />
<br />
<br />
The simulation will be done in NetLogo, as for the data, I have chosen these plants:<br />
<br />
''' Kudzu (Pueraria montana) '''<br />
<br />
Growth Rate: Kudzu is renowned for its rapid growth, capable of extending up to 0.3 meters (1 foot) per day, with mature vines reaching lengths of 30 meters (98 feet). <br />
<br />
<br />
Resource Utilization: As a nitrogen-fixing plant, kudzu thrives in nitrogen-deficient soils, enhancing its competitive advantage in such environments. <br />
<br />
<br />
Competitive Strategy: Kudzu's aggressive growth allows it to overtop and shade native vegetation, effectively outcompeting other species for sunlight and space. <br />
<br />
<br />
''' Purple Coneflower (Echinacea purpurea) '''<br />
<br />
Growth Characteristics: This perennial herb typically grows to heights of 1 to 3 feet (approximately 0.3 to 0.9 meters) and produces a woody rhizome. <br />
<br />
<br />
Resource Requirements: Purple coneflower prefers sunny sites with low levels of competition and soils rich in magnesium and calcium. <br />
<br />
<br />
Competitive Ability: While it can coexist with other species, purple coneflower may require management to prevent being outcompeted by more aggressive plants. <br />
<br />
This description of chosen plant species will be used to set up their behaviour in NetLogo.<br />
<br />
''' Resources: '''<br />
<br />
For Kudzu (Pueraria montana):<br />
<br />
Forest Service, U.S. Department of Agriculture. (n.d.). Pueraria montana var. lobata: Kudzu. Retrieved from https://www.fs.usda.gov/database/feis/plants/vine/puemonl/all.html<br />
<br />
National Center for Biotechnology Information. (2024). PMC Article on Kudzu Growth Dynamics. Retrieved from https://pmc.ncbi.nlm.nih.gov/articles/PMC9824185/<br />
<br />
Wikipedia contributors. (n.d.). Kudzu in the United States. Retrieved from https://en.wikipedia.org/wiki/Kudzu_in_the_United_States<br />
<br />
For Purple Coneflower (Echinacea purpurea):<br />
<br />
USDA Natural Resources Conservation Service. (n.d.). Plant guide: Echinacea purpurea. Retrieved from https://plants.usda.gov/DocumentLibrary/plantguide/pdf/pg_ecan2.pdf<br />
<br />
Plant Delights Nursery. (n.d.). Purple Coneflower (Echinacea purpurea). Retrieved from https://www.plantdelights.com/blogs/articles/purple-coneflower-echinacea-purpurea-plant<br />
<br />
USDA Natural Resources Conservation Service. (n.d.). Echinacea purpurea Fact Sheet. Retrieved from https://plants.usda.gov/DocumentLibrary/factsheet/pdf/fs_ecpu.pdf<br />
<br />
<br />
<br />
<br />
If needed, more studies will be used.<br />
<br />
This simulation can be used by gardeners trying to maintain their garden. [[User:Cesj05|Cesj05]] ([[User talk:Cesj05|talk]]) 17:53, 6 December 2024 (CET)<br />
----<br />
It is necessary to use real-world data. For simplicity sake, I strongly recommend to pick a particular specie or a couple species where are you able obtain data. Otherwise the task wouldn't be verifiable. [[User:Tomáš|Tomáš]] ([[User talk:Tomáš|talk]]) 16:33, 17 December 2024 (CET)<br />
<br />
<br />
Updated - particular species chosen with attributes and resources, I hope it is alright, Mr. Svatoš already told me on class that if I provided some relevant resources, it should be approved without a problem (meaning even without specifically chosen plant species), thank you [[User:Cesj05|Cesj05]] ([[User talk:Cesj05|talk]]) 13:23, 20 December 2024 (CET)<br />
'''APPROVED''' [[User:Tomáš|Tomáš]] ([[User talk:Tomáš|talk]]) 14:00, 20 December 2024 (CET)<br />
== Simulation Concept – Traffic Accident Risk Analysis ==<br />
<br />
=== Objectives ===<br />
* Understand the dynamics of traffic accidents based on road conditions, traffic density, and driver behavior.<br />
* Explore the conditions under which accidents become frequent, and how they impact overall traffic flow.<br />
* Test mitigation strategies like improved road quality or stricter speed limits.<br />
<br />
=== Environment ===<br />
* '''Patches''': Represent road segments and intersections, each with a defined condition:<br />
** '''Good''': Low accident probability.<br />
** '''Bad''': Increased accident probability.<br />
** '''Under Construction''': High accident probability and slower movement for cars.<br />
* '''Road Network''': A grid-based layout with straight roads and intersections where traffic can flow.<br />
<br />
=== Agents ===<br />
# '''Cars (Turtles):'''<br />
## Each car has a speed, a destination, and a probability of making a driving error.<br />
## Movement is influenced by traffic density and road conditions.<br />
# '''Accidents:'''<br />
## Simulated as blocked road segments.<br />
## Cause delays and force cars to reroute.<br />
# '''Traffic Lights (Optional):'''<br />
## Located at intersections to control flow.<br />
## Can be toggled on/off to explore their impact on accidents.<br />
<br />
=== Methods ===<br />
==== Initialization ====<br />
* Randomly distribute cars across the road network with initial speeds and destinations.<br />
* Assign random conditions (good, bad, under construction) to road segments based on user input.<br />
<br />
==== Simulation Steps (Turtles/Agents) ====<br />
# '''Movement:'''<br />
## Cars follow road segments, moving faster on good roads and slower on bad/under-construction ones.<br />
# '''Accident Risk:'''<br />
## Probability of an accident increases with:<br />
### Poor road conditions.<br />
### High speed.<br />
### High traffic density.<br />
# '''Accident Handling:'''<br />
## If an accident occurs, the road segment is temporarily blocked.<br />
## Cars reroute to avoid the blocked segment, increasing congestion elsewhere.<br />
# '''Recovery:'''<br />
## Accidents are cleared after a set duration, restoring traffic flow.<br />
<br />
==== Interaction Dynamics ====<br />
* '''User Controls:'''<br />
** Traffic density, road condition distribution, speed limits, and driver error probabilities can be adjusted with sliders.<br />
* '''Scenarios:'''<br />
** Test high traffic density with poor roads versus low traffic density with good roads.<br />
** Simulate stricter traffic laws by reducing driver errors and imposing speed limits.<br />
<br />
=== Simulation Details ===<br />
* '''Platform''': NetLogo.<br />
* '''Data Source''': Synthetic data will be used to mimic real-world traffic dynamics based on studies and assumptions.<br />
* '''Behavior Setup''': Modeled on findings from traffic and safety research:<br />
** [https://www.tandfonline.com/doi/full/10.1080/13669877.2010.547259 Study 1]<br />
** [https://www.tandfonline.com/doi/pdf/10.1080/23311916.2020.1834659 Study 2]<br />
** [https://www.tandfonline.com/doi/pdf/10.1080/16483840.2003.10414070 Study 3]<br />
* Additional studies will be incorporated if needed to refine parameters.<br />
[[User:Sim timm03|Sim timm03]] ([[User talk:Sim timm03|talk]]) 16:11, 7 December 2024 (CET)<br />
<br />
: '''APPROVED''' Dont forget to keep the model testable, meaning all parameters should have a reasonable justification. [[User:Tomáš|Tomáš]] ([[User talk:Tomáš|talk]]) 14:02, 20 December 2024 (CET)<br />
<br />
= Assignment Proposal (Draft) =<br />
<br />
== Title ==<br />
'''Simulation of Security Efficiency in a Store: Analyzing Optimal Guard Allocation Based on Obstruction and Escape Dynamics'''<br />
<br />
== What will be simulated ==<br />
*A simulation of a store environment where security guards patrol to prevent thieves from stealing goods and escaping through designated exits. The store layout includes customizable obstacles (regals), guards, and thieves. The simulation focuses on the limited visibility due to obstacles and models the dynamic interaction between guards and thieves, exploring how the required number of guards changes based on the number of thieves.*<br />
<br />
== Goal of the simulation (What problem should the simulation solve) ==<br />
*The simulation aims to determine the optimal number of guards needed to secure a store effectively under varying conditions of thief count. The ultimate goal is to provide recommendations for store security design based on quantitative analysis.*<br />
<br />
== Who would use the simulation and how it helps them ==<br />
*Store Managers and Security Companies*: Helps in designing security layouts and determining the number of security guards needed to maximize efficiency and minimize theft. <br />
*Students*: Offers insights into visibility-limited environments and agent-based modeling techniques.<br />
<br />
== Method and simulation environment ==<br />
* '''Method''': Agent-based modeling <br />
* '''Simulation environment''': NetLogo <br />
<br />
== Variables in the model (deterministic and random) ==<br />
<br />
=== Deterministic Variables ===<br />
* Number of guards <br />
* Number of thieves <br />
* Number of regals (obstacles): Fixed positions <br />
* Store size: <br />
* Guard and thief placement: Guards are placed on opposite sides of the store to maximize coverage; thieves are placed randomly.<br />
<br />
=== Random Variables ===<br />
* Movement paths: Thieves and guards move dynamically based on patrol or escape strategies. <br />
* Thief behavior: Randomized target selection for obstacles and exits. <br />
* Guard patrol patterns: Random movement within patrol zones unless a thief is spotted. <br />
<br />
== Formulas in the simulation (examples) ==<br />
* '''Guard visibility''': <br />
* \( \text{Visible range} = d \), where \( d \) is the number of unobstructed cells (line of sight blocked by obstacles). <br />
* '''Thief capture condition''': <br />
* A thief is captured if a guard moves onto the same cell. <br />
* '''Escape success''': <br />
* A thief escapes if it reaches an exit before being captured. <br />
* '''Capture efficiency''': <br />
* \( \text{Efficiency} = \frac{\text{Captured thieves}}{\text{Total thieves}} \) <br />
<br />
== Model complexity and data linking ==<br />
* '''Guard and thief dynamics''': <br />
* Guards patrol predefined zones or reactively chase thieves if spotted. <br />
* Thieves move toward regals to "steal" and then to exits to escape. <br />
* '''Obstacle placement''': <br />
* Regals are fixed in predefined locations that block visibility and movement. <br />
* '''Outputs''': <br />
* Capture success rate <br />
* Number of escaped thieves <br />
* Guard efficiency metrics <br />
<br />
== Specific, measurable, and verifiable results ==<br />
* '''Specificity''': <br />
* The model provides quantitative insights into the number of guards needed to maintain security across various scenarios. <br />
* '''Measurable metrics''': <br />
* Capture rate (% of thieves caught) <br />
* Escape rate (% of thieves successfully escaped) <br />
* Average patrol effectiveness (distance covered by guards and time to interception). <br />
<br />
== Key questions the simulation will answer ==<br />
# How does the number of guards required to secure the store change with varying numbers of thieves? <br />
# What are the most effective patrol strategies for guards in a fixed environment with limited visibility? <br />
# How does the coordination or randomness of thieves’ behavior influence the effectiveness of the store's security? <br />
<br />
[[User:Holp11|Holp11]] ([[User talk:Holp11|talk]]) 21:06, 7 December 2024 (CET)<br />
<br />
: '''APPROVED''', but: under all circumstances, obtain real data and base the simulation upon them. This simulation is relatively simple to develop, the real data are what could make it valuable. [[User:Tomáš|Tomáš]] ([[User talk:Tomáš|talk]]) 14:25, 20 December 2024 (CET)<br />
<br />
== Customers at Traditional and Self-Service Checkouts ==<br />
<br />
=== Topic ===<br />
'''Simulation of the customer check-in process at the checkout''', including incoming customers, their checkout selection (including self-service options), queuing, and service. The model reflects different service speeds, customer behavior (e.g., transitioning between checkouts), and satisfaction levels.<br />
<br />
=== Problem ===<br />
The supermarket lacks rules for opening and closing checkouts, resulting in either excessive staff costs or low customer satisfaction. Data-based rules for checkout operations can optimize efficiency and satisfaction.<br />
<br />
=== Goal ===<br />
Establish optimal rules for opening and closing checkouts to maintain customer satisfaction above 70%.<br />
<br />
=== Simulation Stakeholders ===<br />
* '''HR Managers:''' Determine employee requirements per shift.<br />
* '''Shift Leaders:''' Establish rules for opening new checkouts.<br />
* '''Financial Manager:''' Optimize employee costs.<br />
<br />
== Method ==<br />
* '''Platform:''' NetLogo<br />
* '''Method:''' Agent-based simulation<br />
<br />
== Requirements ==<br />
<br />
=== Reality Abstraction Plan ===<br />
<br />
==== Customers ====<br />
* '''Number of Items in Purchase:''' Lognormal distribution (µ=3, σ=0.3).<br />
* '''Checkout Type Preference:'''<br />
* Items > 20: Preference = 1 (regular checkouts only).<br />
* Items > 10: Lognormal distribution on scale 1-100 (µ=2.8, σ=0.7).<br />
* Items ≤ 10: 100 - (Lognormal distribution on scale 1-100, µ=2.8, σ=0.7).<br />
* '''Willingness to Switch Checkouts:''' Lognormal distribution on scale 1-100 (µ=2.9, σ=0.4). Drops to half after switching.<br />
* '''Satisfaction:''' Depends on waiting time, switching, and checkout type.<br />
* Initial value: Normal distribution (mean=95, std=5).<br />
* '''Waiting Time:'''<br />
* ≤ 3 min: No change.<br />
* > 3 min: Decreases logarithmically: \( S(t) = 100 - 10 \cdot \ln(1 + (t - 3)) \).<br />
* '''Switching Checkouts:'''<br />
* Willingness > 80: No change.<br />
* Willingness ≤ 80: Decreases by a range (e.g., 1-5 points for willingness ≤ 80 & > 60).<br />
* '''Checkout Type:''' Satisfaction changes based on preference and actual service type (e.g., increases by 5-10 points if preference > 60 and served at self-checkout).<br />
* Satisfaction cannot be negative.<br />
* '''Goal:''' Leave the supermarket as satisfied as possible.<br />
<br />
==== Checkouts ====<br />
* '''Regular Checkouts (Count: 5):'''<br />
* '''Service Speed:'''<br />
* Payment: Normal distribution (mean=1 min, std=0.2).<br />
* Marking Items: 80% EAN-coded items (mean=0.02 min, std=0.01); 20% non-EAN (mean=0.03 min, std=0.01).<br />
* '''Checkout Error:''' 0.1% probability; solving time = Normal distribution (mean=0.5 min, std=0.1).<br />
* '''Self-Service Checkouts (Count: 8):'''<br />
* '''Service Speed:'''<br />
* Payment: Normal distribution (mean=1.2 min, std=0.3).<br />
* Marking Items: 80% EAN-coded items (mean=0.03 min, std=0.01); 20% non-EAN (mean=0.04 min, std=0.01).<br />
* '''Checkout Error:''' 1% probability; solving time = Normal distribution (mean=0.5 min, std=0.1).<br />
<br />
=== Simulation Rules ===<br />
* '''Operating Hours:''' 7:00-20:00 (1 average day).<br />
* '''Customer Arrivals:'''<br />
* Peak Hours (7:00-10:00 & 16:00-18:00): Normal distribution (mean=4, std=1).<br />
* Non-Peak Hours (10:00-16:00 & 18:00-20:00): Normal distribution (mean=2, std=1).<br />
* '''Goal of Checkouts:''' Maintain customer satisfaction above 70% with minimal open regular checkouts.<br />
* The simulation will not address scenarios outside the checkout area.<br />
* One customer corresponds to one purchase.<br />
<br />
<br />
<br />
[[User:Rysc00|Rysc00]] ([[User talk:Rysc00|talk]]) 13:23, 08 December 2024 (CET)<br />
<br />
: Please, elaborate it. What will be the real data you will base it on. What supermarket/store.?<br />
: BTW: Don't use HTML for editing these documents, Wiki uses Markup. Using HTML makes the document messy.<br />
<br />
Update: The mentioned supermarket is supposed to be Tesco in Vodňany, my hometown. The supermarket will not share exact data with me - the values are based on my own experience and observation. Is that a sufficient base for the simulation? Obtaining such data from the supermarket is not realistic, and as to any other sources - research papers on this topic are not from the same socio-geographical background, which influences customer behavior a lot. The simulation would be less realistic if I based it on research papers.<br />
<br />
[[User:Rysc00|Rysc00]] ([[User talk:Rysc00|talk]]) 22:17, 20 December 2024 (CET)<br />
<br />
: In general, it is better to choose a topic for which data is available. You can elaborate on the proposed topic if you are able to justify the specific parameters. Expect to focus on this in the result. '''APPROVED''' [[User:Tomáš|Tomáš]] ([[User talk:Tomáš|talk]]) 12:16, 27 December 2024 (CET)<br />
<br />
= What you will simulate: =<br />
# I will simulate the process of artificially snowing a ski slope, including the operation of snow cannons, and the influence of temperature, humidity, and wind on snow production and the maintenance of a snow cover.<br />
<br />
== The goal of the simulation: ==<br />
# The objective is to optimize the snowmaking process to achieve the desired snow cover height at the lowest possible energy and water costs, while accounting for changing weather conditions.<br />
<br />
== Who would actually use such simulation and how: ==<br />
# A typical user might be a ski resort manager or the operator of snowmaking equipment. The simulation would help them plan and optimize their snowmaking strategy in advance, reduce operational costs, and ensure quality snow conditions for skiers.<br />
<br />
== What method and simulation environment: ==<br />
# Multi-agent simulation in NetLogo<br />
<br />
== What variables will be incorporated: ==<br />
# Deterministic variables: the placement of snow cannons, the energy demands of the snow cannons, and the target snow cover height.<br />
# State variables: the current snow depth on the slope, and the current water and energy consumption.<br />
<br />
== What variables will be random: ==<br />
# Weather conditions (temperature, humidity, wind, and any natural snowfall) will be generated with random fluctuations within the range of observed real-world values.<br />
<br />
== What exact data you will base values of your variables on: ==<br />
# The values for weather and the performance of snow cannons will be based on literature and technical specifications from manufacturers (average seasonal temperatures, typical humidity ranges, average efficiency of snow cannons).<br />
<br />
[[User:Lanm14|Lanm14]] ([[User talk:Lanm14|talk]]) 15:00, 08 December 2024 (CET)<br />
<br />
: '''APPROVED''' [[User:Tomáš|Tomáš]] ([[User talk:Tomáš|talk]]) 14:32, 20 December 2024 (CET)<br />
<br />
<br />
=Lightning Network Channel Dynamics Simulation=<br />
<br />
<p>The Lightning Network represents a promising solution to Bitcoin's scalability challenges, enabling fast and low-cost transactions. In the Czech Republic, it's gaining practical adoption with merchants like Alza.cz, Rohlik.cz and payment processors like Qerko and GoPay.</p><br />
<p> The network consists of payment channels, direct connections between two participants. Each channel has a fixed capacity, representing the total funds locked in for transactions. This capacity is shared between the two participants, with each holding a portion of the total on his side of the channel. Payments update the balance distribution within the channel. If two participants don’t have a direct channel, the network routes payments through connected channels, relying on intermediary nodes with enough capacity to complete the transfer. </p><br />
<h2>What will be simulated:</h2><br />
<br />
<p>A NetLogo agent-based simulation of Lightning Network payment channels that models:</p><br />
<ul><br />
<li>Nodes (merchants, customers, routing nodes) as agents with defined balances and behaviors</li><br />
<li>Payment channels as links between nodes with specific capacities</li><br />
<li>Transaction routing through the network</li><br />
<li>Channel balance changes and payment success/failure dynamics</li><br />
</ul><br />
<br />
<h2>Goal of the simulation:</h2><br />
<br />
<p>To analyze how different network configurations affect payment success rates and channel efficiency, specifically:</p><br />
<ul><br />
<li>Identify optimal channel capacity distribution for maximizing successful payments</li><br />
<li>Determine relationship between node connectivity and network reliability</li><br />
<li>Find bottlenecks in payment routing that cause transaction failures</li><br />
</ul><br />
<br />
<h2>Who would use the simulation and how it helps them:</h2><br />
<br />
<p>Primary users:</p><br />
<ol><br />
<li>New merchants considering Lightning Network adoption:<br />
<ul><br />
<li>Understand required number of payment channels</li><br />
<li>Plan initial channel capacity requirements</li><br />
<li>Estimate liquidity needs</li><br />
</ul><br />
</li><br />
<li>Lightning Network node operators:<br />
<ul><br />
<li>Optimize channel configurations</li><br />
<li>Understand routing effectiveness</li><br />
<li>Plan capital allocation</li><br />
</ul><br />
</li><br />
</ol><br />
<br />
<h2>Method and simulation environment:</h2><br />
<br />
<ul><br />
<li>Method: Agent-based modeling</li><br />
<li>Environment: NetLogo</li><br />
</ul><br />
<br />
<h2>Variables incorporated:</h2><br />
<br />
<h3>Deterministic Variables:</h3><br />
<ol><br />
<li>Number of nodes (N):<br />
<ul><br />
<li>Initial setup: 100-200 nodes</li><br />
<li>Based on small subset of real network for feasibility</li><br />
<li>Can be adjusted via interface slider</li><br />
</ul><br />
</li><br />
<li>Initial channel capacity (C):<br />
<ul><br />
<li>Range: 0.001 - 0.1 BTC per channel</li><br />
<li>Based on average values from 1ML.com statistics</li><br />
<li>Set at channel creation time</li><br />
</ul><br />
</li><br />
<li>Node types:<br />
<ul><br />
<li>Merchant: 20% of nodes</li><br />
<li>Customer: 70% of nodes</li><br />
<li>Routing-node: 10% of nodes</li><br />
<li>Proportions based on network analysis papers</li><br />
</ul><br />
</li><br />
<li>Base fee per transaction:<br />
<ul><br />
<li>Default: 1 satoshi base + 0.001% of amount</li><br />
<li>Based on common Lightning node configurations</li><br />
</ul><br />
</li><br />
<li>Network topology structure:<br />
<ul><br />
<li>Average connections per node: 3-8</li><br />
<li>Based on observed network patterns</li><br />
<li>Follows power-law distribution</li><br />
</ul><br />
</li><br />
</ol><br />
<br />
<h3>Random Variables:</h3><br />
<ol><br />
<li>Transaction amounts:<br />
<ul><br />
<li>Distribution: Log-normal</li><br />
<li>Mean: 50,000 satoshis</li><br />
<li>Standard deviation: 25,000 satoshis</li><br />
<li>Based on public Lightning Network statistics</li><br />
</ul><br />
</li><br />
<li>Transaction timing:<br />
<ul><br />
<li>Poisson distribution</li><br />
<li>Mean arrival rate (λ): 0.1 transactions per node per minute</li><br />
<li>Can be adjusted via interface slider</li><br />
</ul><br />
</li><br />
<li>Channel balance fluctuations:<br />
<ul><br />
<li>Random walk within channel capacity</li><br />
<li>Step size: Normal distribution (μ=0, σ=0.01 × capacity)</li><br />
<li>Updates every simulation tick</li><br />
</ul><br />
</li><br />
<li>Node connection preferences:<br />
<ul><br />
<li>Probability of connection decreases with distance</li><br />
<li>Weighted by node type and existing connections</li><br />
<li>Uses preferential attachment model</li><br />
</ul><br />
</li><br />
<li>Payment success probability:<br />
<ul><br />
<li>Base probability: 0.95</li><br />
<li>Modified by:<br />
<ul><br />
<li>Channel capacity utilization</li><br />
<li>Path length</li><br />
<li>Node type</li><br />
</ul><br />
</li><br />
</ul><br />
</li><br />
</ol><br />
<br />
<h2>Data sources for variable values:</h2><br />
<br />
<ol><br />
<li>Network structure and capacities:<br />
<ul><br />
<li>Public Lightning Network explorer (1ML.com):<br />
<ul><br />
<li>Current number of nodes (~17,000)</li><br />
<li>Average channel capacity (~0.03 BTC)</li><br />
<li>Node distribution and connectivity patterns</li><br />
</ul><br />
</li><br />
<li>Mempool.space statistics:<br />
<ul><br />
<li>Total network capacity</li><br />
<li>Channel count</li><br />
<li>Node count</li><br />
</ul><br />
</li><br />
</ul><br />
</li><br />
<li>Transaction patterns:<br />
<ul><br />
<li>Public Lightning Network statistics from Bitcoin Visuals (bitcoinvisuals.com)</li><br />
<li>Academic research papers on Lightning Network analysis:<br />
<ul><br />
<li>"Lightning Network: a second path towards centralisation of the Bitcoin economy" (Lin et al., 2020)</li><br />
<li>"A Quantitative Analysis of Security, Anonymity and Scalability for the Lightning Network" (Tikhomirov et al., 2020)</li><br />
</ul><br />
</li><br />
</ul><br />
</li><br />
</ol><br />
<br />
<h2>Simulation behavior formulas based on:</h2><br />
<br />
<ol><br />
<li>Payment routing:<br />
<ul><br />
<li>Lightning Network specifications (BOLTs) from lightning-rfc repository</li><br />
<li>LND implementation documentation</li><br />
<li>Published research on routing behavior</li><br />
</ul><br />
</li><br />
<li>Channel balancing:<br />
<ul><br />
<li>Lightning Network whitepaper formulas</li><br />
<li>Public node operation best practices</li><br />
<li>Academic analysis of channel dynamics</li><br />
</ul><br />
</li><br />
</ol><br />
<br />
[[User:Filip Simulátor|mikf02]] ([[User talk:Filip Simulátor|talk]]) 19:58, 8 December 2024 (CET)<br />
<br />
: '''APPROVED''' Don't use HTML for writing WIKI!!! [[User:Tomáš|Tomáš]] ([[User talk:Tomáš|talk]]) 11:48, 27 December 2024 (CET)<br />
<br />
= Performance of Solar Power Plant Using Monte Carlo Simulation and ERA5 Data (matj27)=<br />
<br />
== What will you simulate? ==<br />
The simulation will model the potential energy output of a power plant. Simulation will be based upon meteorological data from the ERA5 reanalysis dataset with panel efficiency variability to determine an energy production estimates over a year in Louny (Roughly N 50°21′00″; E 013°47′00″; ERA5 resolution is cca. 31 km - 0.25° grid (bbox: [[13.75, 50.5],[14.00, 50.5],[14.00, 50.25],[13.75, 50.25],[13.75, 50.5]])).<br />
<br />
== Goal of the simulation ==<br />
The goal is to analyze the impact of daily solar radiance variability and panel efficiency fluctuations on the power plant energy output. <br />
<br />
== Users ==<br />
Solar power plants companies and solar power plants owners to calculate financial feasibility, ROI etc.<br />
<br />
== Methods, environment ==<br />
'''Methods:''' Monte Carlo simulation<br />
<br />
'''Environment:''' Python - to process ERA5 GRIB data, Excel - to run Monte Carlo simulation<br />
<br />
== Variables incorporated ==<br />
Solar panels power and efficiency, solar radiance from ERA5.<br />
<br />
Historical ERA5 data will define the mean and variance of solar radiance.<br />
<br />
Panel efficiency variability will be sourced from manufacturer specifications.<br />
<br />
== Data for simulation behavior formulas ==<br />
Formula to estimate the electricity generated in output of a photovoltaic system: E = A * r * H * PR<br />
<br />
E = Energy (kWh)<br />
<br />
A = Total solar panel Area (m2)<br />
<br />
r = solar panel yield or efficiency (%) <br />
<br />
H = Annual average solar radiation on tilted panels (based on solar radiance)<br />
<br />
PR = Performance ratio, coefficient for losses (range between 0.5 and 0.9, default value = 0.75)<br />
<br />
Based on https://photovoltaic-software.com/principle-ressources/how-calculate-solar-energy-power-pv-systems[https://photovoltaic-software.com/principle-ressources/how-calculate-solar-energy-power-pv-systems]<br />
<br />
<br />
[[User:matj27|matj27]] ([[User talk:matj27|talk]]) 19:07, 9th December 2024 (CET)<br />
:: '''Approved''' [[User:Oleg.Svatos|Oleg.Svatos]] ([[User talk:Oleg.Svatos|talk]]) 15:16, 12 December 2024 (CET)<br />
<br />
= Simulation of traffic flow efficiency on highway D1 (based od traffic restrictions) =<br />
<br />
== What will be simulated ==<br />
<br />
Simulation of arrival delay based on number of traffic restrictions on highway D1. How many restrictions are "acceptable" so that there is not too much delay compared to driving without any restrictions. The user will be able to set the number of restricted kilometers and the number of restritions.<br />
<br />
== Goal ==<br />
<br />
Find out how many restrictions are too much and if it's better to have more smaller ones or less bigger ones.<br />
<br />
== Usefulness ==<br />
<br />
<br />
The simulation can show us how much delay is caused by restrictions on the highway, and whether the highway is too restricted or whether restrictions can be increased without significantly reducing travel time. It can also show us whether it is better to have more restrictions in smaller chunks or fewer restrictions over a longer stretch.<br />
<br />
== Simulation method ==<br />
<br />
Simulation in application NetLogo<br />
<br />
== Variables ==<br />
- Number of cars<br />
<br />
- Percentage of truks (slower cars)<br />
<br />
- Number of restricted kilometres<br />
<br />
- Number of restrictions<br />
<br />
- Percentage of aggresive drivers<br />
<br />
== Radnom variables ==<br />
<br />
- Speed of cars<br />
<br />
- Lane changing<br />
<br />
- Random restriction placement<br />
<br />
<br />
== Source for data == <br />
<br />
https://dopravniinfo.cz/D1<br />
https://d1.dd.cz/?direction=12<br />
<br />
[[User:Sedp11|Sedp11]] ([[User talk:Sedp11|talk]]) 16:40, 10 December 2024 (CET) - I had this topis last year but never made it. If its not OK I will make a new one.<br />
<br />
: '''APPROVED''' [[User:Tomáš|Tomáš]] ([[User talk:Tomáš|talk]]) 14:38, 20 December 2024 (CET)<br />
<br />
= System Dynamics Simulation of Hybrid Work Models =<br />
<br />
== What will be simulated ==<br />
The simulation will model workplace dynamics under three work modes—remote, hybrid, and in-office—focusing on the interplay between key factors: productivity, collaboration, employee satisfaction, and cost. The model will explore how these variables interact over time in different work environments.<br />
<br />
== The goal of the simulation ==<br />
To analyze the relationships and feedback loops between productivity, collaboration, satisfaction, and cost under various work modes, and provide actionable insights into:<br />
* How collaboration affects productivity over time.<br />
* How employee satisfaction changes in response to work mode, workload, and collaboration.<br />
* The trade-offs between cost-efficiency and employee performance.<br />
<br />
== Example User and How would it help ==<br />
* Example User: HR managers, workplace strategists, or organizational leaders in medium to large enterprises<br />
* How it helps: The simulation provides data-driven insights into the long-term effects of different work modes, helping organizations create work policies that optimize employee performance and satisfaction while maintaining cost efficiency.<br />
<br />
== Method and Simulation Environment ==<br />
* Method: System dynamics simulation to model causal relationships and feedback loops.<br />
* Simulation Environment: Vensim PLE<br />
<br />
== Variables ==<br />
* Productivity: Represents the task completion rate over time. Influenced by collaboration, workload, and satisfaction<br />
* Collaboration: Measures teamwork effectiveness. Remote work has the lowest collaboration, hybrid has moderate, and in-office has the highest levels.<br />
* Satisfaction: Reflects employee morale and well-being. Satisfaction increases with productivity and effective collaboration but decreases with excessive workload.<br />
* Cost: Represents daily operational expenses per employee. Fixed based on the work mode.<br />
<br />
== Data ==<br />
Based on studies and reports from Statista, workplace surveys and industry averages for operational costs in each work mode.<br />
<br />
== What exact data you will base your formulas in the simulation (simulation behavior) on ==<br />
* Productivity Formula: Productivity = Baseline Productivity × Collaboration Index × Satisfaction Level<br />
* Collaboration Formula: Collaboration = Baseline Collaboration × (1 − Remote_Work_Proportion)<br />
* Satisfaction Formula: Satisfaction = Baseline Satisfaction + (0.2 × Productivity) − (0.1 × Workload Index)<br />
* Cost Formula: Fixed cost values for each work mode.<br />
* Feedback Loops:<br />
** Positive Loop: High collaboration → Higher productivity → Higher satisfaction → Improved collaboration.<br />
** Negative Loop: Excessive workload → Lower satisfaction → Reduced productivity.<br />
<br />
[[User:Tara04|Tara04]] ([[User talk:Tara04|talk]]) 20:15, 11 December 2024 (CET)<br />
:: '''Approved''' [[User:Oleg.Svatos|Oleg.Svatos]] ([[User talk:Oleg.Svatos|talk]]) 15:23, 12 December 2024 (CET)<br />
<br />
----<br />
<br />
= Robotic Vacuum Algorithms Simulation by kulv05 =<br />
<br />
== What will be simulated: ==<br />
<br />
In this task I want to simulate a robotic vacuum cleaner that cleans a room, navigate around obstacles and collecting dust and trash.<br />
<br />
== The goal of the simulation ==<br />
The goal of the simulation is to compare the effectiveness of different movement algorithms for a robot vacuum, find the one that is the most efficient. I aim to determine which algorithm completes the cleaning task in the least time, consumes the least power, overall efficiency as well.<br />
The formulas for comparison:<br />
Efficiency_time= Ticks needed to finish cleaning/Dust Collected;<br />
Efficiency_power=Power usage/Trash Collected;<br />
Efficiency_overall=Trash Collected/(Ticks needed to finish cleaning×Power usage);<br />
<br />
== Who would actually use such simulation ==<br />
<br />
The results can be theoretically valuable for developers working on autonomous home devices and manufacturers of robotic vacuum cleaners such as iRobot, Xiaomi etc. Customers can also find it useful when choosing a new vacuum.<br />
<br />
== What method and simulation environment you plan to use ==<br />
<br />
The simulation will be developed using the NetLogo agent-based model<br />
<br />
== What variables will be incorporated ==<br />
<br />
''Agents'':<br />
<br />
• Vacuum<br />
• Trash<br />
• Room(The space within which the robot operates, including obstacles like furniture)<br />
<br />
''Parameters'':<br />
<br />
• Type of algorithm<br />
• Ticks needed to finish cleaning<br />
• Power usage<br />
• Trash Collected<br />
<br />
==What variables will be random==<br />
<br />
Trash placement<br />
<br />
Start position<br />
<br />
== What exact data you will base your formulas in the simulation (simulation behavior) on ==<br />
<br />
The algorithms used for comparison:<br />
Random walk(reactive), Zigzag, Spiral, Wall to wall, SLAM(if possible to implement in netlogo), A* (if possible to implement in netlogo)<br />
<br />
https://www.diva-portal.org/smash/get/diva2:1213349/FULLTEXT02.pdf [https://www.diva-portal.org/smash/get/diva2:1213349/FULLTEXT02.pdf]<br />
<br />
https://ouster.com/insights/blog/introduction-to-slam-simultaneous-localization-and-mapping [https://ouster.com/insights/blog/introduction-to-slam-simultaneous-localization-and-mapping]<br />
<br />
https://www.geeksforgeeks.org/a-search-algorithm/ [https://www.geeksforgeeks.org/a-search-algorithm/]<br />
<br />
Evaluation: <br />
<br />
Efficiency_time= Ticks needed to finish cleaning/Dust Collected<br />
<br />
Efficiency_power=Power usage/Trash Collected<br />
<br />
Efficiency_overall=Trash Collected/(Ticks needed to finish cleaning×Power usage)<br />
<br />
[[User:Kulv05|Kulv05]] ([[User talk:Kulv05|talk]]) 01:44, 13 December 2024 (CET)<br />
<br />
: '''APPROVED''' [[User:Tomáš|Tomáš]] ([[User talk:Tomáš|talk]]) 17:30, 20 December 2024 (CET)<br />
~<br />
----<br />
<br />
= Simulation Concept – Bee Foraging Behavior =<br />
<br />
=== Objectives ===<br />
* Understand the dynamics of bee foraging behavior and its efficiency in collecting nectar.<br />
* Explore the influence of environmental factors like nectar replenishment rates and bee memory retention on foraging success.<br />
* Simulate how communication methods like the waggle dance influence the collective behavior of bees.<br />
<br />
=== Environment ===<br />
* '''Patches''': Represent flowers scattered across a 2D grid, each containing a limited amount of nectar that replenishes over time.<br />
* '''Hive''': A central location on the grid where bees return after collecting nectar.<br />
<br />
=== Agents ===<br />
# '''Bees (Turtles):'''<br />
## Search for flowers with nectar and collect it.<br />
## Return to the hive to deposit nectar and signal flower locations using the waggle dance.<br />
# '''Flowers (Patches):'''<br />
## Have a specific amount of nectar that can be collected.<br />
## Nectar levels decrease as bees forage and replenish over time.<br />
<br />
=== Methods ===<br />
==== Initialization ====<br />
* Randomly distribute flowers across the grid with initial nectar levels.<br />
* Initialize a fixed number of bees at the hive.<br />
<br />
==== Simulation Steps (Turtles/Agents) ====<br />
# '''Foraging:'''<br />
## Bees search randomly or follow waggle dance signals to locate flowers with nectar.<br />
## Once nectar is collected, they return to the hive to deposit it.<br />
# '''Waggle Dance Communication:'''<br />
## Bees that successfully find nectar signal its location to other bees in the hive.<br />
## Other bees decide whether to follow these signals or continue searching independently.<br />
# '''Nectar Replenishment:'''<br />
## Flowers regenerate nectar at a rate defined by the user.<br />
# '''Memory Retention:'''<br />
## Bees remember flower locations for a limited time, after which they must search anew or rely on waggle dance signals.<br />
<br />
==== Interaction Dynamics ====<br />
* '''User Inputs:'''<br />
** Number of bees.<br />
** Nectar replenishment rate.<br />
** Bee memory retention (time).<br />
* '''Scenarios to Explore:'''<br />
** High vs. low nectar replenishment rates.<br />
** Effect of longer or shorter memory retention.<br />
** Impact of increased hive communication (more bees following waggle dances).<br />
<br />
=== Simulation Details ===<br />
* '''Platform''': NetLogo.<br />
* '''Data Source''': Synthetic data to simulate nectar levels and bee behavior, designed to mimic real-world phenomena based on biological studies.<br />
* '''Behavior Setup''': Inspired by findings in bee foraging and communication studies:<br />
** [https://link.springer.com/article/10.1556/ABiol.63.2012.Suppl.2.8?utm_source=chatgpt.com Effects of Flower Patches on Bee Foraging].<br />
** [https://academic.oup.com/beheco/article/19/2/255/212470 The Role of the Waggle Dance in Foraging Success].<br />
<br />
[[User:Lozd00|Lozd00]] ([[User talk:Lozd00|talk]]) 10:11, 13 December 2024 (CET)<br />
<br />
: '''APPROVED''' [[User:Tomáš|Tomáš]] ([[User talk:Tomáš|talk]]) 17:32, 20 December 2024 (CET)<br />
----<br />
<br />
= Simulation of Urban Bicycle-Sharing System =<br />
<br />
== Problem ==<br />
Bike-sharing systems often struggle with uneven bicycle distribution across stations, leading to user frustration, inefficient system usage, and increased operational costs for redistribution.<br />
<br />
== Goal ==<br />
Develop and analyze optimal strategies for bicycle redistribution that maximize user accessibility and system efficiency while minimizing operational costs.<br />
<br />
== Simulation Stakeholders ==<br />
* City Transportation Planners: Optimize bicycle-sharing system infrastructure<br />
* Bike-Sharing System Operators: Improve operational efficiency<br />
* Municipal Mobility Departments: Understand urban mobility patterns<br />
<br />
== Method and simulation environment ==<br />
* '''Method''': Agent-based modeling <br />
* '''Simulation environment''': NetLogo<br />
<br />
== Agents ==<br />
=== Bicycles ===<br />
Total fleet size based on real data from successful bike-sharing systems (Barcelona bike sharing)<br />
<br />
'''Individual bicycle characteristics:'''<br />
* Battery level<br />
* Maintenance status<br />
* Current station location<br />
<br />
=== Stations ===<br />
* Geographically distributed across area<br />
* Capacity limits based on real urban infrastructure<br />
* Dock availability<br />
* Location attractiveness (proximity to popular destinations)<br />
<br />
=== Users ===<br />
'''Trip Characteristics:'''<br />
* Origin and destination points<br />
* Time of day<br />
<br />
'''User Behavior:'''<br />
* Willingness to walk to alternative stations<br />
* Tolerance for bicycle unavailability<br />
<br />
=== Random Variables ===<br />
<br />
'''User Arrival Rates'''<br />
* Varying by time of day (peak/off-peak hours)<br />
** Probability distribution: Poisson distribution with parameters from actual bike-sharing system data<br />
<br />
== Simulation rules ==<br />
* system operates 24/7<br />
* '''Station emptiness:'''<br />
** < 10% empty<br />
** > 80% full<br />
<br />
== Data Limitations ==<br />
* aggregated data will be used<br />
* no real city will be used for simulation, it will be set in made up part of city with points of interest and bike sharing stations<br />
<br />
== Data sources ==<br />
* '''Research papers:'''<br />
** https://www.sciencedirect.com/science/article/abs/pii/S2210670719319286<br />
<br />
* '''Bike sharing data'''<br />
** https://www.kaggle.com/datasets/edomingo/bicing-stations-dataset-bcn-bike-sharing/data<br />
<br />
[[User:Capj05|Capj05]] ([[User talk:Capj05|talk]]) 16:47, 16 December 2024 (CET)<br />
<br />
----<br />
: '''APPROVED''', but you deal with some very soft variables like: Willingness to walk to alternative stations, Tolerance for bicycle unavailability. It is very important to have all parameters very well justified. [[User:Tomáš|Tomáš]] ([[User talk:Tomáš|talk]]) 17:38, 20 December 2024 (CET)<br />
<br />
= Urban Traffic Flow Optimization Simulation by stej34 =<br />
<br />
== What will be simulated: ==<br />
The simulation will model traffic flow in an urban area, focusing on the effects of traffic light timing, pedestrian crossings, and road capacity on congestion and travel time.<br />
<br />
== Goal of the simulation: ==<br />
The simulation aims to demonstrate how optimizing traffic light patterns and pedestrian crossing behavior can improve traffic flow, reduce congestion, and minimize travel delays in urban environments.<br />
<br />
== Who would use the simulation and how it helps them: ==<br />
This simulation can benefit:<br />
<br />
'''City Planners:''' To experiment with different traffic light timings and road layouts to optimize urban traffic.<br />
'''Traffic Engineers:''' To analyze the effects of pedestrian crossings and road capacity on congestion.<br />
'''Environmental Researchers:''' To study the impact of traffic optimization on vehicle emissions and air quality.<br />
<br />
== Method and simulation environment: ==<br />
'''Method:''' Multiagent simulation of vehicles and pedestrians navigating an urban grid.<br />
'''Simulation environment:''' NetLogo<br />
<br />
== Variables in the model: ==<br />
<br />
'''Deterministic Variables:'''<br />
* Traffic Light Timing: Interval and duration of green, yellow, and red lights.<br />
* Road Capacity: Maximum number of vehicles that can occupy a road segment.<br />
* Pedestrian Crossing Behavior: Frequency of pedestrian crossings and their effect on traffic flow.<br />
<br />
'''Random Variables:'''<br />
* Vehicle Entry Rate: Randomized rate of vehicles entering the simulation from different entry points.<br />
* Driver Behavior: Variability in speed and decision-making among drivers.<br />
* Pedestrian Arrival Rate: Randomized arrival of pedestrians at crossings.<br />
<br />
== Narrowed Focus: ==<br />
<br />
1. '''Traffic Light Optimization:'''<br />
* The simulation will model the effects of varying traffic light timings (fixed vs. adaptive) on overall traffic flow.<br />
* Users can adjust light timings to observe changes in congestion and average travel time.<br />
<br />
2. '''Impact of Pedestrian Crossings:'''<br />
* The simulation will include pedestrian crossings that stop vehicle movement. Users can vary crossing frequency and pedestrian density to explore their impact on traffic flow.<br />
<br />
3. '''Road Capacity Constraints:'''<br />
* The simulation will explore how different road capacities (e.g., single-lane vs. multi-lane roads) affect congestion and flow under various traffic loads.<br />
<br />
== Data sources: ==<br />
<br />
'''Research Articles:'''<br />
* [https://doi.org/10.1016/j.cities.2019.03.001 Traffic Congestion and Urban Planning]<br />
* [https://doi.org/10.1080/00423114.2019.1571387 Effects of Traffic Signal Timing on Urban Traffic Flow]<br />
* [https://doi.org/10.1016/j.trpro.2016.05.003 Pedestrian Impact on Traffic Flow Dynamics]<br />
[[User:Stej34|Stej34]] ([[User talk:Stej34|talk]]) 19:02, 23 December 2024 (CET)<br />
<br />
: To make the simulation useful and allow verifying its validity, choose a real particular place and simulate the traffic situation there. '''APPROVED''' [[User:Tomáš|Tomáš]] ([[User talk:Tomáš|talk]]) 11:42, 27 December 2024 (CET)<br />
<br />
= Simulation of birds behavior by misd01 =<br />
<br />
== What will be simulated: ==<br />
This model is an attempt to mimic the flocking behavior of birds. The flocks emerge without any leader birds; instead, each bird follows the same set of deterministic rules: alignment, separation, and cohesion. <br />
# Alignment: A bird turns to fly in the same direction as nearby birds.<br />
# Separation: A bird moves away from other birds that get too close.<br />
# Cohesion: A bird moves closer to nearby birds to stay with the group (unless they are too close).<br />
<br />
These rules collectively result in the formation, dynamics, and interactions of flocks.<br />
<br />
== Goal of the simulation: ==<br />
To explore and demonstrate how simple, local interactions among individual agents (birds) lead to complex, emergent flocking behaviors without central control. The model aims to study these behaviors for insights into collective animal movement, self-organization, and to inspire applications such as swarm robotics and optimization algorithms.<br />
<br />
== Who would use the simulation and how it helps them: ==<br />
This simulation can benefit:<br />
<br />
* Researchers in Biology and Ecology: To understand how flocks form, break apart, and maintain cohesion without leaders.<br />
* Educators and Students: To illustrate principles of self-organization and emergent behavior in a hands-on, visual way.<br />
* Robotics Engineers: To design autonomous swarming systems for drones or robots, inspired by natural flocking principles.<br />
* Animators and Game Designers: To create realistic group behaviors for simulations, movies, or games.<br />
<br />
== Method and simulation environment: ==<br />
'''Method:''' Multiagent simulation<br />
'''Simulation environment:''' NetLogo<br />
<br />
<br />
== Variables in the model: ==<br />
<br />
'''Deterministic Variables:'''<br />
* Bird speed: The fixed speed at which birds move.<br />
* Perception radius: The distance within which birds can detect neighbors.<br />
* Minimum Separation Distance: The minimum allowable distance between birds before the separation rule is triggered.<br />
<br />
'''Random Variables:'''<br />
* Initial positions: Random starting locations for birds in the environment.<br />
* Initial headings: Random initial movement directions.<br />
<br />
== Agents: ==<br />
'''Turtles'''<br />
Represent individual birds.<br />
Behaviors are governed by three rules. Each of the rules contributes to adjusting the bird's heading. The final heading is a weighted combination of the three rules:<br />
* Alignment: Each bird (agent) calculates the average heading of nearby birds and adjusts its direction toward that average.<br />
* Separation: If another bird is too close (distance below a threshold), the bird moves away by calculating a vector opposite to the direction of the neighbor(s).<br />
* Cohesion: A bird moves toward the center of nearby birds unless another bird is too close (handled by separation).<br />
If another bird is too close, the separation rule temporarily overrides alignment and cohesion until the minimum separation is achieved.<br />
<br />
== Data sources: ==<br />
<br />
'''Research Articles:'''<br />
* [https://cs.stanford.edu/people/eroberts/courses/soco/projects/2008-09/modeling-natural-systems/boids.html Boids: An Artificial Life Program]<br />
* [https://www.sciencedirect.com/science/article/abs/pii/S0003347224000277 Relationship between flock size and flight initiation distance in birds]<br />
* [https://medium.com/@adityaananthram/algorithms-in-nature-part-1-e80e80b29719 Algorithms In Nature]<br />
* [https://www.pnas.org/doi/10.1073/pnas.1118633109 Statistical mechanics for natural flocks of birds]<br />
<br />
<br />
[[User:Misd01|Misd01]] ([[User talk:Misd01|talk]]) 20:41, 27 December 2024 (CET)<br />
<br />
: '''APPROVED''' [[User:Tomáš|Tomáš]] ([[User talk:Tomáš|talk]]) 20:38, 29 December 2024 (CET)<br />
<br />
=Simulation concept: Populating the database - tros01=<br />
==Why?==<br />
Lets say that I have a database containing prepared activities and educational content for boy scouts group. Its purpose is to serve as a source of inspiration and eventually of collection of high quality content appropriate for kids during our weekly meetings or other occasions. From which source should be easy to get precisely only the desired results based on defined properties on each activity (eg. time needed for preparation, minimal number of players, etc.)<br />
<br />
BUT actually its currently more like a proof of concept and not a really operational tool. So accordingly there aren't yet any real records to speak about.<br />
This very early stage of development is exactly the reason why I think it is reasonable to think about how will the database be populated with data. As this will be crucial for its future usability and success. Therefore, the simulation should focus on modeling this data population process.<br />
==What?==<br />
To be precise, the simulation will be concerned with user behavior and related volume of stored records.<br />
<br />
It is important to say that user interface for reading is only the default web gui of the database itself (Neo4j), so the users will have to use the Cypher query language. So after they go through such a way to access the records, there better be some decent amount of useful ones in the database. This is because otherwise their whole effort would be pointless and the user would be discouraged from using the database again.<br />
<br />
Creating the records on the other hand will be easy and accessible as much as possible (user writes to google document in specified folder and with specified structure which enables then loading it programmaticaly into the database). This ease of creation is key to encouraging consistent contributions.<br />
<br />
And here comes the question whether this "natural" way of data population is enough, or rather how long will it take for the database to be able to provide satisfactory results for the user in majority of the cases and as such could be called a useful tool. If the time required would be too long, the users could lose interest of even contributing new content .<br />
Therefore, the simulation will model the rate of content creation and the subsequent impact on database searchability and usability.<br />
<br />
Additionally will be also evaluated the "batch population approach" to see weather it is worth considering to implement. This will involve creating a model of user behavior and content creation, simulating different scenarios, and analyzing the results.<br />
==Objectives==<br />
This simulation aims to predict the growth of the database, determine the feasibility of the current data population strategy and evaluate the alternative.<br />
<br />
#Predict the time needed to reach a critical mass of data sufficient for effective use.<br />
#Evaluate the effectiveness of the current data population method relatively to alternative.<br />
==Users==<br />
'''Example User:''' me the database developer and admin.<br />
<br />
'''How it would help:'''<br />
*Optimizing Data Population: By simulating different scenarios, I can determine the most efficient way to populate the database with valuable content.<br />
*Resource Allocation: The results will inform decisions on whether to prioritize developing a batch upload feature or focus on encouraging individual contributions.<br />
*Setting Expectations: The simulation will provide a realistic timeline for when the database will be sufficiently populated for effective use.<br />
==Method and environment==<br />
'''Method:''' Agent-based modeling<br />
<br />
'''Env:''' NetLogo because of the class requirements. I would rather like to try (learn to do simulations with) Julia because of its broader usability, but I guess it is what it is.<br />
==Variables==<br />
===Deterministic===<br />
;amount of records in db for each category<br />
:without the batch upload the initial value is 0<br />
;number of contributors/agents<br />
:this will be based on real number of leaders in our group<br />
;batch upload size<br />
:values 0, 10, 20, 30, 50, 100 will be tried<br />
;expected probability of finding useful record by individual agents<br />
:based on previous experiences of agent with searching the db<br />
;probability that an agent will try to look up a record<br />
:will be calculated from a combination of the agent’s past success rate and the current amount of records in db.<br />
;quality of record<br />
:number from <1-10><br />
;probability of using any of the found records in the upcoming meeting<br />
:will be calculated from an amount of returned records and their quality<br />
;probability of creating new record<br />
:for the sake of simplicity and simulation feasibility the probability will be set to a constant value same for all agents<br />
;probability of improving a records quality<br />
:for the sake of simplicity and simulation feasibility the probability will be set to a constant value same for all agents<br />
===Random===<br />
;category of recorded/seeked activity<br />
:category means a certain combination of activity properties ( type{running, creative, thinking, discusion, history}, place{room, forest, city, playground}) <br />
:the category can combine max 2 types and 1 place<br />
;initial quality of created records <br />
:will be drawn from lognormal distribution with mean 3 and std 2<br />
==Simulation behavior==<br />
Each tick will represent a single week in real time, because the meeting for which are the activities prepared are realized every week once. Each agent has to prepare some activity for every meeting, so they has a choice to come up with something new or to look for usable activity or at least inspiration in the db. The agents can not use the same activity twice in a year or two.<br />
<br />
So in the beginning of each week an agent will pick a random category of an activity which they will prepare for the meeting. <br />
<br />
When the agent decides to search the db, they will be given all records currently present in db that match the category they picked. From those will be calculated the probability of using any of the records in the upcoming meeting and then evaluated. If successful, the agent will pick a random one from them (the higher the quality, the higher probability of picking it). After that, there is a chance that the agent will improve the quality of the picked record (in reality it means for example adding a feedback from the kids).<br />
<br />
If they are unsuccessful trying to find a suitable activity in the database, or they decide to not search the db at all, they has a chance of recording (with rnd initial quality) the activity that they created or found elsewhere.<br />
<br />
The simulation will then run until the majority of searches in the db are successful.<br />
<br />
And also the scenario with the initial batch upload will be simulated as well. <br />
<br />
[[User:Tros01|Tros01]] ([[User talk:Tros01|talk]]) 00:32, 12 January 2025 (CET)</div>Tros01