Repository navigation
Confusion about func_cycle #103
Description
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
Activity
Bachibouzouk commentedon Nov 16, 2023
@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_cycleand 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 commentedon Nov 16, 2023
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 commentedon Nov 16, 2023
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 commentedon Nov 17, 2023
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 commentedon Nov 21, 2023
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 commentedon Nov 24, 2023
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 commentedon Nov 29, 2023
Hi, I've briefly looked into this issue and I can say the following:
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 thefunc_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_cyclesand, 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_cycleto 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 commentedon Nov 29, 2023
I think that if you set a window of 1 hour with
func_cycleof 30 mins the only possible solution would be to start at window start and in the middle of the window to fulfill thefunc_cycle. I would be in favor to point that out as a warning if an appliancefunc_cycleis 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 towindow_end_time - func_cycleFLomb commentedon Nov 30, 2023
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:
func_cycle; so this cannot be a switch-on event per se'And hence do: