Confusion about func_cycle

[paulamadeo]

Hello Everyone,

I wanted to test out the functions of RAMP and built a very basic "Test" excel input file, with only one appliance:

name: HMI_outdoor_bulb
number: 1
power: 10
num_windows: 1
func_time: 60
func_cylce: 30
window_1_start: 1080
window_1_end: 1200

I set both random_vars to 0.

Considering both the definitions of:

func_time: "Total time an appliance is running in a day (not dependant on windows)"
func_cycle: "Running time: time the appliance is on (after switching it on)"

I expected that the outdoor_bulb would run 30 minutes (func_cycle) two times making 60 minutes in total (func_time) between 6pm (1080) and 8pm (1200). However, i run the file a few times and sometimes I receive a plot like the one that I attached to this Issue where the appliance runs for 5 minutes and then another time for 55. I read in paper that func_cyle stands for the minimum time an appliance is running after being switched on but even this would not be the case here.

I would appreciate if someone could explain the func_cycle function to me and what the explanation to this issue could be.

Thank you very much!

Test.xlsx

[Bachibouzouk]

@paulamadeo - first of all, thank you for taking the time to provide us a nice bug report with pictures, good description and input file !

As you noted this is not the expected behavior of func_cycle and this is probably a bug, I will create a new test based on your example and look closer at it! I will keep you posted and would link the PR to this issue.

[paulamadeo]

Hello @Bachibouzouk, thank you very much for your answer! Is the func_cycle supposed to be the "time the appliance is on (after switching it on)" or the "minimum time the appliance is on (after switching it on)"?

Thank you for taking on this issue and I would appreciate if you keep me posted!

[Bachibouzouk]

It is supposed to be the minimum time the appliance is on after switch on (like a laundry machine is usually on for the whole cycle after being switched on)

[Bachibouzouk]

Dear @paulamadeo, which version of ramp are you using? I tried to run your usecase for file several hundred profiles several times and I had modified the code so that if a timewindows is smaller than the func_cycle it start the debugger. I could not trigger the debugger, also I ran the command several times as well.

[paulamadeo]

Hallo @Bachibouzouk,

I realized that I had the version 0.4.0. installed, i therefore bumped up the version to 0.4.1. hoping that it would resolve the issue. However, as you can see in the screenshot, the bug still exists. Do you have any other idea what the issue could be? Thank you very much for your help in this matter.

[Bachibouzouk]

Hello @paulamadeo - this is peculiar! Can you also share the command you ran with your file (the input file you also shared above). The picture is the one automatically generated by RAMP correct?

[FLomb]

Hi, I've briefly looked into this issue and I can say the following:

• For the input file provided by @paulamadeo , it is true that the unwanted behaviour occurs.
• In general, the unwanted behaviour does not always occur, although it does occurr often.

Why so? Essentially, what you are modelling is a situation in which, in a relatively small time window, the appliance needs to be operated two times with at least 30 minutes of func_cycle. What happens is that, initially, the window is completely free. So the appliance gets switched on in a random moment and is kept on on for a time >= 30 minutes. Now, if the time the appliance is on is, say, 45 minutes, you still need 15 minutes to fulfill the 60-minute total use for the day. So what happens is that another switch on time is calculated among the remaining free spots of the window. Then, however, the duration of that second switch-on event is only as much as needed to finish off the daily functionin time; in this illustrative example, 15 minutes, which is less than the func_cycle.

Now, this behaviour seems odd and very much unwanted if, as in your case, your total functioning time is small enough to often allow only two switch-on events with a minimum duration of 30 mins, leading to one of the two almost always being cut short. However, if you gave the same appliance much more daily functioning time, for instance, you would see multiple perfectly fine switch-on events, and only one cut short (the one needed to finish off the remaining minutes of the daily usage). Normally, this does not happen because most appliances have short minimum-enforced func_cycles and, once random variability is added to both windows size and average daily usage time, the few instances in which something gets cut short represent very minor distortions and plausible real-world deviations from standard usage.

Overall, while I can see this is de facto a 'bug' if modelling a situation like the one above, the solution cannot be to just force the func_cycle to always be respected, since that would lead to a frequent over-use of the appliance compared to the prescribed average daily functioning time. Any ideas @Bachibouzouk ?

[Bachibouzouk]

I think that if you set a window of 1 hour with func_cycle of 30 mins the only possible solution would be to start at window start and in the middle of the window to fulfill the func_cycle. I would be in favor to point that out as a warning if an appliance func_cycle is bigger or equal than say 30% of the window of use. Another way would be to allow the use of the appliance over the window of time as long as it did start within the window. A third way would be to restrict possible start times to window_end_time - func_cycle

[FLomb]

Now that I think of it, building on your third proposed solution, I think that the 'perfect' solution could be that, when you have leftover minutes to spend to finish off the estimated total daily usage, those are not spent in a switch-on event shorter than the func_cycle, but rather added on top of an existing switch-on event, making it longer.

So the code would need to realise:

• 'Ah, I have to spend some minutes which are less than the func_cycle; so this cannot be a switch-on event per se'

And hence do:

• 'Let me see what's the closest previous switch-on event that I can make longer with these leftover minutes while respecting all other constraints'