using TimeSeries for capacity

[Ton D]

Dear Harry and Harvey

I have a Resource called ServerPool with capacity that fluctuates over time. I use a TimeSeries object called TimeSeriesStaffing to define its capacity:

ServerPool    Capacity    { [TimeSeriesStaffing].PresentValue }

From the simulation output I found out that the epochs where TimeSeriesStaffing changes value are not included in the event list. This results in unexpected behavior in the following setting: (I know the example is silly, but I'm trying to make a point)

Suppose I model a service operation with 1 permanent worker and 8 additional workers between 12pm and 1pm. Suppose there are 5 small jobs with a service time of 10 minutes in the queue at 12pm, that there are no arrivals between 12pm and 1pm, and that the permanent server is working on a single massive job between 11am and 3pm. I expected the extra workers to grab the 5 jobs from the queue at 12pm, and thus empty the queue. However due to a lack of events the queue length is reported incorrectly.

Perhaps I can fix this by creating an artificial EntityLogger object and make sure it logs at all the time epochs where TimeSeries changes, since I assume that puts those epochs in the event list. But then the simulation output would depend on whether or not I have such an EntityLogger object, which would be unnatural.

Regards,
Ton

[Harry King]

Ton,

It's a bit complicated to get the Seize objects to respond to rapid fluctuations in Resource capacity.

At present, a Resource's capacity is checked only when an entity seizes or releases a Resource. This means that an increase of capacity will not be used to begin clearing the queue until an entity releases a Resource unit or a new entity arrives in the queue. This limitation is okay as long as the changes in capacity occur slowly compared to the time scale over which Resource units are seized and released.

Is the ability to respond immediately to changes in capacity a feature that you need for one of your models?

Harry

[Ton D]

Hi Harry

That's a nice way to summarize how JaamSim checks the resource capacity. There are several posts on this forum on setting resource capacity using TimeSeries so I think this discussion is important. My example was extreme in that JaamSim didn't "detect" the extra capacity on my sample path, but this issue arises any time new resource capacity comes online: JaamSim responds to the extra capacity only at the first epoch an Entity is seized or released... which is sample path specific.

When I wrote my model I assumed that JaamSim would respond immediately to changes in capacity and that's important for my model. The extent to which this is a problem depends on the specific model and it may very well be minor for most users, but I would argue that there is a gap between the model specification and JaamSim's output.

In my case, I specify a TimeSeries "exogeneously". Is there a workaround in that case? Even if so, this issue may be more broad... I have no idea what kind of "endogeneous" TimeSeries users may use, but I can imagine capacity moving from one Resource to another Resource, perhaps as a function of the queue lengths at the respective Resources. In that case it could be very important to reflect changes in capacity immediately (and it would also be important to be able to specify what should happen to preempted jobs, but that's a different topic...).

Ton

[Mark]

Ton,

Here's the standard workaround used in practice in most languages where variable resource capacity is not possible. It sounds like it should work here because of the resource capacity changing based upon seizing and releasing:

1) Initialize the resource capacity to be a number much higher than anything you will ever need in your model.
2) Create a new source that spawns dummy entities with the highest priority so they always jump to the front of the queue.
3) At time 0, produce a bunch of resource-grabbing entities that seize the surplus resource capacity.
4) Your TimeSeries is exogenous, so schedule a new resource-grabbing entity to be created whenever the resource capacity decreases, and give it a delay time attribute that corresponds to a later time when the resource capacity increases again - that way it releases at just the right time.

[Mark]

NOTE: I haven't played much with preemption in JaamSim, but if preemption is possible (I think I remember it being discussed on the forums a while back - can't remember if it was implemented or not) you should be able to use this method to specify preemption logic as you would with any other queue.

In my mind, you have the following setup:

Normal_Source --> Seize_Resource-->Branch_on_Normal_vs_ResourceGrabbing_Type--->Regular_Delay--->Release_Resource-->Sink
/ \ /
ResourceGrabbingSource \--->ResourceGrabbingDelay

In case that ASCII art graphic doesn't display properly, the trajectory for each entity is as follows:
Normal_Entity:
Normal_Source -> Seize_Resource -> Branch_on_Normal_vs_ResourceGrabbing_Type -> Regular_Delay -> Release_Resource -> Sink

ResourceGrabbingEntity:
ResourceGrabbingSource -> Seize_Resource -> Branch_on_Normal_vs_ResourceGrabbing_Type -> ResourceGrabbingDelay -> Release_Resource -> Sink

