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.