Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Daily frequency and duration of switch-on events #79

Open
JW-Kraft opened this issue Aug 16, 2023 · 5 comments
Open

Daily frequency and duration of switch-on events #79

JW-Kraft opened this issue Aug 16, 2023 · 5 comments
Assignees
Labels
enhancement New feature or request

Comments

@JW-Kraft
Copy link
Collaborator

JW-Kraft commented Aug 16, 2023

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)
(#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 #78).
A "maximal switch-on event duration" parameter to be defined by the user might still be useful though?

@FLomb FLomb self-assigned this Aug 23, 2023
@FLomb FLomb added the enhancement New feature or request label Aug 23, 2023
@FLomb
Copy link
Contributor

FLomb commented Aug 23, 2023

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
Copy link
Collaborator Author

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
Copy link
Contributor

FLomb commented Sep 4, 2023

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
Copy link
Collaborator Author

JW-Kraft commented Sep 4, 2023

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

@Bachibouzouk
Copy link
Collaborator

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants