idaholab / heron Goto Github PK

Defect Description

Describe the defect

What did you expect to see happen?

What did you see instead?

$ ./make_docs.sh
CONDA
raven_libraries * C:\Users\haoyuwang.conda\envs\raven_libraries

Building manuals ...
... building in user_manual...
bash: make_win.sh: No such file or directory

Do you have a suggested fix for the development team?

Describe how to Reproduce
Steps to reproduce the behavior:
1.
2.
3.
4.

Screenshots and Input Files
Please attach the input file(s) that generate this error. The simpler the input, the faster we can find the issue.

Platform (please complete the following information):

• OS: [e.g. iOS]
• Version: [e.g. 22]
• Dependencies Installation: [CONDA or PIP]

For Change Control Board: Issue Review

This review should occur before any development is performed as a response to this issue.

• 1. Is it tagged with a type: defect or task?
• 2. Is it tagged with a priority: critical, normal or minor?
• 3. If it will impact requirements or requirements tests, is it tagged with requirements?
• 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
• 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.

• 1. If the issue is a defect, is the defect fixed?
• 2. If the issue is a defect, is the defect tested for in the regression test system? (If not explain why not.)
• 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)?
• 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)?
• 5. If the issue is being closed without a pull request, has an explanation of why it is being closed been provided?

Issue Description

If RAVEN is installed using PIP-only, the HERON "executable" should respect that.

For Change Control Board: Issue Review

This review should occur before any development is performed as a response to this issue.

• 1. Is it tagged with a type: defect or task?
• 2. Is it tagged with a priority: critical, normal or minor?
• 3. If it will impact requirements or requirements tests, is it tagged with requirements?
• 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
• 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.

• 1. If the issue is a defect, is the defect fixed?
• 2. If the issue is a defect, is the defect tested for in the regression test system? (If not explain why not.)
• 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)?
• 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)?
• 5. If the issue is being closed without a pull request, has an explanation of why it is being closed been provided?

Defect Description

Describe the defect

AS RAVEN PR idaholab/raven#1289, the HERON tests fail

Do you have a suggested fix for the development team?

Regolding

Describe how to Reproduce
Steps to reproduce the behavior:
1.
2.
3.
4.

Screenshots and Input Files
Please attach the input file(s) that generate this error. The simpler the input, the faster we can find the issue.

Platform (please complete the following information):

• OS: [e.g. iOS]
• Version: [e.g. 22]
• Dependencies Installation: [CONDA or PIP]

For Change Control Board: Issue Review

This review should occur before any development is performed as a response to this issue.

• 1. Is it tagged with a type: defect or task?
• 2. Is it tagged with a priority: critical, normal or minor?
• 3. If it will impact requirements or requirements tests, is it tagged with requirements?
• 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
• 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.

• 1. If the issue is a defect, is the defect fixed?
• 2. If the issue is a defect, is the defect tested for in the regression test system? (If not explain why not.)
• 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)?
• 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)?
• 5. If the issue is being closed without a pull request, has an explanation of why it is being closed been provided?

Issue Description

It would be ideal to train the ARMAs used in the testing as a part of the regression tests.

Unfortunately (idaholab/raven/issues/1237) we don't have the capability to do cross-directory prerequisites yet.

Once we do, we should remove the skips on those tests and make them prereqs.

For Change Control Board: Issue Review

This review should occur before any development is performed as a response to this issue.

• 1. Is it tagged with a type: defect or task?
• 2. Is it tagged with a priority: critical, normal or minor?
• 3. If it will impact requirements or requirements tests, is it tagged with requirements?
• 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
• 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.

• 1. If the issue is a defect, is the defect fixed?
• 2. If the issue is a defect, is the defect tested for in the regression test system? (If not explain why not.)
• 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)?
• 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)?
• 5. If the issue is being closed without a pull request, has an explanation of why it is being closed been provided?

Issue Description

HERON seems to only use hourly repeating cashflows. It would be nice to use capex and yearly periodic (such as fixed O&M) as well.

For Change Control Board: Issue Review

This review should occur before any development is performed as a response to this issue.

• 1. Is it tagged with a type: defect or task?
• 2. Is it tagged with a priority: critical, normal or minor?
• 3. If it will impact requirements or requirements tests, is it tagged with requirements?
• 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
• 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.

• 1. If the issue is a defect, is the defect fixed?
• 2. If the issue is a defect, is the defect tested for in the regression test system? (If not explain why not.)
• 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)?
• 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)?
• 5. If the issue is being closed without a pull request, has an explanation of why it is being closed been provided?

Issue Description

It should be possible to request specific initial values for the outer optimization. The default now is 1/2 max capacity.

Further, multiple initial values should be usable to initialize multiple trajectories.

For Change Control Board: Issue Review

This review should occur before any development is performed as a response to this issue.

• 1. Is it tagged with a type: defect or task?
• 2. Is it tagged with a priority: critical, normal or minor?
• 3. If it will impact requirements or requirements tests, is it tagged with requirements?
• 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
• 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.

• 1. If the issue is a defect, is the defect fixed?
• 2. If the issue is a defect, is the defect tested for in the regression test system? (If not explain why not.)
• 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)?
• 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)?
• 5. If the issue is being closed without a pull request, has an explanation of why it is being closed been provided?

Issue Description

Is your feature request related to a problem? Please describe.
I am developing a validator, and I would like to access the <initial_stored> quantity of HERON storage component. Paul mentioned that the initial level can be retrieved by <component_object>.get_interaction().get_initial_level(meta)

Describe the solution you'd like
Pass the "meta" into validator. Currently there is no "meta" in the validator namespace. Thanks!

Describe alternatives you've considered
N/A

For Change Control Board: Issue Review

This review should occur before any development is performed as a response to this issue.

• 1. Is it tagged with a type: defect or task?
• 2. Is it tagged with a priority: critical, normal or minor?
• 3. If it will impact requirements or requirements tests, is it tagged with requirements?
• 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
• 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.

• 1. If the issue is a defect, is the defect fixed?
• 2. If the issue is a defect, is the defect tested for in the regression test system? (If not explain why not.)
• 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)?
• 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)?
• 5. If the issue is being closed without a pull request, has an explanation of why it is being closed been provided?

Issue Description

Is your feature request related to a problem? Please describe.

We need to allow <constant> and <variable> nodes from OUTER to be included in the magic passthroughs to INNER without the user having to update the list.

Describe the solution you'd like

HERON can write this list as arguments to the DispatchManager in a node or something along those lines.

Describe alternatives you've considered

Furthermore, I don't think there's a way to systematically add parametric variables that aren't part of unit descriptions (such as these magic terms) to the HERON input, so that might need to come with the PR.

For Change Control Board: Issue Review

This review should occur before any development is performed as a response to this issue.

• 1. Is it tagged with a type: defect or task?
• 2. Is it tagged with a priority: critical, normal or minor?
• 3. If it will impact requirements or requirements tests, is it tagged with requirements?
• 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
• 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.

• 1. If the issue is a defect, is the defect fixed?
• 2. If the issue is a defect, is the defect tested for in the regression test system? (If not explain why not.)
• 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)?
• 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)?
• 5. If the issue is being closed without a pull request, has an explanation of why it is being closed been provided?

Issue Description

Some of the regression tests are failing, only on Windows.

For Change Control Board: Issue Review

This review should occur before any development is performed as a response to this issue.

• 1. Is it tagged with a type: defect or task?
• 2. Is it tagged with a priority: critical, normal or minor?
• 3. If it will impact requirements or requirements tests, is it tagged with requirements?
• 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
• 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.

• 1. If the issue is a defect, is the defect fixed?
• 2. If the issue is a defect, is the defect tested for in the regression test system? (If not explain why not.)
• 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)?
• 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)?
• 5. If the issue is being closed without a pull request, has an explanation of why it is being closed been provided?

Issue Description

Having a bash script similar to RAVEN's raven_framework for establishing conda env, etc. would help heron be run more consistently.

For Change Control Board: Issue Review

This review should occur before any development is performed as a response to this issue.

• 1. Is it tagged with a type: defect or task?
• 2. Is it tagged with a priority: critical, normal or minor?
• 3. If it will impact requirements or requirements tests, is it tagged with requirements?
• 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
• 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.

• 1. If the issue is a defect, is the defect fixed?
• 2. If the issue is a defect, is the defect tested for in the regression test system? (If not explain why not.)
• 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)?
• 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)?
• 5. If the issue is being closed without a pull request, has an explanation of why it is being closed been provided?

Issue Description

Calls to ValuedParams (such as get_capacity in Components) take too many arguments that are often unnecessary and have duplicates in them. Taking the capacity example, the argument list is
get_capacty(meta, raven_vars, dispatch, t) but raven_vars, dispatch, t are all already in meta, so just passing meta through should be sufficient.

Maybe meta should be renamed to SystemState or something to reflect what it's holding.

For Change Control Board: Issue Review

This review should occur before any development is performed as a response to this issue.

• 1. Is it tagged with a type: defect or task?
• 2. Is it tagged with a priority: critical, normal or minor?
• 3. If it will impact requirements or requirements tests, is it tagged with requirements?
• 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
• 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.

• 1. If the issue is a defect, is the defect fixed?
• 2. If the issue is a defect, is the defect tested for in the regression test system? (If not explain why not.)
• 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)?
• 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)?
• 5. If the issue is being closed without a pull request, has an explanation of why it is being closed been provided?

Issue Description

Is your feature request related to a problem? Please describe.
The dispatcher manager validators needs to allow for the deployment of validator-specific input XML blocks.
The code should allow for any derived validator to, optionally, define its own input specifications (e.g. options, settings, etc.)

Describe the solution you'd like
Activate the INPUT DATA reader within the validator class

Describe alternatives you've considered
hardcoded values (not optimal)

For Change Control Board: Issue Review

This review should occur before any development is performed as a response to this issue.

• 1. Is it tagged with a type: defect or task?
• 2. Is it tagged with a priority: critical, normal or minor?
• 3. If it will impact requirements or requirements tests, is it tagged with requirements?
• 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
• 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.

• 1. If the issue is a defect, is the defect fixed?
• 2. If the issue is a defect, is the defect tested for in the regression test system? (If not explain why not.)
• 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)?
• 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)?
• 5. If the issue is being closed without a pull request, has an explanation of why it is being closed been provided?

Issue Description

With CIVET back up, we need to make sure devel is behaving as expected on all the test machines.

For Change Control Board: Issue Review

This review should occur before any development is performed as a response to this issue.

• 1. Is it tagged with a type: defect or task?
• 2. Is it tagged with a priority: critical, normal or minor?
• 3. If it will impact requirements or requirements tests, is it tagged with requirements?
• 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
• 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.

• 1. If the issue is a defect, is the defect fixed?
• 2. If the issue is a defect, is the defect tested for in the regression test system? (If not explain why not.)
• 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)?
• 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)?
• 5. If the issue is being closed without a pull request, has an explanation of why it is being closed been provided?

Defect Description

There is a bug that can occur when the pyomo rolling window is shorter than a cluster history from a synthetic history sample, where the storage level and synthetic history reset to time 0 instead of moving forward with the rolling window. This can cause incorrect results due to incorrect data being accessed.

Discovered as a result of working on #77.

For Change Control Board: Issue Review

This review should occur before any development is performed as a response to this issue.

• 1. Is it tagged with a type: defect or task?
• 2. Is it tagged with a priority: critical, normal or minor?
• 3. If it will impact requirements or requirements tests, is it tagged with requirements?
• 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
• 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.

• 1. If the issue is a defect, is the defect fixed?
• 2. If the issue is a defect, is the defect tested for in the regression test system? (If not explain why not.)
• 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)?
• 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)?
• 5. If the issue is being closed without a pull request, has an explanation of why it is being closed been provided?

Make a better TEAL error note. Currently it is hard to discern when there is an issue with libraries that are referenced.

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

For Change Control Board: Issue Review

This review should occur before any development is performed as a response to this issue.

• 1. Is it tagged with a type: defect or task?
• 2. Is it tagged with a priority: critical, normal or minor?
• 3. If it will impact requirements or requirements tests, is it tagged with requirements?
• 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
• 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.

• 1. If the issue is a defect, is the defect fixed?
• 2. If the issue is a defect, is the defect tested for in the regression test system? (If not explain why not.)
• 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)?
• 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)?
• 5. If the issue is being closed without a pull request, has an explanation of why it is being closed been provided?

Issue Description

As discussed in our meeting the optimization mode isn't functioning yet. Adding this feature would allow the dispatcher to find optimal values the opt_bounds node in the input xml.

Issue Description

The current pyomo-based dispatcher assumes a free market or regulated market approach to dispatch.

In many electricity grid cases, a deregulated market is not entirely a free market; rather, the following process is followed:

• The "controlling entity" (e.g. ISO) has a demand to meet
• Each producing unit submits its available capacity and price per unit production
• The ISO determines how much of each unit to dispatch, generally starting with lowest cost and moving to highest until demand is met
• Any leftover capacity for the unit can be used for auxiliary services

This dispatch strategy should be generalizable into a dispatch strategy in HERON. One important note is that the "stack" of marginal costs and capacities (usually a step function) is not always given per-unit, but rather can be a black box function call taking required production/demand and returning price.

Further, the auxiliary services may add to the total demand required, which initiates a feedback loop that may need to be solved using e.g. Picard iteration. For now, just getting a static implementation would be a good start.

This is a program-driven use case.

For Change Control Board: Issue Review

This review should occur before any development is performed as a response to this issue.

• 1. Is it tagged with a type: defect or task?
• 2. Is it tagged with a priority: critical, normal or minor?
• 3. If it will impact requirements or requirements tests, is it tagged with requirements?
• 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
• 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.

• 1. If the issue is a defect, is the defect fixed?
• 2. If the issue is a defect, is the defect tested for in the regression test system? (If not explain why not.)
• 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)?
• 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)?
• 5. If the issue is being closed without a pull request, has an explanation of why it is being closed been provided?

Issue Description

Users should be able to provide information pertaining to a case that would be valuable to have at the end of the RAVEN stack. This could be information that would help distinguish between runs when the data contains a multilevel structure.

For example, If a user is examining effect on marginal costs across a set of varying market demand scenarios for a set of different markets, a user should be able to specify something like:

<Case name="Sweep_Runs">
...
  <caseinfo>
    <state>California</state>
    <scenario>CarbonTax</scenario>
  </caseinfo>
...
</Case>

This would allow HERON's template builder to handle a broader range of cases.

For Change Control Board: Issue Review

This review should occur before any development is performed as a response to this issue.

• 1. Is it tagged with a type: defect or task?
• 2. Is it tagged with a priority: critical, normal or minor?
• 3. If it will impact requirements or requirements tests, is it tagged with requirements?
• 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
• 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.

• 1. If the issue is a defect, is the defect fixed?
• 2. If the issue is a defect, is the defect tested for in the regression test system? (If not explain why not.)
• 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)?
• 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)?
• 5. If the issue is being closed without a pull request, has an explanation of why it is being closed been provided?

Issue Description

Storage constraint writing options should be added to the pyomo_solver, and a convention for tracking storage
activity/level should be considered.

Previously, storage dispatch has only been simulated using custom dispatch strategies.

For Change Control Board: Issue Review

This review should occur before any development is performed as a response to this issue.

• 1. Is it tagged with a type: defect or task?
• 2. Is it tagged with a priority: critical, normal or minor?
• 3. If it will impact requirements or requirements tests, is it tagged with requirements?
• 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
• 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.

• 1. If the issue is a defect, is the defect fixed?
• 2. If the issue is a defect, is the defect tested for in the regression test system? (If not explain why not.)
• 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)?
• 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)?
• 5. If the issue is being closed without a pull request, has an explanation of why it is being closed been provided?

The nominal solver used by the pyomo dispatcher is cbc, but that is not available through conda or otherwise on windows.

Issue Description

Updates calls for CashFlow to call for TEAL instead.

For Change Control Board: Issue Review

This review should occur before any development is performed as a response to this issue.

• 1. Is it tagged with a type: defect or task?
• 2. Is it tagged with a priority: critical, normal or minor?
• 3. If it will impact requirements or requirements tests, is it tagged with requirements?
• 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
• 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.

• 1. If the issue is a defect, is the defect fixed?
• 2. If the issue is a defect, is the defect tested for in the regression test system? (If not explain why not.)
• 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)?
• 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)?
• 5. If the issue is being closed without a pull request, has an explanation of why it is being closed been provided?

Defect Description

I developed a validator for a 3-unit system composed of Balance of Plant (BOP), Secondary Energy Source (SES) and Thermal Energy Storage (TES). Under some situations the dispatcher cannot observe the validation constraints identified in a previous solve attempt. I outputted the dispatched value (curr) from pyomo and the constraints (V1) calculated by the validator when validation concerns are raised, see the docx file attached.
Dispatcher Issue.docx

What did you expect to see happen?

I am expecting that on Attempt 4, unit = TES, t=12, the dispatcher can issue a "curr" value lower than the upper constraint (V1= 501003.691) found in Attempt 3.

What did you see instead?

On Attempt 4, 5, ..., 101, unit = TES, t=12, the dispatcher never observe the upper constraint (V1= 501003.691) found in the previous solve attempt. In fact, only the upper constraint (V1= 501004.074) found in Attempt 2 is observed. The gap between “curr” and “V1” in Attempts 4 and beyond remain the same 0.383.

Do you have a suggested fix for the development team?

I contacted Paul Talbot and we think this issue is not associated with the numerical precision or tolerance. In the attached word file there is also a cyan highlighted case:
At Attempt 3, t=12, the SES has a dispatched value “curr= 18.557” and a lower constraint “V1= 19.317”, and the gap between them is 0.76. Later in Attempt 4, t=12, this constraint is observed.

It is interesting that a gap of 0.76 can be observed but a gap of 0.383 cannot be observed, maybe there is a threshold of such gap in pyomo dispatcher?

Describe how to Reproduce
Steps to reproduce the behavior:

1. Contact me directly and I can add you to my repository access list. I am providing the input file here, but it requires the customized validator and the ARMA to run.
   heron_input_para_BOP_SES_TES_MW.txt

Screenshots and Input Files
Please attach the input file(s) that generate this error. The simpler the input, the faster we can find the issue.

Platform (please complete the following information):

• OS: Microsoft Windows 10 Enterprise
• Version: 10.0.18363 Build 18363
• Dependencies Installation: CONDA

For Change Control Board: Issue Review

This review should occur before any development is performed as a response to this issue.

• 1. Is it tagged with a type: defect or task?
• 2. Is it tagged with a priority: critical, normal or minor?
• 3. If it will impact requirements or requirements tests, is it tagged with requirements?
• 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
• 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.

• 1. If the issue is a defect, is the defect fixed?
• 2. If the issue is a defect, is the defect tested for in the regression test system? (If not explain why not.)
• 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)?
• 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)?
• 5. If the issue is being closed without a pull request, has an explanation of why it is being closed been provided?

Testing 79b99e6

Test linux : Failed

View the results here.

Issue Description

Is your feature request related to a problem? Please describe.
I would like to request a feature that the optimization window length can be specified in the input file. Currently the window length is fixed to 24 hours, as listed in Line 70 of the "pyomo_dispatch.py".

Describe the solution you'd like
Allow the pyomo to read the <time_discretization> section for the <num_steps> entry from the input file, and update the "self._window_len" in the "pyomo_dispatch.py" accordingly. Paul said it would be possible to expose this window size to the user, by registering it in the “get_input_specs” and reading it in the “read_input”.

Describe alternatives you've considered
N/A

For Change Control Board: Issue Review

This review should occur before any development is performed as a response to this issue.

• 1. Is it tagged with a type: defect or task?
• 2. Is it tagged with a priority: critical, normal or minor?
• 3. If it will impact requirements or requirements tests, is it tagged with requirements?
• 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
• 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.

• 1. If the issue is a defect, is the defect fixed?
• 2. If the issue is a defect, is the defect tested for in the regression test system? (If not explain why not.)
• 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)?
• 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)?
• 5. If the issue is being closed without a pull request, has an explanation of why it is being closed been provided?

Issue Description

Allow different printing levels to be set for debugging dispatchers

For Change Control Board: Issue Review

This review should occur before any development is performed as a response to this issue.

• 1. Is it tagged with a type: defect or task?
• 2. Is it tagged with a priority: critical, normal or minor?
• 3. If it will impact requirements or requirements tests, is it tagged with requirements?
• 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
• 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.

• 1. If the issue is a defect, is the defect fixed?
• 2. If the issue is a defect, is the defect tested for in the regression test system? (If not explain why not.)
• 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)?
• 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)?
• 5. If the issue is being closed without a pull request, has an explanation of why it is being closed been provided?

Defect Description

Describe the defect

What did you expect to see happen?

HERON tests to pass in a PIP machine (Machine where dependencies are installed via PIP)

What did you see instead?

8/10 tests fail

FAILED:
Failed /home/civet/civet/build_0/raven/plugins/HERON/tests/integration_tests/cashflows/Cashflows
Failed /home/civet/civet/build_0/raven/plugins/HERON/tests/integration_tests/labels/Labels
Failed /home/civet/civet/build_0/raven/plugins/HERON/tests/integration_tests/multimarket_fix_price/MultimarketFixPrice
Failed /home/civet/civet/build_0/raven/plugins/HERON/tests/integration_tests/min_demand/MinDemand
Failed /home/civet/civet/build_0/raven/plugins/HERON/tests/integration_tests/production_flex/ProductionFlex
Failed /home/civet/civet/build_0/raven/plugins/HERON/tests/integration_tests/validator/ValidatorExample
Failed /home/civet/civet/build_0/raven/plugins/HERON/tests/integration_tests/var_demand_fix_price/VarDemandFixPrice
Failed /home/civet/civet/build_0/raven/plugins/HERON/tests/integration_tests/var_demand_var_price/VarDemandVarPrice

Do you have a suggested fix for the development team?

N/A

Describe how to Reproduce
Steps to reproduce the behavior:

1. Install dependecies via PIP (linux machine)
2. run_tests --plugins --re=HERON

Screenshots and Input Files
Please attach the input file(s) that generate this error. The simpler the input, the faster we can find the issue.

Platform (please complete the following information):

• OS: Linux
• Version: DEVEL
• Dependencies Installation: PIP

For Change Control Board: Issue Review

This review should occur before any development is performed as a response to this issue.

• 1. Is it tagged with a type: defect or task?
• 2. Is it tagged with a priority: critical, normal or minor?
• 3. If it will impact requirements or requirements tests, is it tagged with requirements?
• 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
• 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.

• 1. If the issue is a defect, is the defect fixed?
• 2. If the issue is a defect, is the defect tested for in the regression test system? (If not explain why not.)
• 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)?
• 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)?
• 5. If the issue is being closed without a pull request, has an explanation of why it is being closed been provided?

Defect Description

Describe the defect

What did you expect to see happen?

HERON can accept the project time equal to one year

What did you see instead?

A crash of RAVEN inner,

