You are right that, as of version 9.0, EneryPlus accepts year inputs in the RunPeriod definition, enabling multi-year simulations. However, we definitely don’t support it in legacy and there are a number of good reasons why we will likely not support it in Honeybee[+] (quoting myself below from a recent Pull Request):
- OpenStudio does not support it and, as far as I understand, there are no plans to support it in the future.
- It would create a coordination nightmare between ladybug and honeybee-energy. To just scratch the surface of the headache that this will create, someone running a multi year energy simulation in E+ will not be able to import their results to ladybug data collections, making it impossible to visualize or just simply work with any of the simulation results using ladybug. A full refactor of the ladybug library would be needed to support this.
- In my view, refactoring the entire code base of ladybug in order to expose the year input of the RunPeriod is an example of letting an edge case affect the development and ease-of-use of the most common workflows. Realistically, the only reason why you’d want to make use of the year input on the RunPeriod is to run a multi-year simulation and, if you badly needs this, then I don’t think it’s unreasonable to ask a user to break up their climate data into one year per EPW and run separate simulations.
So this last point embodies what I would suggest to you, @zdenom . You can break down your 5 years into 5 annual EPWs and, if you plug all 5 of them into the simulation component, you can run one after the other just like you would with an exposed year input on the RunPeriod. And, this way, you can still parse your results back into Grasshopper and visualize all your results with the ladybug components.