topic Re: scenarios given by the optimizer, not matching simulation in FlexSim Forum

scenarios given by the optimizer, not matching simulation

marc_r5 — Fri, 15 Apr 2022 09:24:45 GMT

[ FlexSim 22.0.2 ]

Hello,

I have this model and I am trying to use the optimizer but I am facing various problems.

- The optimizer is giving me production time equals to 0, that does not make sense

- The optimizer gives scenarios with the same outcome.

- The optimizer's scenarios, if I replicate them and play them in simulation, gives me a different value than the optimizer.

Please, I don't get what is the issue and stuck for a few days with this.

Thanks

Layout v3.2_14.fsm

Re: scenarios given by the optimizer, not matching simulation

JordanLJohnson — Fri, 15 Apr 2022 15:50:28 GMT

This model doesn't seem repeatable. When I run it, the message box appears at slightly different end times. If the model isn't repeatable, then you won't get consistent results from the Optimizer.

The end time doesn't seem to vary by much. However, other events in the model do vary, by quite a bit. Because my Windows region settings are different, I got exceptions in parsing the date/time values. These exceptions happened at wildly different times in the model; sometimes they happened at time 120, other times as late as 250. In a repeatable model, these exceptions should happen at exactly the same time, every time. The big swing in these exceptions reveals a severe repeatability problem. You can replicate these exceptions by changing lines 23 and 24 of the "Register to Departures GT" activities:

DateTime departureDate = DateTime(table["DepartureDate"], "_broken_d/%m/%Y %H:%M:%S");
DateTime endDate = DateTime(table["FabricationEndDate"], "_broken_%d/%m/%Y %H:%M:%S");

Then you can easily see the exceptions happening at different times.

If you fix the repeatability issues, you'll likely fix the optimizer issues you are having. This article provides many things to check, to make sure your model is repeatable:

https://docs.flexsim.com/en/22.1/BestPractices/ModelRepeatability/ModelRepeatability.html

Re: scenarios given by the optimizer, not matching simulation

marc_r5 — Tue, 19 Apr 2022 06:54:23 GMT

Hello Jordan, thanks for your response.

The model use different time for each piece in each processor. The total production time is what I need to minimize, so they need to change to take the min of them.

So to do that, each time the model resets, it changes the order of the arrivals, so the production time must change, as the pieces enters in a different time and each processors time are different for each piece. So, it will give different result each time it resets.

I am not sure if I understand this issue you say that the end time change.

About the issue with parsing datetime, I used "%d/%m/%Y %H:%M:%S" because someone on the forum told me it was the "universal" way, that won't give error in different region settings. Is it "_broken_d/%m/%Y %H:%M:%S" the way to avoid region settings issues?

Thanks.

Re: scenarios given by the optimizer, not matching simulation

marc_r5 — Tue, 19 Apr 2022 07:02:16 GMT

This is where I change the values on reset.

It is done like this to iterate the order within each building and floor, so both of them are mantained in the same order, and within each, there are a lot of panels that will be changed in order to find the best production time according to the balancing between stations.

Re: scenarios given by the optimizer, not matching simulation

moehlmann_fe — Tue, 19 Apr 2022 08:58:52 GMT

In your model you are missing the last step of the proposed solution I provided in your previous question: Resetting the table to its original row order after assigning the "order" values based on the sequence parameter.

https://answers.flexsim.com/questions/118451/optimize-iterating-order-within-groups.html

Currently, when you apply the same sequence multiple times in a row the table order will change every time, which is likely why you run into repeatability issues. You can see this when you open the table and hit "Reset" multiple times in a row.

To have the model be repeatable I added a new column to the table in the other post, which determines the "correct" order of the table it is restored to at the end of the code. That way, the same sequence will always result in the same table.

