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

Error when daily functioning time of an appliance is 0 #114

Closed
JW-Kraft opened this issue Feb 22, 2024 · 5 comments · Fixed by #116
Closed

Error when daily functioning time of an appliance is 0 #114

JW-Kraft opened this issue Feb 22, 2024 · 5 comments · Fixed by #116

Comments

@JW-Kraft
Copy link
Collaborator

I just noticed this when testing a case in which an appliance can have a functioning time of 0. In my case this happens because I dynamically create UseCases based on survey data. Each month is represented by an individual UseCase to represent seasonality of use.
In some months, an appliance is not used at all, which I want to model by giving that appliances a func_time=0. I still want to add the appliance to the UseCase to keep consistent output for every month (I return each appliances load profile individually)
If a user defines an Appliance time_fraction_random_variability to be 1, this error might also occur, since the randomized time of use of a appliance for a day could turn out to be 0.

The error occurs in the function: Appliance.generate_load_profile :

  • In line 1861: while tot_time <= rand_time: executes the loop, when rand_time of an appliance is 0.
  • In the following line the function self.rand_switch_on_window(rand_time) then returns an empty array of indexes
  • This then causes an error when checking for peak_time_windows in line 1890. (trying to access indexes[0], indexes[-1] while indexes is an empty array

Why is this a problem?

  • It always occurs when an appliance's func_time is set to 0. One could argue that this shouldn't be done anyway but then we should throw an error already when an appliance is defined. Currently the default value of func_time of an appliance is 0.
  • It can randomly occur if time_fraction_random_variability is set to 1 because in this case, all of the defined func_time is subject to random variation.

An easy solution:

  • Change the condition of the while loop to: while tot_time <= rand_time and rand_time!=0:: -> this way it does not run when rand_time=0 and no use of this appliance is trying to be simulated.
@Bachibouzouk
Copy link
Collaborator

Hello @JW-Kraft, thank you for this issue. The solution you propose make sense to me.

I think we should throw a warning instead of an error, because of you trick to set the func_time to 0 to switch the appliance off

@FLomb @mohammadamint do you see a problem with the proposed solution?

A test or two to check that the warning is issued and to make sure the appliance is not used

@mohammadamint
Copy link
Collaborator

A warning makes more sense that an Error that stops the simulation.

@JW-Kraft
Copy link
Collaborator Author

@Bachibouzouk @mohammadamint
I would propose not throwing a warning: If a user defines func_time to be 0 this is most likely a conscious decision to (like in my case). Throwing a warning for the appliance for every simulated day would be rather annoying in that case.
It might make sense to check for "strange" user input for appliances once an appliance is added. This could be done for more attributes than just func_time and is not really part of this issue. Rather a potential new feature.

@Bachibouzouk
Copy link
Collaborator

This could be done for more attributes than just func_time and is not really part of this issue. Rather a potential new feature.

I think you are right, we don't want to issue warnings for each days, but we could issue warning when appliance is created that func_time is 0 and I think this warning would be related to this issue and I would implement it (not the warnings for other strange user inputs)

@Bachibouzouk
Copy link
Collaborator

This was solved with #116

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

Successfully merging a pull request may close this issue.

3 participants