( 1.33 sec) STEP MULTIRUN : Message -> *** Initialization done ***
( 1.33 sec) STEP MULTIRUN : Message -> *** Beginning run ***
( 1.35 sec) EnsembleModel : DEBUG -> Submitting model flex
( 74.31 sec) ARMA : DEBUG -> Evaluating cycle 0
( 1.35 sec) DataSet : Warning -> Variables provided: dict_keys(['SampledVars', 'SampledVarsPb', 'crowDist', 'prefix', 'PointProbability', 'ProbabilityWeight', 'SamplerType', 'ProbabilityWeight-scaling', 'ProbabilityWeight-BOP_capacity', 'ProbabilityWeight-SES_capacity', 'ProbabilityWeight-TES_capacity', 'ProbabilityWeight-electr_market_capacity', 'ProbabilityWeight-denoises', 'jobHandler', 'uniqueHandler', 'scaling', 'Cycle', 'netLoad', 'Time'])
( 1.35 sec) DataSet : ERROR -> Provided realization does not have all requisite values for object "flex_samples": "Year"
--------------------------------------------------
There were 1 warnings during the simulation run:
(1 time) Variables provided: dict_keys(['SampledVars', 'SampledVarsPb', 'crowDist', 'prefix', 'PointProbability', 'ProbabilityWeight', 'SamplerType', 'ProbabilityWeight-scaling', 'ProbabilityWeight-BOP_capacity', 'ProbabilityWeight-SES_capacity', 'ProbabilityWeight-TES_capacity', 'ProbabilityWeight-electr_market_capacity', 'ProbabilityWeight-denoises', 'jobHandler', 'uniqueHandler', 'scaling', 'Cycle', 'netLoad', 'Time'])
--------------------------------------------------
( 1.36 sec) Job Handler : Message -> Process Failed <Runners.SharedMemoryRunner.SharedMemoryRunner object at 0x0000018319E92108> internal returnCode -1
( 1.36 sec) STEP MULTIRUN : DEBUG -> the job "1" has failed.

Do you have a suggested fix for the development team?

Describe how to Reproduce
Steps to reproduce the behavior:
1.
2.
3.
4.

Screenshots and Input Files
Please attach the input file(s) that generate this error. The simpler the input, the faster we can find the issue.

Platform (please complete the following information):

• OS: [e.g. iOS]
• Version: [e.g. 22]
• Dependencies Installation: [CONDA or PIP]

For Change Control Board: Issue Review

This review should occur before any development is performed as a response to this issue.

• 1. Is it tagged with a type: defect or task?
• 2. Is it tagged with a priority: critical, normal or minor?
• 3. If it will impact requirements or requirements tests, is it tagged with requirements?
• 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
• 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.

• 1. If the issue is a defect, is the defect fixed?
• 2. If the issue is a defect, is the defect tested for in the regression test system? (If not explain why not.)
• 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)?
• 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)?
• 5. If the issue is being closed without a pull request, has an explanation of why it is being closed been provided?

Issue Description

If an ARMA ROM is trained with <evalMode>full</evalMode>, the template writers don't undo that to use evalMode as clustered, resulting in full-size samples. It would be convenient to automatically convert those.

For Change Control Board: Issue Review

This review should occur before any development is performed as a response to this issue.

• 1. Is it tagged with a type: defect or task?
• 2. Is it tagged with a priority: critical, normal or minor?
• 3. If it will impact requirements or requirements tests, is it tagged with requirements?
• 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
• 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.

• 1. If the issue is a defect, is the defect fixed?
• 2. If the issue is a defect, is the defect tested for in the regression test system? (If not explain why not.)
• 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)?
• 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)?
• 5. If the issue is being closed without a pull request, has an explanation of why it is being closed been provided?

Defect Description

Describe the defect

What did you expect to see happen?

I trained an ARMA with 24 hours of power trajectory, but I only want to optimize for the first 20 hours.
The <time_discretization> in node is in the follows:
<time_discretization>
<time_variable>Time</time_variable>
<end_time>19</end_time>
<num_steps>20</num_steps>
</time_discretization>
I am expecting to see the optimization result for the first 20 hours (from hour 0 to hour 19).

What did you see instead?

In the "out~inner" output file, it returns an error:
"OSError: Requested number of steps (20) does not match "Time" history provided (24)!"

Do you have a suggested fix for the development team?

Maybe the HERON can perform a quick check of the ARMA time history before running:
if ARMA length > num_steps:
use num_steps for the optimization
else:
use ARMA length for the optimization

Describe how to Reproduce
Steps to reproduce the behavior:

1. For your information, the input file is in the fork "https://github.com/wanghy-anl/HERON.git", branch “wanghy/Validator_Constraints”:
   HERON\tests\integration_tests\validator_FARM\heron_input_para_BOP_SES_TES_MW.xml

Screenshots and Input Files
Please attach the input file(s) that generate this error. The simpler the input, the faster we can find the issue.

heron_input_para_BOP_SES_TES_MW.txt

Platform (please complete the following information):

• OS: [e.g. iOS] OS Microsoft Windows 10 Enterprise
• Version: [e.g. 22] 10.0.18363 Build 18363
• Dependencies Installation: [CONDA or PIP] CONDA

For Change Control Board: Issue Review

This review should occur before any development is performed as a response to this issue.

• 1. Is it tagged with a type: defect or task?
• 2. Is it tagged with a priority: critical, normal or minor?
• 3. If it will impact requirements or requirements tests, is it tagged with requirements?
• 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
• 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.

• 1. If the issue is a defect, is the defect fixed?
• 2. If the issue is a defect, is the defect tested for in the regression test system? (If not explain why not.)
• 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)?
• 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)?
• 5. If the issue is being closed without a pull request, has an explanation of why it is being closed been provided?

Issue Description

Printing verbosity (and logging in general) deserves a good consideration for HERON (and passthrough to TEAL).

For Change Control Board: Issue Review

This review should occur before any development is performed as a response to this issue.

• 1. Is it tagged with a type: defect or task?
• 2. Is it tagged with a priority: critical, normal or minor?
• 3. If it will impact requirements or requirements tests, is it tagged with requirements?
• 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
• 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.

• 1. If the issue is a defect, is the defect fixed?
• 2. If the issue is a defect, is the defect tested for in the regression test system? (If not explain why not.)
• 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)?
• 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)?
• 5. If the issue is being closed without a pull request, has an explanation of why it is being closed been provided?

Issue Description

