Due date

11:59am on 31/03/2023 (Friday of Week 8).

Mark scheme

• The full mark for the project is 25. The allocation of the marks is as follows: Task 1: 70%; Task 2: 30%.

• A breakdown of the marks for Task 1 is as follows:

– 45% for the formulation.  Of this, 60% is given to correct mathematical expressions and 40% to clear and correct explanations in a layman’s terms. Partial marks will be given to correct expressions and/or explanations even if the formulation is not completely correct.

– 15% for the AMPL code. The code is marked for its correctness and its consistency with your formula- tion. The code is considered correct only if it reflects the formulation accurately and the formulation is correct. Partial marks will be given for correct parts even if the code does not run as a whole. The style of the code does not matter.

– 5% for results and the discussion.

– 5% for the flow and coherency of the overall narrative of the report. The report should be more than a collection of equations or a list of bullet points. Necessary transition and/or motivation should be included.

• As Task 2 is open-ended, everyone can choose to do it in their own ways. Therefore it is impossible to give a detailed breakdown for the marks. However, the following principles will be applied:

– Since Task 2 is given 30% of the marks, the work you put in to answer it should be roughly 30% of the work you put into the whole project.

– I expect broadly all answers would contain elements of modelling, and elements of coding, computa- tion and data analysis. Therefore the best answers usually will have met three criteria: (a) they deal with novel ideas which involve modelling issues as challenging as those in Task 1; (b) they contain well thought-out numerical experiments and thorough data analysis which lead to some new insights; and

(c) they contain sufficient work.

– A good answer will have met one or two of the three criteria stated above, or contain good attempts to meet all. An answer exploring multiple relatively obvious ideas would be considered as a good answer if sufficient efforts are demonstrated.

– A bad answer would be one where no real efforts have been made to meet any of the criteria.

• If you contribute truly exceptional original discussions (e.g., in Task 2), extra marks will be awarded to compensate for the loss in other places if necessary.

• The report should not be more than 4 pages long on A4 paper (with reasonable margin, font sizes, and line spacing). There is no limit on the length of the codes.

General advices on writing the report

• Explain the mathematical formulations fully. The formulation should include the definitions of the variables (why do we need this variable? How is it defined?), the calculations you judge to be non-trivial in the context of the project, and the meaning of the constraints and the cost function explained in layman’s terms. Typeset the equations properly.

• Always support your discussions or arguments with sufficient data. When necessary, corroborate an asser- tion with several pieces of data. This is important to convince the readers (and yourself) that the results are correct and the data are not faulty.

• When you present your results, think how to make it easier to understand.

• Think of it as a scientific paper or a formal technical report to your supervisor. It means you need to use a  more formal tone, with proper punctuations that sometimes might be skipped in informal communication.  As an example, instead of‘do’, you may want to use‘conduct’or‘perform’or other similar words. When  we have to refer to the author (in this case, yourself), we usually do not use‘I’or‘me’. Rather, we use‘we’ and‘us’, even if you are the sole author. You may also use‘this author’, or use passive voice instead.

• Your failed attempts might be interesting.  However, what matters the most (and what your supervisor cares) is the final correct results. Therefore, it is OK to write about failed attempts, but it should not be a main part of the report.

• More suggestions can be found from the Internet - for example:

http://www2.le.ac.uk/offices/ld/resources/writing/writing-resources/science

Debugging tips

If you have trouble with your code, it means the code has‘bugs’. The following are a few tips on how to‘debug’:

1. Pay attention to the small things: keywords and commands are case sensitive; do not forget the semi-colon at the end of a statement; do not use British spelling for the keywords.

2. Read the error message. It usually gives you the line number where the first error is detected, sometimes also the nature of the error (although its meaning may not be obvious). The code usually stops at the first error so there would be only one error message. But if the code throws out several messages, start from the first one, because the other errors may disappear after the first one is fixed.

3. Starting from the line reported in the error message, check backwards: check that line, then check the line immediately before (sometimes the error is caused by the line before - most commonly by missing the semi- colon at the end of the line); then check the definitions of all variables and parameters involved in these two lines; and so on.

4. If you are not sure about some commands or keywords, a good idea is to write a simple code to test them.

5. If you could not find any mistakes in the code, and the code did generate some results, but the results did not make sense, then you should check your formulation. Is the cost function correct? Are there any constraints missing? And so on. You may use examples in notes, handout, lab sheet, examples sheets and anything you can find to help.

6. Another useful debugging trick is to try different values for the parameters of the problem, and see if the changes in the solutions make sense.  You can often predict how the solution should change by common sense. For example, if you tighten a constraint, you should not expect the optimal solution to be improved. This trick is equally useful for debugging code and formulation.

7. If you are really desperate, do not hesitate to ask. I can help correct the coding mistakes. For questions about the formulation of the problems, I will usually direct you to relevant parts of the notes or example sheets or other possibly useful references.

1 Optimal Allocation of Operating Theatres

Description of the situation

The allocation takes place in a Sheffield hospital where the use of health resources, particularly operating theatres, must be controlled effectively.  The hospital has 10 staffed operating theatres serving 6 departments:  surgery, gynaecology, ophthalmology, otolaryngology, oral surgery and emergency. There are 8 main surgery theatres and 2 elective outpatient surgery (EOPS) theatres.  An operating theatre is either‘short’or‘long’, depending upon the daily number of hours the room is available. Because of the socialized nature of health care, all surgeries are scheduled during work days only (Monday through Friday).

Table 1 summarizes the daily availability of the different types of operating theatres and Table 2 provides the weekly demands of operating theatres in terms of hours. The numbers of underallocated hours for each depart- ment can not exceed the maximum numbers given in Table 2.

Table 1: Surgery Room Availability

Table 2: Weekly Demand for Operating Theatres Hours

Let

uj = maximum number of underallocated hours allowed in department j

hj = requested weekly target hours for department j

xijk = number of rooms of type i assigned to department j on day k

In other words, xijk represents the schedule of the rooms. Our goal is to find an optimal solution for xijk .

Your tasks

1. As a first attempt, we assume that, if a room is assigned to a department, it will be occupied by that depart- ment for the whole day. As a result xijk is an integer. The ideal solution would satisfy exactly the weekly target hours for all departments. However, we recognise that it may not be possible. Therefore, we intro- duce sjto denote the difference between the target hours and the actually allocated hours for department j, i.e.,

sj = hj− the actually allocated hours for department j,

and decide that our objective should be finding a schedule xijk that minimizes the total relative under-allocation of all departments. We observe that, positive sjrepresents under-allocation, whereas negative sj represents over- allocation. Thus, when sj ≥ 0, the ratio sj/hjmeasures the relative under-allocation for the jth department.