-
Notifications
You must be signed in to change notification settings - Fork 33
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
Release v0.5.2 #150
Release v0.5.2 #150
Conversation
Bachibouzouk
commented
Jun 3, 2024
•
edited
Loading
edited
- The changelog should be filled here
- The version number should be bumped
- Test release should be performed with release candidates
try fix the issue with test-pypi
solve the similar issue of test-pypi with the workflow in the publish-pypi workflow
…ease-issue-1 Update python-pypi-test.yml
Skip appliance if func_time==0 or rand_time==0
- in Appliance -> .update_daily_use: - duration of switch-on event is corrected to be only as long as duty cylce - corrected duration of switch-on event is returned - in Appliance -> .generate_load_profile - calculation of total time of operation is performed using corrected duration of switch-on event
- Introduce current_duty_cycle_id as attribute of Appliance to keep track of the current duty cycle and avoid re-evaluating which duty-cycle is concerned by a switch on event - Change x in range(a,b) to a <= x < b as the latter is about 5 times faster 243 ns vs 51.4 ns - Remove direct mention of specific issue in the comments
As now indexes are not updated by update daily_use but by rand_switch_on_window, it is less risky for backward compatibility to update the total time before entering the loop
When this parameter is set to False (default) te behavior should be the same as previously, i.e. continuous duty cyles during the entire switch on event (can contain several duty cycles). Only when set to True would the switch on event be limited to the duration of the duty cycle in order to better model productive use of appliances (mill, welder)
It needs to be run from the root of the repository
Fix/duty cycle repetition for productive use
Fix/empty peak time range
to ensure the Back-compatibility with legacy code, the Appliance method of User class is present. However the method is not further maintained since the nex-gen version of the sofware. To warn the users to move towards the new method, a DeprecationWarning is added.
Hi, Some issues I detected:
|
Test_run is only supposed to be runnable if you are developping and installed ramp locally with |
This one at least works locally, it is most certainly a problem of file path, or maybe we need to push the copy of the Contribute.md file as well (locally the file is copied and included in the index directly as wagtail allows a mix and match of .rst and .md files) |
I've also tried using a developer version installed locally, but it still doesn't work. The BASE_PATH that it uses to create the TEST_OUTPUT_PATH gets messed up and points to a completely wrong location. I have pasted below the error message to give you an idea:
|
Previously the mean of the index range was computed and see if it was falling within a duty cycle. This method compare the boundaries of the range with the one of each duty cycle to know if there is an intersection. If there is one, the duty cycle is chosen. Note: this method does not take into account the case where the indexes range spans accross more than one duty cycle.
Fix duty cycle selection
Small fixes before the release
With some pre-commit linting fixes on previous releases
So that twine check dist/* does not output errors. Pre-commit removed trailing spaces in the file as well
df93fb4
to
b31aaf8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've tested the PR, and it works smoothly; thanks for the work, @Bachibouzouk