RAMP-project / RAMP

Repository of the open-source RAMP model for generating multi-energy loads profiles
European Union Public License 1.2
58 stars 33 forks source link

Daily frequency and duration of switch-on events #79

Open JW-Kraft opened 1 year ago

JW-Kraft commented 1 year ago

This is related to the duty-cycle repetition issue #78. Both are based on the rand_switch_on_window function:

The duration of this switch-on window is randomly drawn between the user defined func_cylce and a maximum duration given either by the end of the user defined functioning window or the remaining daily functioning time of the appliance. This leads to the generation of a small number of switch-on windows that are getting smaller with every iteration. (1st iteration: duration_1 drawn from [func_cycle … func_time], 2nd iteration: duration_2 drawn from [func_cycle …func_time – duration_1], 3rd iteration: duration_3 drawn from [func_cycle … func_time – duration_1 – duration_2] and so on) (https://github.com/RAMP-project/RAMP/issues/78)

I tested the function simulating 10 000 days of one test appliance (func_time=4*60, window_1=[8*60, 18*60], func_cycle=10) and tracked the number of switch-on events per day (daily_nr) and the durations of them (dur). Both appear to be exponentially distributed. image image

Currently, the user can only specify the minimal duration of a switch-on event with the parameter func_cycle but cannot influence the distributions shown above (number of switch-on events per day, their average or maximal duration...). I imagine that this could be useful as many appliances have a "typical" usage duration.

One option to influence the duration of switch-on events would be using duty-cycles (with the modifications I proposed in issue https://github.com/RAMP-project/RAMP/issues/78). A "maximal switch-on event duration" parameter to be defined by the user might still be useful though?

FLomb commented 1 year ago

Hi, so you are saying that the right-end tail of the distribution, with some particularly long events, might be unwanted in some cases?

JW-Kraft commented 1 year ago

Hi, I mean more that the distributions themselves might be unwanted. When an appliance is used (assume a computer, water boiler, phone charger...) I would expect the duration of individual usages to be normally distributed around an average, that is specific for the appliance.

Currently, the algorithm generates the exponential distribution which is "limited on the right" by the func_cycle paramater but I'm not sure if that actually represents the duration of use of many appliance well.

FLomb commented 1 year ago

Ok, I get your point about the potential usefulness of being able to specify the typical duration of a given event. I agree this could be something worth exploring. I don't think that using the cycles for this would be very intuitive from a user perspective, though, so I would go for a new specific parameter.

I'm not sure why you say that the func_cycle parameter limits the distribution "to the right", though. The func_cycle per se does not impose any limit on the maximal duration, only to the minimum. What seems to be reducing the duration of the events is how the maximum duration is automatically computed in each iteration based on the available space in a time window (the func_time), right?

JW-Kraft commented 1 year ago

Yes, you're right. I also meant "limits the distribution to the left". Sorry for the confusion.

Bachibouzouk commented 3 months ago

This was not fixed together with issue #78 by PR #111 right @JW-Kraft ?