[DEFECT] Bug in create_componentsets_in_HERON() function

[caleb-sitton-inl]

Thank you for the defect report

• [X] I am using the latest version of FORCE.
• [X] I have created a minimum, reproducible example that demonstrates the defect.

Defect Description

Under certain circumstances, the src/heron/create_componentsets_in_HERON() function will not correctly update HERON components. Specifically, when multiple back-to-back children nodes of a single cashflow both need to be updated, the second will not be deleted. This causes a duplication of the node instead of its replacement and incorrect updating. The cause is a for loop in which children nodes that need to be updated are directly removed. This causes the iterator to skip over subsequent children nodes.

Steps to Reproduce

1. Create a HERON input XML script (see screenshot below for example)
   • Ensure it contains a component with an <economics> subnode that has a <CashFlow> child
   • Ensure above CashFlow has a name containing the string "capex"
   • Place two or more subnodes back-to-back as children of the capex CashFlow node that need to be updated (e.g., <reference_driver>, <reference_price>, or <scaling_factor_x> nodes)
2. Call src/heron/create_componentsets_in_HERON() function with the above XML script and a valid componentSets folder containing a component set with the same name as the component in the HERON input XML
3. Observe output as an XML script or run <result_tree_name>.findall('./Components/Component/economics/CashFlow/<second_child_name>') (see screenshot)

Expected Behavior

The function should remove all <reference_driver>, <reference_price>, and <scaling_factor_x> children nodes of the capex CashFlow. It should then add new nodes with the values from the componentSet file. Thus, there should be exactly one each of the <reference_driver>, <reference_price>, and <scaling_factor_x> subnodes within the capex CashFlow.

Screenshots and Input Files

OS

MacOS

OS Version

No response

Dependency Manager

CONDA

For Change Control Board: Issue Review

• [x] Is it tagged with a type: defect or task?
• [x] Is it tagged with a priority: critical, normal or minor?
• [x] If it will impact requirements or requirements tests, is it tagged with requirements?
• [x] If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
• [x] Is a rationale provided? (Such as explaining why the improvement is needed or why current code is wrong.)

For Change Control Board: Issue Closure

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