Changing the value of a variable daily depending on the month

Question

question

C asked Apr 28, '22 C commented May 1, '22

Changing the value of a variable daily depending on the month

Hi all!

I want to increase the battery discharge rate by changing the value "1.0" (the underlined one in the code) depending on dates and probabilities. For example;

If it is January, there is a 60% chance that the value is 1.0 for that day, a 35% chance that the value is 1.1 for that day, and a 5% chance that the value is 1.2 for that day. A maximum of 5 days at most in January can have the value of 1.2, 15 days 1.1, and the rest of 11 days have the value of 1. I think it should use a statistical distribution for that.

If it is not possible, while is it not the way I intended (I want randomizing) but it can use a table with values defined for 365 days and change the value accordingly. Just reference a table, and I will fill it.

v4.fsm

The current code is given below:

/**Custom Code*/
Object current = param(1);
treenode activity = param(2);
Token token = param(3);
Variant assignTo = param(4);
string labelName = param(5);
treenode processFlow = ownerobject(activity);

TrackedVariable battery = current.labels["Battery"];
battery.rate = 1.0*current.dischargeRate;

return battery.value/current.dischargeRate;

Software Version:

FlexSim 19.0.0

statistical distribution coding

v4.fsm (247.8 KiB)

Answer 1 · 2022-04-28T12:36:25Z

Felix Möhlmann answered Apr 28, '22 C commented May 1, '22

I added some logic to your model that should do what you ask for.

A global variable "dailyChargeRate" was added and replaces the fixed value in line 10 in the code that sets the discharge rate.

A new process flow sets this value each day at midnight (first time directly on model start). Which number is chosen is based on the "ChargeRatesTable". Three columns form a group that specify the possible value, its chance to get picked and the maximum number of times it can occur in the month. Each row represents a month.

The code first checks if a new month has started and resets the array label of the token that counts how often each value was picked.

Then it goes through the table and checks which values are still eligible to be picked (below max). These get pushed to an array that holds all possible values. So far I copied the values you mentioned into the table. The number of three-column groups is practically unlimited (though there is a max size for a table in FlexSim).

Afterwards the chance of all eligible values is summed up, since it might be smaller than one, if one ore more values have reached their max already. A random number between 0 and that sum then determines which value gets picked: If the random number is smaller than the chance of a value plus the chances of all previous values, the number gets picked. For example, let's say there are three numbers with chances (0.1, 0.2, and 0.4), so the random number would between 0 and 0.7. For 0.28, the second value would get picked, because 0.1 < 0.28, but 0.1 + 0.2 > 0.28.

After a number is picked, the respective count in the token label is incremented and the global variable is set to the new value.

v4-fm.fsm

I'll also attach the model I used to test the logic. Each day the chosen value is written to a global table. Since it's otherwise it can quickly run many years to test the results.

Currently, since the chance of the value 1 is higher than its maximum allowed count, it mostly appears in the first 2/3 of a month. 1.1 then follows in bulk after 1 is not allowed anymore.

dailyRateTest-fm.fsm

v4-fm.fsm (251.2 KiB)

dailyratetest-fm.fsm (20.1 KiB)

· 7

C commented · Apr 29, 2022 at 02:48 PM

Hi Felix! It is great that you helped me again! Thank you so much for creating this code.

This was about battery discharging and my model is hourly so I renamed your code, tables and variables. I think I made the changes accordingly as it still seems to work.

There seems to be a problem with BOS_ALC ferries, which were not the case before. Now, when there would be two LCs working in the BOS_ALS_PAS process logic, the wrong LC takes starts with the queue. The one that is waiting should take the departure, not the newly arrived LC. This makes the battery levels drop too much.

It would be great if you could help me solve this. Should I create another question for this?

Managed to hit a month with this one but still has that thing with LC10: v4-fm.fsm

Edit: Newer file.

0 ·

v4-fm.fsm (248.6 KiB)

v4-fm.fsm (274.5 KiB)

Felix Möhlmann C commented · Apr 30, 2022 at 08:07 AM

Yes, it would be good if you could create a new question for the problem with the ferries. To find the issue it would also be really helpful if you could provide a time at which you observe the unwanted behaviour. I didn't find any behaviour as you describe it. (BOS_ALS_PAS are LC10, LC11, and LC12, correct?) Nor did I find any reason in the process flow why they should deviate from "first in, first out" order.

Two additional notes about your model:

- When running the simulation I get an error message. The calculated table "Throughput By Type CalculatedTable" is trying to read data from a statistics collector that doesn't seem to exits.

- Is it actually necessary to create tens of thousand of item at the start of the model? Since you only create items once at the start, as far as I can tell, it seems like the goal is just always have something to load?.
In that case you could also simply have the token that triggers the transport task create an item to be loaded.
The large number of items slows down the 3d view, making it more difficult for follow the movement of the task executers.

1 ·

C Felix Möhlmann commented · Apr 30, 2022 at 11:37 AM

Thank you. I'll create a new question for the behaviour of BOS_PAS_LC group after 20:00, when they deviate to another route loop.

- I was trying to get statistics for the daily highest and lowest battery level for each ship. I was not successful. There was a leftover. Now I deleted all does not exist.

- I want to run the model for a year. Currently we create an item with a unique type label for each. Each item type refers to the source and destination port. They reach around 20k for each ship or more than 250k at total. Unless I provide enough of them, ships stop "travel loaded".

I desperately need to reduce the number of items as they hang the sim too much. It would be great if you can give me an example and I'll duplicate it for rest of the model. Here is the most current file: v4-fm.fsm

0 ·

v4-fm.fsm (242.6 KiB)

Show more comments

question