[DEFECT] Debug mode does not work with opt mode

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:

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.

[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?

idaholab / HERON