At compile time, it would be nice to know if the ARMAs are set up to produce the right shape histories to be compatible with the desired calculation, rather than have a difficult-to-understand crash later at run time.

For Change Control Board: Issue Review

This review should occur before any development is performed as a response to this issue.

• 1. Is it tagged with a type: defect or task?
• 2. Is it tagged with a priority: critical, normal or minor?
• 3. If it will impact requirements or requirements tests, is it tagged with requirements?
• 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
• 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.

• 1. If the issue is a defect, is the defect fixed?
• 2. If the issue is a defect, is the defect tested for in the regression test system? (If not explain why not.)
• 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)?
• 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)?
• 5. If the issue is being closed without a pull request, has an explanation of why it is being closed been provided?

Issue Description

Right now HERON expects "Time" as the pivot parameter throughout the code. It would be great to be flexible enough to be able to specify a different pivot parameter name.

For Change Control Board: Issue Review

This review should occur before any development is performed as a response to this issue.

• 1. Is it tagged with a type: defect or task?
• 2. Is it tagged with a priority: critical, normal or minor?
• 3. If it will impact requirements or requirements tests, is it tagged with requirements?
• 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
• 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.

• 1. If the issue is a defect, is the defect fixed?
• 2. If the issue is a defect, is the defect tested for in the regression test system? (If not explain why not.)
• 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)?
• 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)?
• 5. If the issue is being closed without a pull request, has an explanation of why it is being closed been provided?

Defect Description

Describe the defect

What did you expect to see happen?

If the ARMA has not been trained using the node, there is no way to use the ARMA in the HERON workflow since the <year_variable> does not have any effect in the output of the ARMA.

What did you see instead?

Do you have a suggested fix for the development team?

Describe how to Reproduce
Steps to reproduce the behavior:
1.
2.
3.
4.

Screenshots and Input Files
Please attach the input file(s) that generate this error. The simpler the input, the faster we can find the issue.

Platform (please complete the following information):

• OS: [e.g. iOS]
• Version: [e.g. 22]
• Dependencies Installation: [CONDA or PIP]

For Change Control Board: Issue Review

This review should occur before any development is performed as a response to this issue.

• 1. Is it tagged with a type: defect or task?
• 2. Is it tagged with a priority: critical, normal or minor?
• 3. If it will impact requirements or requirements tests, is it tagged with requirements?
• 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
• 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.

• 1. If the issue is a defect, is the defect fixed?
• 2. If the issue is a defect, is the defect tested for in the regression test system? (If not explain why not.)
• 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)?
• 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)?
• 5. If the issue is being closed without a pull request, has an explanation of why it is being closed been provided?

Issue Description

Is your feature request related to a problem? Please describe.

Change production_flex and validator test gold file into ordered csv and add relative errors.

For Change Control Board: Issue Review

This review should occur before any development is performed as a response to this issue.

• 1. Is it tagged with a type: defect or task?
• 2. Is it tagged with a priority: critical, normal or minor?
• 3. If it will impact requirements or requirements tests, is it tagged with requirements?
• 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
• 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.

• 1. If the issue is a defect, is the defect fixed?
• 2. If the issue is a defect, is the defect tested for in the regression test system? (If not explain why not.)
• 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)?
• 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)?
• 5. If the issue is being closed without a pull request, has an explanation of why it is being closed been provided?

I made a model from the HERON storage test. I changed the capacities and then added an arma for the electrical grid. I had 2 armas (one for lmp, and the other for the eletrical grid load) and trained them with the same variable name "Signal". When I ran raven inner.xml it gave me issues with a GRO_dispatch_in_Time. When I made the variable names different the model ran fine in raven.

This review should occur before any development is performed as a response to this issue.

• 1. Is it tagged with a type: defect or task?
• 2. Is it tagged with a priority: critical, normal or minor?
• 3. If it will impact requirements or requirements tests, is it tagged with requirements?
• 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
• 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.

• 1. If the issue is a defect, is the defect fixed?
• 2. If the issue is a defect, is the defect tested for in the regression test system? (If not explain why not.)
• 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)?
• 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)?
• 5. If the issue is being closed without a pull request, has an explanation of why it is being closed been provided?

Issue Description

As discussed in our meeting, the added feature would be the ability to see what the dispatcher ran each component at throughout a time history.

Issue Description

It should be possible to run HERON without sweeping or optimizing anything in the outer loop. Currently this makes all "constant" nodes in the outer Grid Sampler or Optimizer, which results in a RAVEN error being thrown.

This can be trivially fixed by swapping to a Monte Carlo for this state, or more effectively by only running the "inner" without an "outer".

For Change Control Board: Issue Review

This review should occur before any development is performed as a response to this issue.

• 1. Is it tagged with a type: defect or task?
• 2. Is it tagged with a priority: critical, normal or minor?
• 3. If it will impact requirements or requirements tests, is it tagged with requirements?
• 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
• 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.

• 1. If the issue is a defect, is the defect fixed?
• 2. If the issue is a defect, is the defect tested for in the regression test system? (If not explain why not.)
• 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)?
• 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)?
• 5. If the issue is being closed without a pull request, has an explanation of why it is being closed been provided?

Defect Description

Describe the defect

What did you expect to see happen?

Successfully running outer.xml and getting a sweep.csv file

What did you see instead?

Jot submitted was aborted, showing the following error:

There were 1 warnings during the simulation run:
(1 time) There were 2 failed runs! Run with verbosity = debug for more details.

OSError: There were failed runs; aborting RAVEN.

Do you have a suggested fix for the development team?

Describe how to Reproduce
Steps to reproduce the behavior:
1.
2.
3.
4.

Screenshots and Input Files
Please attach the input file(s) that generate this error. The simpler the input, the faster we can find the issue.
production_flex.txt

production_flex.zip

Platform (please complete the following information):

• OS: [macOS]
• Version: [11.2.3]
• Dependencies Installation: [CONDA]

For Change Control Board: Issue Review

This review should occur before any development is performed as a response to this issue.

