Basically I've got a Service which can work with two alternatives of ResourceSets. Let's say, the Service would optimally work with one Doctor and one Nurse, but it is also possible to work with only one Doctor if a Nurse isn't available.
Now, assuming the Doctor works slower without a Nurse, the Service's delay time must depend upon the resourceSet being employed at the moment (Doctor+Nurse or Doctor). Any idea how can I program this?
You should also have in mind that my model has various Services in parallel working in the same way, it's not just only one Service line.
Thanks!
You're using Services but, to me, using the combination of Seize, Delay and Release gives you more flexibility.
What I've done is set the resource choice according to the image bellow:
It is important to have the nurses prior to the doctors in the first set (for some reason anylogic would opt for using only the doctor if otherwise - even with a nurse available).
Than, I would write this code:
Which means that if the agent was only able to seize one resource it will take longer (15 is just a random value).
In the delay block, I would set the processing time to agent.processTime
The topology I'm using is this:
Obviously this is a workaround and will not work for every case. You can always change the conditions you verify. I couldn't find a way to check which resource set was picked by the seize operation. If you're in a hurry this will do the trick.
Hope that helps,
Luís
Related
I am trying to simulate a manufacturing assembly process, where material items are processed following an unique line. In the quality control stations, when a failure is detected, the object is sent to the repair area (by a truckpallet) and, when it is repaired, the same resource takes it and puts it at the start of the line. Until this point, I already programmed it.
The problem is the following: when it is a repaired object, is has to follow the same conveyor but with no stops in the stations. The object must enter a station and leave it, with no delays (as the works related with the stations have already been made).
I thought the best would be to consider the difference (repaired vs. not repaired) in the Agent, but then I can't work with it in the Main agent... I have also tried alternative solutions, for example defining variables in each station 1 and consider that in the stations delays and in the following station:
triangular( 109.1*delay_bec, delaytime_bec*delay_bec, 307.6*delay_bec)
Actions - in finished process:
if(delay_bec==0){
delay_headers=0;
delay_bec=1;}
But nothing worked... Any help?
I thought the best would be to consider the difference (repaired vs. not repaired) in the Agent, but then I can't work with it in the Main agent...
This is actually the correct approach. You need to create a custom agent type, give in a boolean variable isRepaired (or similar) and then in the delay you can dynamically adjust the duration using that characteristic:
agent.isRepaired ? 0. : 100
This will delay normal agents by 100 time units and repaired agents not at all.
Obviously, you must make sure that the agents flowing through the flow blocks are of your custom agent type (see the help how to do that)
I am modeling ticket system with various SLA. The model must contain several service blocks with different reaction time ( from 2 to 32 hours). In the service block only working hours should be taken into account. So in the service block timeout should stop when non-workong hours and on the weekend. Could you please kindly tell me how i can realize it?
Thank you very much in advance!
I can think of two answers, one simplified but works in many cases, the other more advanced and probably more accurate:
Simplified approach: I would set the model in hours and keep everything running as is without any stop. So, at the end of the simulation, if the total time is 100 hours and you know that you have 8 hours/day with 5 days/week, then you'd know the total duration is 2.5 weeks. Of course, this might have limitations or might become more complex later on if you want day-specific actions (e.g. you want to differentiate between Monday, Tuesday, etc.)
Advanced more accurate approach: Create resources whose capacities are defined by schedule and assigned them to your services. Create a schedule and specify the working hours in that schedule. Check the below link to learn more about schedules. I call this the more advanced approach because you need to make sure the schedule is defined correctly and make sure all elements in the model are properly controlled (e.g. non-service blocks such as source, delays, etc.).
https://help.anylogic.com/topic/com.anylogic.help/html/data/schedule.html?resultof=%22%73%63%68%65%64%75%6c%65%73%22%20%22%73%63%68%65%64%75%6c%22%20
I personally would use the first approach if the model is rather simple and modeling working hours is enough for analysis. Otherwise, I'd go for option 2.
Finally, another option I'd like to highlight is the "suspend/resume" functions. I am only adding this because you asked "how to stop timeout". So these functions specifically stop and resume timeout. But you'll need to define the times at which they are executed (through an event for example).
Good day
I'm a new user trying to find my with Anylogic.
Any help with the following question will be appreciated.
Is it possible to start a model with initial values/quantities given to certain blocks/sections in a model? In other words not have the model start from 0 but from the values given.
You can run a "warmup" period manually and save that as a model snapshot. In future runs, you can start off from that snapshot by loading it. See the help on model snapshots
This is the general problem of model initialisation (e.g., if you're modelling a manufacturing facility, you may want the run to start with the facility at the state it would be at on 9am next Monday morning). There is no generic answer: what initialisation you need is 100% model-dependent (as is how easy/hard this is).
In particular, process models make this difficult because entities (agents) are expected to have flowed through the process up to the point they 'start' in. You can use things like extra initialisation-only Source/Enter blocks to 'inject' agents into the appropriate process points, but in most models it's not this easy: you will have all kinds of model state that needs to be made consistent with this (e.g., the agents flowing through the process might have attributes which have changed based on what's happened to them so far, so this would have to be made consistent).
That's why warm-up periods (letting the model run 'from empty' for a period until its state is qualitatively what you want as your starting point) is a common approach. Model snapshots can help you here (see Ben's answer) but they're not the only way of doing it. (You can also just 'reset' all your metrics/output gathering at the point when you determine the warm-up period has ended --- i.e., you are effectively establishing a new 'time zero' --- but, again, exactly what you need to do is 100% model dependent.)
There is a question: Is there a possibility to set tests to perform priority in selenoid.
Problem: There is a suite> 20 tests, correspondingly at startup it fills the queue. After that, another test is run. He gets to the end of the line.
Is there an option to make it run as soon as the browser is freed, without waiting for all the tests to run before it?
No, this is not possible in current implementation. All incoming requests have equal priority. Two alternatives:
I think such issues should be addressed in test framework of you choice. For example for py.test a quick search shows a plugin for ordering your tests: https://github.com/ftobia/pytest-ordering Not sure whether it works.
You could also install Ggr and use different Selenoids and quota names for different tests, but this seems to be too much complicated for your case.
(I have also posted this question at math.stackexchange.com because I'm not sure where it should belong.)
I have a system with the following inputs:
Set of work items to be completed. These are variable sized. They do not have to be completed in any particular order.
Historical data as to how long work items have taken to complete in the past. However, past performance is no guarantee of future success! That is, once we come to actually execute a work item, we may find that it takes longer or shorter than it has previously.
There can be work items that I have never seen before and hence have no historical data about.
Work items further have a "classification" of "parallel" or "serial".
Set of "agents" which are capable of picking up a work item and working on it. The number of agents is fixed and known in advance. An agent can only work on one work item at a time.
Set of "servers" against which the agents execute work items. Servers have different capabilities. Specifically, they are capable of handling different numbers of agents simultaneously.
Rules:
If a server is being using to execute a "serial" work item, it cannot simultaneously be used to execute any other work item.
Provided a server isn't being used to execute any "serial" work items, it can simultaneously handle as many agents as it is capable of, all executing "parallel" work items.
There are a handful of work items which must be executed against a specific server (although any agent can do that). These work items are "parallel", if that matters. (It may be easier to ignore this rule for now!)
Requirement:
Given the inputs and rules above, I need to execute the set of work items "as quickly as possible". Since we cannot know how long a work item will take until it is complete, we cannot possibly hope to derive a perfect solution up front (I suppose), so "as quickly as possible" means not manifestly doing something stupid like just using one agent to execute each work item one by one!
Historically, I've had a very simple round-robin algorithm and simply sorted the work items by descending historical duration such that the longest running work items get scheduled sooner and, hopefully, at the end of the cycle I'm able to keep all agents and servers reasonably well loaded with short-duration work items. This has resulted in a pretty good "square" shape to the utilization graph with no long tail of long-duration work items hanging around at the end of the cycle.
This historical algorithm, however, has required me to pre-configure the number of agents and servers and pre-allocate work items to "pools" and assign pools to servers, and lots of other horrible stuff. I now need to support a dynamic number of agents and servers without having to reconfigure things. (Note that the number of servers will be fixed during a cycle - that is, the number will only change between cycles - but the number of agents may increase or decrease in the middle of the cycle.)
Once all work items are complete, we record how long each work item took to feed in to the next cycle and start again from the beginning!