COMP4038 Coursework 2 Tips v2024-03-28
A good conceptual model structure for the report looks like this:
• Brief problem statement
• Objectives, including specific constraints/requirements {consider defining one for a simulation experiment and one for an optimisation experiment}
• Any other constraints or requirements {not captured in the objectives}
• Experimental factors (Inputs) {make sure they are related to your objectives}
• Responses (Outputs) {make sure they support you to test if you fulfilled your objectives}
• Content (defining model scope and level of detail) {scope captures all candidate components that could be considered as part of the system (i.e. included and excluded ones); level of detail only considers the components that are within the scope (i.e. included ones) and describes how (at what level of abstraction) these components are going to be considered} {use screen shots of tables to save words} {Scope table requires justification, LOD table comments}
• Assumptions (facets of limited knowledge or presumptions) {all assumptions (including the Scope and LOD table ones) should be listed here, including a brief justification}
• Simplifications (facet of the desire to create simple models) {all simplifications (including the Scope and LOD table ones) should be listed here, including a brief justification}
• Graphical representation and short explanation and justification of design decisions {you might want to represent the process flow of the overall system and some details like classes and state charts for agents etc., whatever is related to the design of your system}
Building a simpler model
• Your conceptual model can be more ambitious than your actual implementation
o You can state that you are implementing a first prototype of the conceptual model where not everything is considered. If you want to do that, add a paragraph at the end of the conceptual model section, providing some information of what you are leaving out.
o Simplifications listed within the conceptual model should relate to the full model rather than the prototype. Simplifications related to the prototype should be listed in the added paragraph.
Objectives
• Simulation: Objectives must be clear and concise (a short sentence stating the objective and related constraints where appropriate).
Objective: Ensure that x% of customers are served in y minutes, subject to ...
• Optimisation: Objective includes objective function s.t. constraints (can relate to the
definition of the solution space and for filtering the solutions found). Provide a mathematical formulation with a brief explanation of the objective.
Objective: The optimisation would … so that … while …
Minimise: Σ …
subject to a ≤ …
b ≤ …
where a = number of …, b = …
• In AnyLogic they are separated into constraints (checked before a run to define the solution space) and requirements (checked after the run to filter the solutions found)
Implementation
• Make sure your model implementation matches your model conceptualisation (either the full version or the prototype).
• In the report:
o Please provide a short opening paragraph followed by one (or more) screenshot(s) of your implementation
o If your implementation is very complex, you should just provide a summary of the highlights (the things you are proudest about regarding your implementation).
o If you have written lots of Java code, it would be good if you say a few words about the Java code you wrote, again focusing on the highlights (and perhaps present the pseudocode for the most relevant algorithm(s)).
• In your simulation model:
o Provide some meaningful graphical representation (diagrams) at least of some of your outputs
• When you implement your model, please use the following diagram for help
• Use AnyLogic Help (tutorials; demo models; example models) before asking us
o For defining shift hours, the Schedule element provided in AnyLogic might be very handy; you can find some help in AnyLogic "AnyLogic Help / Defining Model Logic / Schedules" and here in particular "Weekly Schedule" to define the schedule and "Schedule API" to access/change schedule variables.
Experimentation
• Creating a base case: As we do not have a real world case, you might find it tricky to create a base case (representation the current state of the system) for your simulation experiments. The trick to run some experiments with estimated realistic data and parameter settings (where realistic means e.g. "time in system" in minutes rather than seconds). Tune data and parameters until you get a scenario that works (you could use a parameter variation experiment if you want to do it professionally or just trial and error). When you get a scenario that "just" works, break it by changing the parameter settings slightly and you will have a base case of a student service provider that is experiencing some issues. If you only focus on optimisation and are trying to improve a system that is not experiencing any issues, you could skip the last step.
• Varying arrival rates: Regarding arrival rates, you might want to allow the user to set it up (this could be overall expected arrival rate per week or so). Future customer numbers are very likely to rise (I am sure you could find some evidence for this online) . One might want to test if the system can cope with these rising customer numbers using current staffing levels.
• Interactive simulation: Adding sliders to your classes to vary parameters during runtime: If you think there is something a user should have control over in the simulation experiment during runtime you could add some sliders; it is relatively straightforward. It depends on if you want to market your model as an exploratory tool or a predictive tool.
• Number of decision variables: The PLE edition of AnyLogic only allows 7 decision variables. If you create more, you get an error message when running the optimisation. There are different ways of dealing with this.
o Reduce the number of decision variables
o Use an external optimiser (e.g. HeuristicLab); we will have a look at this on Thursday
o If you like a challenge (I did not try this but my colleague Dario mentioned it as one potential solution at some point) you could encode the solution as a bit string; different sections of the bit string could represent separate decision variables; this way, a single integer could represent multiple decision variables; however, a decoder would need to be implemented to perform. the conversion from integer to bit string
o If you like an even bigger challenge, implement your own optimiser in AnyLogic
• Optimisation experiment running slow: If your optimisation experiments are running extremely slow, you might want to consider using a rapid prototype version of your model for running these. It should have relevant functionality for running the optimisation experiments, but nothing else. You can then submit two models - the full version for getting good marks for presentation and the simplified version for allowing to re-run the optimisation experiments.