I am new to PD. I have created a POC model and have some questions on how to solve the unwanted effects my simulation runs.
I have attached my model to help explaining my issues. Please run the simulation for 30min to notice the 3 problems listed below.
What I am trying to do: Agents walk though the checkpoints (1). Agents proceed to the Waiting1 and wait. Agents wait until capacity reach 100 (2), then all the "approaching and waiting" agents in Waiting1 proceed to Waiting2. Once the first wave of agents get release/trigger in Waiting1, change the activity time of Waiting1 from -1 to 0. New generated agents will not have to not have to wait in Waiting1 after the first 100 agents. As the agents walk from Waiting1 to Waiting2, they need to cross through the one-way passageways (3). Agents wait in Wait2 for 3 minutes then finally proceed to exit.
1) How do I make sure all agents approach the indicative corridors to pass the checkpoints, pick the least busies lane.
2) How do I trigger the ALL agents (waiting or approaching) in waiting1 to move to next activity step when the capacity in Waiting1 reaches 100? Rightnow, I setup as a timer in the Availability List, but is not what I want to do.
3) When agents walk from Waiting1 to Waiting2, they pick only the middle passageway. I would like the agents to spread out and pick other available passageways.
Sorry for many questions, looking to hear from you soon.
- Show Opening.mod
- (369.29 KiB) Downloaded 4 times
Happy to see new users of PD. Thanks for attaching the model, I must say that you learn fast! I have attached your model with some modifications to try to solve your issues/challenges.
1) In order to distribute agents through queues, an option is to use an action line before the queues. You first need to set a group in the activities (checkpoints). In this case I wrote "Security". Then in the action line, I used a predefined code which every time an agent crosses the line checks which is the less busy queue and sends the agent there. You just need to adapt the group name in the code (already implemented).
2) The best way to do this is to use the entry trigger of your activity (waiting 1). This code is executed every time an agent enters your activity. The code simply checks how many agents are in the activity, and if there are more than 100, it triggers all waiting and approaching agents.
3) A way to solve this issue is using a flow splitter (implemented in the model). An other solution could be using use local obstacle instead of passageways with connected walkable areas. Local obstacles do not modify the ECM network.
If anything is not clear enough or you have other questions, please let me know.
- Show Opening _ V.1.mod
- (383.92 KiB) Downloaded 4 times
I see you added a script in Wait1 Entry Trigger to do an agent count and trigger the logic when > than 100. that's great.
However, I broke your script when i changed Wait1 a little bit. I want the agents to wait in "front of the line" in Wait1. So I change the parameter of Location Approaching to Random Point on a Specific Line. This logic seems to break your script and does not trigger the >100 logic, i think. Do you know why? How would I make this work?
Also there was a question that I did not ask clearly in my last post, I hoping you can help me again. After the first 100 agents get triggered to move from Wait1 to next step (Waiting2), I would like Wait1 Activity Time to change to 0 (let me know if there is a better way). Any agents enter Wait1 afterward do not have to wait in Wait1 and can proceed to Wait2 immediately. Basically, I want to trigger one time only and after that, agents approaches to Wait1 do not have to wait to proceed to next activity.
- Show Opening V1.1.mod
- (384.3 KiB) Downloaded 5 times
Please find attach the model with few modifications.
If you use front of line in the location approaching in this example, there is no space for 100 agents. Then the agents which do not fit keep trying to approach the line and they are not counted as one of the 100. Thus, as the content is always smaller than 100, the trigger never happens. To solve this, you could make the line bigger. If not, another option is to include a location deviation (see model). Before, agents are forced to be exactly in the position assigned. By giving a location deviation, you allow a deviation in the final destination. This helps to fit all 100 agents. Remember also to toggle to store approaching agents option in the activity location GUI in order to successfully trigger agents - see screenshot-
Regarding your second question, an easy solution is using user table (Modelling tab). There you can define a table that always on reset turns the value to 1. Then, in the trigger code of your wait 1 activity, you can change the value of this table when the trigger happens. Finally, in the agent activity input, you can set that wait 1 activity is only taken into account when the table has a 1 (precondition) -see screenshot-. Another easy solution is work with labels.
Please let me know if something is not clear!
- Activity.PNG (41.22 KiB) Viewed 108 times
- AcitivityLocation.PNG (26.91 KiB) Viewed 108 times
- Show Opening V2.mod
- (387.88 KiB) Downloaded 4 times
Your help is extremely valuable. Thank you very much.
As for the waiting in front of the line in Wait1, I find the location deviation is not exactly clean but it did solve my current issue. I am wondering if there a better approach/option to this?
I would like to propose a solution for your question with holding 100 agents at the activity border.
Please, find the modified model attached to this post.
There have been few changes.
Now the agents are waiting in the queue before the activity, not at the activity itself.
To implement this, Waiting1 activity from the beginning has activity time = 0, and the Reset code (tab Location of Waiting1 GUI) sets the activity to "Unavailable" at each reset of the model. Also, Waiting1 now uses Indicative corrdor_5 as a queue (you can see this on the Waiting1 GUI tab General).
Indicative corridor_5 stops the agents due to unavailability of Waiting1 (see Indicative corrdor_5 stopping condition). All agents are waiting here until their total number is 100. You can find this condition in the entry trigger of this Indicative corridor. As soon as the number of agents in the queue reaches 100, they are released and the approaching agents are not stopped anymore.
Also, I have added a Flow splitter element in order to distribute agents more evenly in the Indicative corridor_5.
Please let me know if something is not clear or you have more questions.
- Show Opening V1.1_Solved.mod
- (395.1 KiB) Downloaded 5 times