Changing the value of a variable daily depending on the month

Question

question

C asked Apr 28 2022 at 11:30 AM C commented May 01 2022 at 2:43 PM

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)

______

Cookie preferences

Your privacy is important to us and so is an optimal experience. To help us customize information and build applications, we collect data about your use of this site.

May we collect and use your data?

Learn more about the Third Party Services we use and our Privacy Statement.

Strictly necessary – required for our site to work and to provide services to you

These cookies allow us to record your preferences or login information, respond to your requests or fulfill items in your shopping cart.

YES

Improve your experience – allows us to show you what is relevant to you

These cookies enable us to provide enhanced functionality and personalization. They may be set by us or by third party providers whose services we use to deliver information and experiences tailored to you. If you do not allow these cookies, some or all of these services may not be available for you.

YES

NO

Customize your advertising – permits us to offer targeted advertising to you

These cookies collect data about you based on your activities and interests in order to show you relevant ads and to track effectiveness. By collecting this data, the ads you see will be more tailored to your interests. If you do not allow these cookies, you will experience less targeted advertising.

YES

NO

Are you sure you want a less customized experience?

We can access your data only if you select "yes" for the categories on the previous screen. This lets us tailor our marketing so that it's more relevant for you. You can change your settings at any time by visiting our privacy statement

Your experience. Your choice.

We care about your privacy. The data we collect helps us understand how you use our products, what information you might be interested in, and what we can improve to make your engagement with Autodesk more rewarding.

May we collect and use your data to tailor your experience?

Explore the benefits of a customized experience by managing your privacy settings for this site or visit our Privacy Statement to learn more about your options.

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

Felix Möhlmann answered Apr 28 2022 at 12:36 PM C commented May 01 2022 at 2:43 PM

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 2: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 8: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