• 1. Is it tagged with a type: defect or task?
• 2. Is it tagged with a priority: critical, normal or minor?
• 3. If it will impact requirements or requirements tests, is it tagged with requirements?
• 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
• 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.

• 1. If the issue is a defect, is the defect fixed?
• 2. If the issue is a defect, is the defect tested for in the regression test system? (If not explain why not.)
• 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)?
• 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)?
• 5. If the issue is being closed without a pull request, has an explanation of why it is being closed been provided?

Issue Description

HERON currently only uses "Year" as the macro parameter. It'd be swell if this was a user option.

Note this still assumes all ARMAs use the same names; we're not at the point of handling multiple ARMA time scales well yet.

For Change Control Board: Issue Review

This review should occur before any development is performed as a response to this issue.

• 1. Is it tagged with a type: defect or task?
• 2. Is it tagged with a priority: critical, normal or minor?
• 3. If it will impact requirements or requirements tests, is it tagged with requirements?
• 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
• 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.

• 1. If the issue is a defect, is the defect fixed?
• 2. If the issue is a defect, is the defect tested for in the regression test system? (If not explain why not.)
• 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)?
• 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)?
• 5. If the issue is being closed without a pull request, has an explanation of why it is being closed been provided?

Issue Description

What did you expect to see happen?

A full clean plugin install.

What did you see instead?

Same issue has happened for other users.

Do you have a suggested fix for the development team?

Some rights requirements need to be turned off?

Please attach the input file(s) that generate this error. The simpler the input, the faster we can find the issue.

For Change Control Board: Issue Review

This review should occur before any development is performed as a response to this issue.

• 1. Is it tagged with a type: defect or task?
• 2. Is it tagged with a priority: critical, normal or minor?
• 3. If it will impact requirements or requirements tests, is it tagged with requirements?
• 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
• 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.

• 1. If the issue is a defect, is the defect fixed?
• 2. If the issue is a defect, is the defect tested for in the regression test system? (If not explain why not.)
• 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)?
• 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)?
• 5. If the issue is being closed without a pull request, has an explanation of why it is being closed been provided?

Issue Description

Sometimes a custom dispatch is necessary, or simpler than using existing dispatch strategies. A simple API for quick custom dispatching would be great.

For Change Control Board: Issue Review

This review should occur before any development is performed as a response to this issue.

• 1. Is it tagged with a type: defect or task?
• 2. Is it tagged with a priority: critical, normal or minor?
• 3. If it will impact requirements or requirements tests, is it tagged with requirements?
• 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
• 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.

• 1. If the issue is a defect, is the defect fixed?
• 2. If the issue is a defect, is the defect tested for in the regression test system? (If not explain why not.)
• 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)?
• 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)?
• 5. If the issue is being closed without a pull request, has an explanation of why it is being closed been provided?

Defect Description

HERON needs to be updated to conform with recent RAVEN updates.

This is a rolling issue, so it should not generally be closed.

For Change Control Board: Issue Review

This review should occur before any development is performed as a response to this issue.

• 1. Is it tagged with a type: defect or task?
• 2. Is it tagged with a priority: critical, normal or minor?
• 3. If it will impact requirements or requirements tests, is it tagged with requirements?
• 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
• 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.

• 1. If the issue is a defect, is the defect fixed?
• 2. If the issue is a defect, is the defect tested for in the regression test system? (If not explain why not.)
• 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)?
• 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)?
• 5. If the issue is being closed without a pull request, has an explanation of why it is being closed been provided?

Defect Description

Describe the defect

When using a transfer function in a component, the meta object becomes nested with call the the evaluate method.

What did you expect to see happen?

The meta object should be updated, but not become nested when a component transfer function is evaluated.

What did you see instead?

The meta object nested once for each iteration causing a crash later on.

Do you have a suggested fix for the development team?

I have a fix with a unit test addressing this is a PR.

Describe how to Reproduce
Steps to reproduce the behavior:

1. Write a custom dispatcher that evaluates a dispatch using a user-provided transfer function.

Screenshots and Input Files
Please attach the input file(s) that generate this error. The simpler the input, the faster we can find the issue.

Platform (please complete the following information):

• OS: Fedora
• Version: 32
• Dependencies Installation: CONDA

For Change Control Board: Issue Review

This review should occur before any development is performed as a response to this issue.

• 1. Is it tagged with a type: defect or task?
• 2. Is it tagged with a priority: critical, normal or minor?
• 3. If it will impact requirements or requirements tests, is it tagged with requirements?
• 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
• 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.

• 1. If the issue is a defect, is the defect fixed?
• 2. If the issue is a defect, is the defect tested for in the regression test system? (If not explain why not.)
• 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)?
• 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)?
• 5. If the issue is being closed without a pull request, has an explanation of why it is being closed been provided?

Issue Description

If there's no stochasticity in the problem, we can eliminate the inner and only run a single-level RAVEN run for optimization or sweeping. This would be a simple thing to detect and modify in the templating.

For Change Control Board: Issue Review

This review should occur before any development is performed as a response to this issue.

• 1. Is it tagged with a type: defect or task?
• 2. Is it tagged with a priority: critical, normal or minor?
• 3. If it will impact requirements or requirements tests, is it tagged with requirements?
• 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
• 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.

• 1. If the issue is a defect, is the defect fixed?
• 2. If the issue is a defect, is the defect tested for in the regression test system? (If not explain why not.)
• 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)?
• 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)?
• 5. If the issue is being closed without a pull request, has an explanation of why it is being closed been provided?

Defect Description

If:

• a negative value is used for a cashflow driver (instead of placing the negative on the price)
• and the reference driver is not negative (it defaults to 1)
• and the scaling factor is not identically one
  then the cashflow computation can result in imaginary numbers for cashflows, which can cause lots of problems.

Suggested fix is to check if a driver is negative, and either error out or move it to the price.

Having the driver negative honestly doesn't make much philosophical sense, but it can be done.

For Change Control Board: Issue Review

This review should occur before any development is performed as a response to this issue.

