[DEFECT] Debug mode does not work with opt mode

[GabrielSoto-INL]

---

Defect Description

Describe the defect
Nominally, HERON has two options for <mode> in the XML input: sweep or opt. Users can add an additional node to the parent <Case> node to overwrite these two and instead run a shorter debug using the <debug> node. The <mode> node stays in the XML in this case. If the XML script has a combination sweep and debug modes:

<Case>
...
  <mode>sweep</mode>
  <debug/>
...
</Case>

then the debug mode is executed correctly. If the XML script has a combination of opt and debug modes:

<Case>
...
  <mode>opt</mode>
  <debug/>
...
</Case>

then the HERON run fails.

What did you expect to see happen?

Debug mode should work regardless of what <mode> is specified.

What did you see instead?

Two errors depending on whether a user selected GradientDescent or the BayesianOpt algorithms within opt mode. Screenshots are shown below. These are typically errors regarding ElementTree parsing.

Do you have a suggested fix for the development team?

This seems like a template_driver.py problem.

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.

Error in HERON when using BayesianOpt:

Error in HERON when using GradientDescent:

Platform (please complete the following information):

• OS: Windows
• 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?