scenarios given by the optimizer, not matching simulation

scenarios given by the optimizer, not matching simulation

marc_r5
Not applicable
13 Views
17 Replies
Message 1 of 18

scenarios given by the optimizer, not matching simulation

marc_r5
Not applicable

[ 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

0 Likes
Accepted solutions (1)
14 Views
17 Replies
Replies (17)
Message 2 of 18

JordanLJohnson
Autodesk
Autodesk
Accepted solution

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

.


Jordan Johnson
Principal Software Engineer
>

Message 3 of 18

marc_r5
Not applicable

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.

0 Likes
Message 4 of 18

marc_r5
Not applicable

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.

1650351582196.png

0 Likes
Message 5 of 18

moehlmann_fe
Observer
Observer

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.

1650358587673.png

1650358615456.gif

(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)

0 Likes
Message 6 of 18

marc_r5
Not applicable
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.

0 Likes
Message 7 of 18

marc_r5
Not applicable

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

Layout v3.2_14.fsm

0 Likes
Message 8 of 18

jason_lightfootVL7B4
Autodesk
Autodesk

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

0 Likes
Message 9 of 18

marc_r5
Not applicable
I did that, and it still changes the order each time I press the reset button...
0 Likes
Message 10 of 18

moehlmann_fe
Observer
Observer

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

1650371346709.png

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

0 Likes
Message 11 of 18

marc_r5
Not applicable
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.

0 Likes
Message 12 of 18

moehlmann_fe
Observer
Observer

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.

1650374631954.png

layout-v32-14(1).fsm

0 Likes
Message 13 of 18

marc_r5
Not applicable

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

0 Likes
Message 14 of 18

moehlmann_fe
Observer
Observer

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

1650440730875.png

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

0 Likes
Message 15 of 18

marc_r5
Not applicable
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!

0 Likes
Message 16 of 18

moehlmann_fe
Observer
Observer
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.

0 Likes
Message 17 of 18

marc_r5
Not applicable
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...?

0 Likes
Message 18 of 18

moehlmann_fe
Observer
Observer
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.


0 Likes