This will also work for the endogenous TimeSeries case, it just needs 2 changes:
1) Creation of entities is handled dynamically by a signal (not sure if JaamSim currently supports this, but it would be nice to have).
2) ResourceGrabbing entities wait at an entity gate rather than a Delay object, thus allowing them to be released on-demand by a signal to
increase the resource capacity.

[Mark]

Also for the endogenous TimeSeries case, if entities cannot be generated from a source on-demand by a signal, you could just have a second entity gate right after the ResourceGrabbingSource and generate ResourceGrabbing entities at a rate such that one will always be available when you need it to decrease the resource capacity. In this way, the whole endogenous timeseries "Variable Resource Capacity" problem reduces to making your model capable of sending a "increase resource capacity" signal and a "decrease resource capacity" signal.

Oh, and it's probably worth explicitly stating:
- Exogenous = "from outside the system" which in our case means "Known/Calculable in advance".
- Endogenous = "from inside the system" which in our case means "Not known/calculable in advance" or "generated on-demand".

[Zoli]

Mark, Ton,

I experimented a bit and tried to make a model where the dummy entities sieze zero units of Resource1, but unfortunately this doesn't work(seizezero.cfg). An alternative workaround is to renege the queued entities from the queue to itself(renege.cfg).

Zoli

[Harry King]

Ton, Mark, and Zoli,

Judging from the flood of responses, it looks like this is a desirable feature for many people. It should be possible to implement it in the same way that an ExpressionThreshold checks for a change in the value of its expression. It requires the expression to be evaluated after every event in the model, but this is no worse that what we are already doing for ExpressionThresholds. The extra testing will only be done when an expression is entered -- for a constant value the test loop can be bypassed.

I'll try to get this into the next release.

Harry

[Harry King]

Ton, Mark, and Zoli,

This feature has been added in release 2017-02.

Harry

[Ton D]

Hi Harry

I have a follow-up comment.

Suppose the service times are super long (say an hour for sake of this discussion), and the number of servers is a TimeSeries that always equals 2 except for (say) a minute, where it dips to 1. Then there are two different ways to handle the logic when the capacity increases from 1 to 2:

1) Interpret it as the second working coming back online. This means that unless this worker released an entity in this 1 minute interval, the simulation doesn't "see" the dip.
2) Interpret it as a third working coming online, while the second worker continues to process his own job until it is ready to be released. This means that there are three workers serving jobs for a while after the dip.

You have implemented option 1) in JaamSim. For option 2) one would have to specify a rule that tells the simulation which workers go offline when the capacity decreases. For instance one could use the rule that the server(s) should be chosen uniformly at random.

I'm curious to hear your thoughts as to whether option 2) represents a challenge for JaamSim.

Regards,
Ton

[Mark]

Ton,

Could you not model this situation using nested Seize/Release objects?

The outer seize/release specifying the total resource quantity, followed by a branch object that routes to a set of seize/release objects in parallel, each seizing a different resource with capacity 1?

You could have a time-series on each of the inner resources and only route to seize that resource if it is available at that time.

The downside to this is that you have to know in advance an upper bound on the number of maximum resource capacity your model will ever require and make at least that many inner parallel branches.

Source --> SeizeOuter --> Branch --> ParallelSetOf( SeizeInner --> Delay -->ReleaseInner ) --> ReleaseOuter --> Sink

In this way you can now make the inner resources heterogeneous.

[Ton Dieker]

Hi Mark

You're right this gives you some control on the individual workers but I don't think this takes care of this issue. Once a long job runs on a resource then it will continue to be served even if its capacity very briefly becomes to 0. (Also, the service time is unaffected by this capacity change in the current logic.)

I guess I'm wondering if one could specify a policy which capacity is taken offline. Selecting capacity at random is just one option; another would be to discard the job(s) with the shortest/longest remaining service time etc.

Ton

--
You received this message because you are subscribed to a topic in the Google Groups "Jaamsim Users Discussion Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jaamsim-users/BRT4BDAJc5A/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jaamsim-users+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/jaamsim-users.
To view this discussion on the web, visit https://groups.google.com/d/msgid/jaamsim-users/94c50152-49b6-42cd-b186-bcd61f45ee96%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Mark]

It would all depend upon what you want to happen when the capacity changes.  

