Resource
A resource is anything limited that work has to wait for. Use one when several steps share it, or when you want to see its utilization.
What it is
A resource is a pool of identical units that entities hold while they work, such as nurses, forklifts or operating rooms. Resource capacity is the number of units. Resources arrive at the Intermediate view.
The question it helps answer
Do we need another person, or is the constraint somewhere else? Resource results show utilization and how long work waited, so you can test adding a nurse before anyone hires one.
How it behaves
A resource doesn't sit in the flow. Activities use it through a resource requirement, which says what's needed. A requirement reads as a sentence:
- Needs 1 Nurse.
- Needs 1 Nurse and 1 Doctor. Use + also needs… to add a line.
- Needs 1 Doctor or 1 Resident. Use + or… to add an alternative.
An entity gets a requirement whole or not at all. It waits until everything is free at once, so it never ties up the nurse while waiting for the doctor. Where there are alternatives, it takes the first that fits.
Waiting entities are served longest wait first, unless an action's Priority says otherwise. Higher Priority wins, and ties go to whoever has waited longest.
Actions control how long a resource is held.
- A Delay with a Requirement gets the resource, takes its time, and gives it back.
- Seize Resource and Release Resource hold it across several actions, or several activities.
Anything still held is released when the entity leaves the model. See Actions.
A resource keeps working on whatever holds it. A higher Priority decides who goes next, but it never takes a resource from an entity that already has it. If the activity breaks down while an entity holds a resource, the resource stays with that entity through the repair. It counts as in use and is charged at the utilized rate, because it can't go anywhere else.
An entity needing several resources takes them all at once or waits holding none of them. While it waits, it keeps its place in line for each one, so a stream of small requests can't starve a big one, even if some of what it needs is free.
A resource still held when the run ends counts as in use up to the end, and that time is charged. Hold time, per capture, averages only the holds that finished.
A Release with no Requirement frees everything the entity holds, and releasing a Requirement it doesn't hold does nothing. A Dispose, Split or Join frees what the entity holds at that moment, ahead of it leaving the step. So when a resource comes free, an entity already queued for it goes before one whose Delay ends at the same instant, even a higher-priority one.
Seizing a Requirement the entity already holds takes nothing more. Resource totals count units, so a Requirement for 2 units counts as 2 requests, 2 captures and 2 releases.
Priority on an action decides who goes next. Priority inside a Requirement decides something else: which alternative an entity tries first.
You can tie a resource to a shape on your diagram, or keep it only in the model's list. It simulates the same either way. Only a resource linked to a shape shows in animation.
Properties
You can create a resource in two ways from the Intermediate view: use Add Resource on the Model editor's Resources tab, or set a shape's Type to Resource. A shape then offers to link to an unclaimed resource or create a new one. Each resource links to one shape or lane at most.
Once a resource exists, its Basic, Financial and Levers tabs show in every complexity view. Follow a schedule is the exception: it needs the Advanced view.
Resources list
| Item | What it does |
|---|---|
| Add Resource | Opens a short form with Name and Capacity. If the name is taken, Quodsi makes it unique. You can also type name: Nurse | capacity: 3 in Name, and that capacity wins over the Capacity field. |
| Capacity | Shows the resource's capacity in its row. |
| Shape status | Shows the linked shape, lane · not animated, or no shape · not animated. Only a resource linked to a shape appears in animation. All three simulate the same. |
| Edit | Opens the tabs below. Back to Resources returns to the list. |
| Delete | The only place to delete a resource. It shows what will change first. Requirements that can no longer be met are deleted, delays that used them become plain delays, and you choose what happens to Seize and Release steps. |
Basic tab
| Property | What it does |
|---|---|
| Name | Names the resource in results and requirements. A name another resource uses shows an inline message, and validation flags it. |
| Capacity: Fixed capacity | The number of units, which is the most that can be held at once. Default 1, minimum 1. Used for the whole run. |
| Capacity: Follow a schedule | Advanced view. Takes capacity from a work schedule instead. If the model has no schedule, Quodsi creates one with a Monday to Friday day shift at the current capacity, and opens it. If it has several, Quodsi links the first and tells you. |
| Work schedule | Shows while following a schedule. Picks which one. A link to a deleted schedule shows as Missing schedule, and validation reports it as an error. |
| Edit schedule | Opens the linked schedule. Other resources and activities following it change too. |
| New schedule | Creates a schedule, links it and opens it. |
| Nominal capacity (for reporting) | Shows while following a schedule. It doesn't change the run. It's what nominal utilization divides by, so use it to say what fully staffed means. Linking a schedule raises it to the schedule's highest capacity if it was lower. |
If a model follows a schedule and you're not in the Advanced view, the option shows disabled, and the schedule still applies.
Financial tab
The rates are per hour whatever time unit your model uses, and each one charges per unit of the resource. None can be negative.
| Property | What it does |
|---|---|
| Enable Financial Tracking | Default off. While it's off the rates below are kept but hidden, and this resource costs nothing. |
| Cost Per Seize | Charged for each unit each time it's acquired, however long it's held. Two units seized together cost twice this. Default 0. |
| Cost Per Hour Utilized | Charged for each unit for as long as it's held. Two units held for an hour cost twice this. Default 0. |
| Cost Per Hour Idle | Charged for each unit that is available and not held. Three idle units for an hour cost three times this. An off-shift unit isn't idle, so it costs nothing. Default 0. |
Levers tab
| Property | What it does |
|---|---|
| Capacity | Marks capacity to vary in what-ifs. Hidden while the resource follows a schedule, because the schedule sets capacity. |
| Cost per seize, Cost per hour utilized, Cost per hour idle | The same, for each rate. These show once financial tracking is on. |
A lever you've already saved keeps its row, greyed with the reason, if its setting stops applying.
Requirements
Requirements are in the Model editor's Resources tab, in the Requirements section, and in any action's requirement field. They say who and how many each step needs. A requirement's name fills in from its sentence until you type your own. Editing one used by several actions offers Save for all, or Save as a copy for this step.
Example
A clinic has three nurses shared between Triage and Discharge. Add a Nurse resource with Capacity 3. On both activities, add a Delay and set its Requirement to Nurse. Now each nurse can work either step, and a surge at Triage will slow Discharge. Add a lever on Capacity to compare three nurses against four.
Common mistakes
- Assuming capacity alone reserves anything. A resource does nothing until an action uses it. Validation warns you about an unused resource.
- Raising activity capacity and keeping one resource. Two exam rooms and one nurse still see one patient at a time. Check which limit binds.
- Forgetting a Release. A Seize holds until something lets go. See Activity.
- Asking for more units than exist. A Requirement for 3 units of a 2-unit resource could never be met, so validation stops the model. With a work schedule, the limit is the schedule's highest capacity.
- Sharing a resource between parts of one Requirement. Alternatives are chosen in order, and a choice isn't revisited. A Requirement for (A or B) and A, with one unit of A, takes A for the first part and then waits forever for a second A, even though B would have worked. Nothing warns you, and the entity simply never gets served. Put the alternative that can't conflict first.
- Two entities each holding what the other needs. If one holds the Doctor and wants the Nurse while another holds the Nurse and wants the Doctor, neither can go on. The run ends with a deadlock error naming them, and it has no results. Seizing everything in one Requirement avoids this, because it's all or nothing. If a shift still has capacity to give, it isn't a deadlock, only a run that ended first: you get the results, with those entities in progress.
- Reading utilization alone. A resource at 75% can still have long queues when arrivals bunch. Check waits as well.
- Deleting without reading the prompt. Deleting a resource changes the steps that used it. Delays become plain delays, and you choose what happens to Seize and Release steps.