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.

Issue: it was not easy to find that there were extra dependencies for
testing

Solution: mention it explicitely in the CONTRIBUTING.md

issue: the test was failing randomly when accessing whether the sampled
coincidence were following a normal distribution, due to the fact we
apply math.ceil to the random.gauss to get integer number of appliances
to be switched on simultaneously

solution: get an experimental probability density function and fit a
normal distribution to it, look how large is the error of mean and std
as a proxy of visual inspection of the graph

Related to #99

issue: using the excel file generated by the "Using tabular inputs to
build a model" example one could not run successfully `ramp -i
example_excel_usecase.xlsx -n 10`

solution: pass the argument flat=False to the Usecase method
generate_daily_load_profiles. The postprocessing should actually
make use of the newest capabilities

issue: the user could not simulate more than one year because of a
requirement that the number of power values for an appliance should not
exceed 366

solution: the checks were moved to a function of Appliance class which
is called when the usecase is initialized. If the Appliance instance has
constant power, its power timeseries is adjusted and a warning is
issued. However if the power timeseries was provided by user and does
not contain enough values to cover the simulation range, an error is
raised.

Also provide a test of the CLI with example file

Remove typo in a string

Add a section about issues

within the current template, 'basicstrap', the navigation on the left sidebar (with the partial TOC) is a bit
counter-intuitive. The new template provides a more intituitive
sidebars.

Add a line at end of section with link to download the notebook

issue:

Python 3.8 is mentioned in the README as the prefered python version for
the installation. However, this python vesion is going to be outdated by
October 2024.

Current RAMP dev can be safely used by python 3.10.

Changes:

- README.rst --> updateing the installation guide
- environment.yml --> updating the python dependency for installing
  environment through yml file
 - setup.py --> updating the python_requires accordingly

issue:
When a user object is empty cannot be printed due as the __repr__ method
uses the save() method to print the properties of the users, which raise
Exception in case no appliances are added to the user.

solution:
in case save() methods returns an exception, the function prints the
user_name, and user_num with a message to mention no appliances are
assigned to the user object yet.

The comparisons were not saved so the return value was always "True"

As the contribution guidelines have a dedicated in the documentation we
replace the link within the readme which was pointing towards the file
CONTRIBUTING.md on github with a link which points towards the dedicated
contribution guidelines within the documentation

issue:
The lack of clear explanation of the example notebooks makes the core
context of each example very difficult to be understood and followed.

changes:
improving the explanation of the example

Improving the explanation and analysis of the example

- Imroving the example with occasional uses
- fixing some typos

Improving the example explanatio for cooking appliances

Co-authored-by: Pierre Francois <[email protected]>

Co-authored-by: Pierre Francois <[email protected]>

Co-authored-by: Pierre Francois <[email protected]>

Co-authored-by: Pierre Francois <[email protected]>

Co-authored-by: Pierre Francois <[email protected]>

Co-authored-by: Pierre Francois <[email protected]>

Do this only for the first occurence as there are many appliances and
users in examples 1 and 3