Hello, if you have any need, please feel free to consult us, this is my wechat: wx91due
CS115 - Computer Simulation, Assignment #1 – Train Unloading Dock
In this assignment, you will write a simulation of a train unloading dock. Trains arrive at the station as a Poisson process on average once every 10 hours. Each train takes between 3.5 and 4.5 hours, uniformly at random, to unload. If the loading dock is busy, then trains wait in a first-come, first-served queue outside the loading dock for the currently unloading train to finish. Negligible time passes between the departure of one train, and the entry of the next train (if any) into the loading dock---unless the entering train has no crew (see below).
There are a number of complications. Each train has a crew that, by union regulations, cannot work more than 12 hours at a time. When a train arrives at the station, the crew’s remaining work time is uniformly distributed at random between 6 and 11 hours. When a crew abandons their train at the end of their shift, they are said to have “hogged out”. A train whose crew has hogged out cannot be moved, and so if a hogged-out train is at the front of the queue and the train in front finishes unloading, it cannot be moved into the loading dock until a replacement crew arrives (crews from other trains cannot be used). Furthermore, a train that is already in the loading dock cannot be unloaded in the absence of its crew, so once the crew hogs out, unloading must stop temporarily until the next crew arrives for that train. This means that the unloading dock can be lie unused even if there is a train in it, and even if it is empty and a (hogged-out) train is at the front of the queue; in both of these cases we say the loading dock is “hogged-out”. More specifically, the loading dock is hogged out if there are any trains in the queue but the loading dock is not actively unloading. (A bit of thought should convince you that trains in the queue behind the one at the front do not affect the hogged-out status of the unloading dock.) In other words, the loading dock can only be called “idle” if no trains are present.
Once a train’s crew has hogged out, the arrival of a replacement crew takes between 2.5 and 3.5 hours, uniformly at random. However, due to union regulations, the new crew’s 12-hour clock starts ticking as soon as they are called in for replacement (i.e., at the instant the previous crew hogged out); i.e., their 2.5-3.5 hour travel time counts as part of their 12-hour shift.
You will simulate this system for 1 million (1,000,000) hours (plus the time it takes for all remaining trains to depart), and output the following statistics at the end:
5. A histogram of the number of trains that hogged out 0, 1, 2, etc times.
Input Specification: We will run your code, but to make it easy for the grader, we need everybody to adhere to the following guidelines: create a makefile that builds your program (if necessary), and your program should take either two or three command-line arguments. When given three arguments, the first argument should just be “-s”, your program should read the second argument as the file path to the pre-determined train arrival schedule (described below), and it should read the third argument as the file path to the pre-determined travel-times for new crews (also described below). When only given two arguments, the first argument must be the average train inter-arrival time, and the second argument must be the total simulation time. Thus, for example, if your program is written in C and compiled to an executable called “train”, then to run it with the default parameters above, I should be able to run it on my Unix command line as:
That will allow the grader to run your program using the same syntax as above:
target: ;
The pre-determined train arrival schedule contains three space-delimited columns: inter-arrival-time, unloading time, and remaining crew hours (in that order), with each arrival event on a new line:
When using a pre-determined schedule and there are no more train arrivals scheduled, end the simulation after the very last train has departed; when using random values, stop adding arrival events after the total simulation time has passed as specified by the command arguments (e.g., at 1,000,000 hours), but don’t stop the simulation until the last train has departed.
Output Specification: Your program should print one line for every event that gets called. We want to be able to follow what’s happening in your code. Each train and each crew should be assigned an incrementing integer ID . The final statistics should come after the simulation output and closely match the specified format. Output lines should resemble the following example (lines have been split here just for human readability but shouldn’t be in your output):
A script to automatically check the output formatting is provided to give feedback on I/O specification compliance. The script is on openlab in the directory /home/wayne/pub/cs115/A1- syntax-checker; the same directory contains sample output, plus my own executable (though its output format has debugging info that produces more output than the spec wants). To test your program’s input and output, you can run one of the following commands, ensuring that you are located in your own directory containing your train executable. Note that the format checker takes no arguments: instead, it expects to read the output of your program on its standard input stream (look up that term if you’re not familiar with Linux/Unix). Thus, you could use a pipe as follows, assuming your program is in the current directory and is run starting with the command “train” (though other reasonable possibilities include “train.sh” or “python3 train.py”):
$ ./train 10 1e6 | ~wayne/pub/cs115/A1-syntax checker/train_format_checker.py
Submission: Submit a brief write-up of your results on GradeScope.com, along with your source code and specific sections of the output (only the first few pages and the last few dozen lines containing the statistics) for the default parameters. There should be no more than 10 pages. Be sure to also submit the PDF, along with your source code, electronically via the submit command on ICS openlab (see syllabus for details on the submit command).
Your code should be “pretty”, which means easily understood and maintainable by another programmer. This is of course subjective, but it should be well indented, and well commented inside, such that, if we were fellow employees and I had to change your code, I wouldn’t be cursing your birth after several hours (or days) of trying to figure it out. It should be easy-to-read; the variables should have meaningful (but not overly verbose) names; the comments should clarify tricky points but not obvious ones. (I’ve seen the comment “add one to x” beside “x++”; that qualifies as an unnecessary comment. A better comment would tell us WHY x is being incremented, if it’s not obvious.) The prettiness (i.e., understandability, readability, and maintainability) of your code, by the grader’s judgment alone, will count as 25% of your grade.
Your code should be correct. We will judge the correctness of your code both by reading it, and based on tracing its output events and final statistics. Correctness of the traces and the output will count for 50% of the grade. The write-up will count for the remaining 25%.
Notes from problems running codes from previous years (READ THIS if you use Python):
If I email you to ask for help running your program, please don't tell me to "pip install" something; doing that makes my life harder; experience shows that if I "pip install" something to allow your code to run, then some other student's code will break. Please use "module load" appropriately as above, and also add the appropriate "module load" commands to your shell script so I don't have to do it manually.