This is probably a similar issue faced when the devs put machine "breakdown" logic into JaamSim.

In other simulation packages I have used you usually have to specify the interrupt logic policy:

Some of the options include:

1) Any entity that started processing will continue processing until finished.

2) Any entity that started processing will be interrupted, stored in a side queue, and then resumed upon the resource coming back online.

3) Entity is immediately interrupted and has to restart work from scratch.

Can you just make the internal resources in my above-stated model have breakdowns according to a time-series.

I haven't looked carefully at the breakdown logic, but it may handle the interruption logic that I think you are asking for.

Let me know if I have still misunderstood what you are trying to do.

[Ton D]

Hi Mark

Yes, I was looking exactly for the kind of logic along the lines of the three options you specified, with the additional option to discard the job (that is the one of most interest to me right now). Comparing such breakdown logic within the context of the current discussion on time-dependent capacity, there is an additional component to a policy in the latter case: you also need to specify which of the server(s) go(es) offline. Your solution goes in this direction and can possibly handle it... I haven't used breakdowns yet but it's not so obvious to me how to use them to select a server to take down on the basis of a characteristic of the job they work on (eg remaining service time, random selection, etc).

Ton

[Mark]

Ok, well why not just try this:

- Use the parallel design previously mentioned.

- Use processes instead of seize-delay-release just to simplify.

- Before the process, use an assign object to sample a random processing time from your distribution of choice and record it on the entity as "ProcessTime".  Also record 'this.SimTime' in an attribute called "ProcessStartTime".

- Set the service time of the process object to 'this.obj.ProcessTime' to get the value from the entity's attribute.

- The process object gets an ImmediateReleaseThreshold that tells it exactly when to close.   The ImmediateReleaseThreshold should (if I understand the documentation correctly) cause the process object to release the entity as soon as the threshold closes.

- You can use whatever logic you want to open close the ImmediateReleaseThreshold (Timeseries, Expression, Signal).  You should be able to design something that shuts the threshold off according to your desired policy logic for reducing the capacity.

- Put an branch object after the process object.  If the express 'this.SimTime - this.obj.ProcessStartTime < this.obj.ProcessTime' then it got interrupted and you can dispose of the object or otherwise route it according to your goals.  Otherwise, it did fully process and it should continue on its way.

All you have to do is decide exactly what selection criteria you want for choosing which process to deactivate.  Here are some ideas based upon what you said:

Uniformly decide:

- Use a timeseries to generate an entity at the time you want to reduce the capacity by 1.

- Have it randomly sample an integer index of one of the processes.

- Create a signal object for each process.

- Route to the correct signal object based upon the index.

- Use a signal threshold as the ImmediateReleaseThreshold value.

Shut down the one with the minimum remaining time:

- Use a timeseries to generate an entity at the time you want to reduce the capacity by 1.

- Use boolean algebra to sample the index of the process with the shortest remaining time.

  '( [Process1].obj.ProcessTime - (this.SimTime - [Process1].obj.ProcessStartTime) < min(all other remaining times) ) * IndexOfProcess1 + 

   same format for all other Processes'

- Create a signal object for each process.

- Route to the correct signal object based upon the index.

- Use a signal threshold as the ImmediateReleaseThreshold value.

NOTE:  I haven't checked whether it is legal to reference an attribute belonging to the current entity of another object using '[OtherObjectName].obj.EntitysAtttribute' but I'm hoping that works.

[Ton D]

Hi Mark

Thanks for your detailed response. I have no experience working with thresholds and signals, and some of the examples shared on the forum have broken through updates.

I figured that the best way to understand your ideas is to do a simple example first: a single server that gets switched off a lunch hour, and kicks out the job in service when the lunch hour starts (if any). Much of your email is about the branching logic etc, which is only relevant to the case of multiple servers... and I hope to be able to understand that better after I have understood this simpler example. See the attached file.

You can add a threshold to Seize objects but not to EntityDelay, Resource, or Release objects... so I added it to the ImmediateReleaseThreshold of Seize. However, this doesn't kick out the Entity that's in service when lunch starts. I guess it only influences the entities that flow through the Seize object during lunch... although then I don't see why there is a distinction between ImmediateReleaseThreshold and say ImmediateThreshold.

If none of this makes sense then I haven't understood what you mean by "process"; I do feel like I understand the seize-delay-release construction but you're losing me when you talk about processes... I assumed that that's shorthand for the group of objects.

Regards,
Ton