• 1. Is it tagged with a type: defect or task?
• 2. Is it tagged with a priority: critical, normal or minor?
• 3. If it will impact requirements or requirements tests, is it tagged with requirements?
• 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
• 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.

• 1. If the issue is a defect, is the defect fixed?
• 2. If the issue is a defect, is the defect tested for in the regression test system? (If not explain why not.)
• 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)?
• 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)?
• 5. If the issue is being closed without a pull request, has an explanation of why it is being closed been provided?

Issue Description

It should be possible to add constraints to the outer optimization via the HERON input.

For Change Control Board: Issue Review

This review should occur before any development is performed as a response to this issue.

• 1. Is it tagged with a type: defect or task?
• 2. Is it tagged with a priority: critical, normal or minor?
• 3. If it will impact requirements or requirements tests, is it tagged with requirements?
• 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
• 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.

• 1. If the issue is a defect, is the defect fixed?
• 2. If the issue is a defect, is the defect tested for in the regression test system? (If not explain why not.)
• 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)?
• 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)?
• 5. If the issue is being closed without a pull request, has an explanation of why it is being closed been provided?

Issue Description

It would be nice to be able to confirm the viability of dispatch decisions via models, surrogates, or any other validation metric that may be useful.

This aligns with the ANL work on the reference governor.

For Change Control Board: Issue Review

This review should occur before any development is performed as a response to this issue.

• 1. Is it tagged with a type: defect or task?
• 2. Is it tagged with a priority: critical, normal or minor?
• 3. If it will impact requirements or requirements tests, is it tagged with requirements?
• 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
• 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.

• 1. If the issue is a defect, is the defect fixed?
• 2. If the issue is a defect, is the defect tested for in the regression test system? (If not explain why not.)
• 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)?
• 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)?
• 5. If the issue is being closed without a pull request, has an explanation of why it is being closed been provided?

Issue Description

I am trying to optimize the LCOE for an energy system and would appreciate an easier way to use the outputs from my model to solve for the LCOE.
Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

For Change Control Board: Issue Review

This review should occur before any development is performed as a response to this issue.

• 1. Is it tagged with a type: defect or task?
• 2. Is it tagged with a priority: critical, normal or minor?
• 3. If it will impact requirements or requirements tests, is it tagged with requirements?
• 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
• 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.

• 1. If the issue is a defect, is the defect fixed?
• 2. If the issue is a defect, is the defect tested for in the regression test system? (If not explain why not.)
• 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)?
• 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)?
• 5. If the issue is being closed without a pull request, has an explanation of why it is being closed been provided?

Issue Description

Even though the DispatchManager can handle arbitrary ARMAs, there's still issues with the templating system detecting whether to include macro parameters (Year, Cluster, ClusterTime) in the outer-inner files.

This should be enhanceable by interrogating the ARMA files ahead of time to determine what their structure is. For now, it is required to have at least a one-year interpolated ARMA.

For Change Control Board: Issue Review

This review should occur before any development is performed as a response to this issue.

• 1. Is it tagged with a type: defect or task?
• 2. Is it tagged with a priority: critical, normal or minor?
• 3. If it will impact requirements or requirements tests, is it tagged with requirements?
• 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
• 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.

• 1. If the issue is a defect, is the defect fixed?
• 2. If the issue is a defect, is the defect tested for in the regression test system? (If not explain why not.)
• 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)?
• 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)?
• 5. If the issue is being closed without a pull request, has an explanation of why it is being closed been provided?

I have created a model that uses a steam generator that then uses a turbine to convert the steam to electricity. The electricity is then is consumed by two power grids. The primary grid that the electricity goes to has a load that is characterised by an ARMA model. For this model there are two ARMAs the first one is used for economic stuff as used in the production_flex test, and another one describes the demand for the power grid. This code runs great when I have the primary power grid at a fixed value but as soon as I change it to use an ARMA it breaks. I have been following the instruction manual that I built from the docs folder but it doesn't offer very much information for this part.

It gave this error:

Traceback (most recent call last):
  File "/home/prism/repos/HERON/src/main.py", line 96, in <module>
    sim.read_input(args.xml_input_file) # TODO expand to use arguments?
  File "/home/prism/repos/HERON/src/main.py", line 52, in read_input
    objects = input_loader.parse(inp, location, self.messageHandler)
  File "/home/prism/repos/HERON/src/input_loader.py", line 58, in parse
    comp.read_input(comp_xml, case.get_mode())
  File "/home/prism/repos/HERON/src/Components.py", line 121, in read_input
    demand.read_input(item, mode, self.name)
  File "/home/prism/repos/HERON/src/Components.py", line 1085, in read_input
    Interaction.read_input(self, specs, mode, comp_name)
  File "/home/prism/repos/HERON/src/Components.py", line 412, in read_input
    self._set_valued_param(name, comp_name, item, mode)
  File "/home/prism/repos/HERON/src/Components.py", line 442, in _set_valued_param
    signal = vp.read(comp, spec, mode)
  File "/home/prism/repos/HERON/src/ValuedParams.py", line 152, in read
    typ, node, signal, request = self._load(comp_name, spec, mode, alias_dict)
  File "/home/prism/repos/HERON/src/ValuedParams.py", line 238, in _load
    signals = item.findFirst('ARMA').parameterValues['variable']
KeyError: 'variable'

Please attach the input file(s) that generate this error. The simpler the input, the faster we can find the issue.

heron_input.txt

For Change Control Board: Issue Review

This review should occur before any development is performed as a response to this issue.

• 1. Is it tagged with a type: defect or task?
• 2. Is it tagged with a priority: critical, normal or minor?
• 3. If it will impact requirements or requirements tests, is it tagged with requirements?
• 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
• 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.

• 1. If the issue is a defect, is the defect fixed?
• 2. If the issue is a defect, is the defect tested for in the regression test system? (If not explain why not.)
• 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)?
• 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)?
• 5. If the issue is being closed without a pull request, has an explanation of why it is being closed been provided?