Holistic Energy Resource Optimization Network (HERON) is a modeling toolset and plugin for RAVEN to accelerate stochastic technoeconomic assessment of the economic viability of various grid-energy system configurations, especially with application to electrical grids and integrated energy systems (IES).
Apache License 2.0
22
stars
36
forks
source link
[TASK] Consolidate sign tracking for production activity #329
Currently, we've maintained the convention that "negative is consuming, positive is producing" both in the inner workings of HERON, as well as in the HERON input file. This requires users to be careful about what sign they use when inputting values; for example, a "demanding" unit such as a market requires a negative sign in front of its capacity.
This has worked fine, until we get into defining coefficients for transfer functions, especially as we consider polynomial coefficients. Should the sign of coefficients be negative for resources consumed by the component? For linear transfer functions, we can implicitly interpret what is meant, but this is not true for polynomial transfer functions, for example.
As such, we could split the convention: in the user input, values expressed may be left as positive, since we know via "consumes", "demands", and "produces" what is happening. However, upon reading in the user input, the sign convention of "negative consuming, positive producing" can be retained, allowing for sign changes in synthetic histories and custom functions that have meaning. It also simplifies the mathematical expression generation process.
For Change Control Board: Issue Review
This review should occur before any development is performed as a response to this issue.
[x] 1. Is it tagged with a type: defect or task?
[x] 2. Is it tagged with a priority: critical, normal or minor?
[x] 3. If it will impact requirements or requirements tests, is it tagged with requirements?
[x] 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
[x] 5. Is a rationale provided? (Such as explaining why the improvement is needed or why current code is wrong.)
For Change Control Board: Issue Closure
This review should occur when the issue is imminently going to be closed.
[x] 1. If the issue is a defect, is the defect fixed?
[x] 2. If the issue is a defect, is the defect tested for in the regression test system? (If not explain why not.)
[x] 3. If the issue can impact users, has an email to the users group been written (the email should specify if the defect impacts stable or master)?
[x] 4. If the issue is a defect, does it impact the latest release branch? If yes, is there any issue tagged with release (create if needed)?
[x] 5. If the issue is being closed without a pull request, has an explanation of why it is being closed been provided?
Issue Description
Currently, we've maintained the convention that "negative is consuming, positive is producing" both in the inner workings of HERON, as well as in the HERON input file. This requires users to be careful about what sign they use when inputting values; for example, a "demanding" unit such as a market requires a negative sign in front of its capacity.
This has worked fine, until we get into defining coefficients for transfer functions, especially as we consider polynomial coefficients. Should the sign of coefficients be negative for resources consumed by the component? For linear transfer functions, we can implicitly interpret what is meant, but this is not true for polynomial transfer functions, for example.
As such, we could split the convention: in the user input, values expressed may be left as positive, since we know via "consumes", "demands", and "produces" what is happening. However, upon reading in the user input, the sign convention of "negative consuming, positive producing" can be retained, allowing for sign changes in synthetic histories and custom functions that have meaning. It also simplifies the mathematical expression generation process.
For Change Control Board: Issue Review
This review should occur before any development is performed as a response to this issue.
For Change Control Board: Issue Closure
This review should occur when the issue is imminently going to be closed.