(The first reset after activating the last code line results in a "wrong" order still, since the table is not yet sorted by the last column. Afterwards, the table doesn't change on every reset anymore)

Re: scenarios given by the optimizer, not matching simulation

marc_r5 — Tue, 19 Apr 2022 09:08:15 GMT

Thank you so much Felix. Sorry I missed that, I got confused...

So to do it dynamically, on the parameter "on set", I would copy paste the original order into a new column each time, so I can then order by it? Am I right?

Thank you so much again.

Re: scenarios given by the optimizer, not matching simulation

marc_r5 — Tue, 19 Apr 2022 09:30:31 GMT

I tried to do that, but order still changes... I cannot find why...

Layout v3.2_14.fsm

Re: scenarios given by the optimizer, not matching simulation

jason_lightfoot_adsk — Tue, 19 Apr 2022 10:11:41 GMT

Because in your runStart trigger you sort only by the "Order" column. You need to use the OriginalOrder or comment that line.

Re: scenarios given by the optimizer, not matching simulation

marc_r5 — Tue, 19 Apr 2022 12:20:52 GMT

I did that, and it still changes the order each time I press the reset button...

Re: scenarios given by the optimizer, not matching simulation

moehlmann_fe — Tue, 19 Apr 2022 12:33:36 GMT

You shouldn't copy the "Order" column to the "OriginalOrder" column. The "OriginalOrder" values for each row are static.

Otherwise you have the same problem again: The order would depend on the last used sequence.

Re: scenarios given by the optimizer, not matching simulation

marc_r5 — Tue, 19 Apr 2022 12:57:31 GMT

Hi Felix, then without copying the values, how the optimizer assigns a new order each time?

The model takes by the order column each piece and creates it in the flow, if I always order by originalorder column which is static and never changes, the flow order will be the same?

I think I miss something.

Re: scenarios given by the optimizer, not matching simulation

moehlmann_fe — Tue, 19 Apr 2022 13:24:51 GMT

I wasn't sure how exactly the orders are generated in your model. The assumption for my solution was that each token would be assigned an "order number" in ascending order and look for the row with the corresponding number. So the first token would look for the row where "order" = 1 and so on.

If they are created in the order they appear in the table, then you can simply change the order of operations in the code. Restore the original order first, then assign the new values.

In this case, re-assigning the "order" values after sorting the table also shouldn't be necessary.

layout-v32-14(1).fsm

Re: scenarios given by the optimizer, not matching simulation

marc_r5 — Wed, 20 Apr 2022 07:23:18 GMT

Hello,

Perfect, I've simplified this part. And yes, I create tokens, and assign each token by order to data in arrivals table.

But, doing this, and now I would think it has a proper logic, when I click on reset, order changes still, and when optimize, I get a lot of results with production time equals to 0, which is weird...

Production time is a tracked variable that I assign at the end of the process.

I thank you all for the help so far, but if you could give me some light in this, I would appreciate it a lot, as I cannot find any kind of example like this anywhere.

Thank you

Layout v3.2_14.fsm

Re: scenarios given by the optimizer, not matching simulation

moehlmann_fe — Wed, 20 Apr 2022 07:51:28 GMT

You commented out the line that resets the table order before assigning the new one, which is why it still changes.

The optimizer issue is likely caused by how you populate the schedule table of the process flow source. I am not actually when exactly the calculated table updates, but I find that on occasion an empty table is pasted into the source, meaning nothing actually happens when the model is started.

Right now you have three things that have to happen on model reset (update arrivals table, update calculated table based on it and copy schedule to the PF source). Because they all happen in different parts of model (Parameter On Set trigger, OnModelReset trigger, Calculated Table) the order in which these happen might not be fixed. Instead I would change the model so that everything happens in the OnSet trigger of the parameter: Assign new order to table -> SQL query to get the arrival schedule -> Copy schedule to source

I don't know if the calculated table is used in some other place in the model. If not, it would be redundant after this change.

layout-v32-14(2).fsm

Re: scenarios given by the optimizer, not matching simulation

marc_r5 — Wed, 20 Apr 2022 08:36:06 GMT

Oh, thank you very much Felix. Now I think it makes more sense! I appreciate your help so much!

One last question if I may. The originalorder column, does it needs to be a static column with a random order because it is just used to reset the table's order and assign a new one? Am I right?

Thanks again!

Re: scenarios given by the optimizer, not matching simulation

moehlmann_fe — Wed, 20 Apr 2022 08:50:02 GMT

Yes, the order can be random, though I would suggest you use the "default" state of the table to create the column. (The order the table was in when you imported/created it)

This way, the sequence (1,2,3,...,500) will result in that default ordering.

Re: scenarios given by the optimizer, not matching simulation

marc_r5 — Wed, 20 Apr 2022 13:12:41 GMT

Perfect, thanks.

And this "on set" logic on this parameter can be done in another place like "on simulation start" if exists?

I mean this, because "on reset" I coud import data, and then all the changes on parameters that come from a global table, will be done afterwards before simulation starts...?

Re: scenarios given by the optimizer, not matching simulation

moehlmann_fe — Wed, 20 Apr 2022 14:03:38 GMT

The ordering of the table should work if done on simulation start.

Copying the arrival times into the source might better be done in the "On Import" trigger. Since the data is ordered by time anyway, I don't think it has to be done on every reset/model start.