Hello, dear friend, you can consult us at any time if you have any questions, add WeChat: THEend8_
COMP4038
A good conceptual model structure for the report looks like this: • Brief problem statement • Objectives, including performance measures (where appropriate) {in an optimisation experiment this might be the objective function, and perhaps a more general objective} • Any other constraints {not captured in the objectives} or requirements • 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 potential candidates that could be considered as part of the system; level of detail only considers the components that are within the scope and describes how (at what level of abstraction) these components are going to be considered} {use screen shots of tables to save words } • Assumptions (facets of limited knowledge or presumptions) {all assumptions should be listed here, including a brief justification} • Simplifications (facet of the desire to create simple models) {all simplifications 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 class and state charts for agents etc., whatever is related to the design of your system} • Data requirements {remember to also mention "data requirements" in your conceptual model (see Lec03A slide 37)} For more details, read Stewart Robinson's book or his papers Implementation • Make sure your implementation matches your conceptualisation; if not (e.g. your model implementation is a simplified version of your conceptual model), provide a good reason for it or consider updating your conceptual model (stating that you excluded certain elements or features, e.g. due to time pressure or complexity). • In the report: o Please provide a short opening paragraph followed by one (or more) screenshot(s) of your implementation 2/4 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 passenger 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 passenger numbers using current staffing levels. 3/4 • 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; we will have a look at this on Thursday • 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. Video • I personally use "Apowersoft Screen Recorder" for producing videos, as it produces videos in a decent size, but there are many alternatives available on the internet • You should record video with sound, showing and explaining features and the running simulation and optimisation. I showed you an example of such a video in Lecture 01A. Please note that we will use the video during the marking process, so promote your work (perhaps with a summary of highlights at the end) Submission • Please submit the following three files: 1. A written report in pdf format (approx. 2500 words +/- 10%) 2. A zip file including your AnyLogic model(s) and other relevant files to allow us to reproduce your experimental runs 3. A demonstration video (4 minutes +/- 0.5 minute, maximum size: 100 MB) Random Collection of Information, Tips and Tricks • Remember the KISS principle and start your implementation with a rapid prototype • Remember that the simulation life cycle has arrows in both directions; in case of the coursework come up with some draft objectives and fine-tune them later (as we do not have a client that provided us with the details) • It is always good to find some real-world data online, but it's not always possible; for missing data try to remember your last trip and use some assumptions based on this. If your assumptions are reasonable (you could briefly explain how you came up with them), everything is fine.