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.