Incorrect "extsou" value after retrieving initial conditions (SNAP 4.0.2, TRACE plugin 4.4.3)

[NRCgg]

(posting for Rey Peinado, Luis lrey@iberdrola.es )

I attached the problem we had with the extsou card value after initializing. This is in the new SNAP 4.0.2 and TRACE plugin 4.4.3

If you need the files to run and reproduce the problem just tell me (about 18.3Mb the .med and .tpr files).

<< note - the attachment was marked "Internal Use", so I am including it only via this restricted link >>

Note: Related issue: #19

[wrd-apt]

I looked into the word document describing the problem in more detail on box. It identifies the problem as the EXTSOU property of a Power component being set to -1E30 after retrieving initial conditions. That is the sentinel value in TPR when the value isn't being set by TRACE. While we can (and will) fix the TRACE plug-in to not modify the EXTSOU value when the TPR contains the unset value, I wonder if this should also be reported to the TRACE development team.

[NRCgg]

@wrd-apt: (quoting reply from Rey Peinado, Luis lrey@iberdrola.es email):

I asked Chester about this issue cause we thought is more a SNAP problem.

Jus to put you in situation:

We are doing some BEPU analysis and for sensitivity cases we change the materials properties (we use 6 different UO2 materials) and the only way we found was to use the Custom Processing from SNAP to inject the code and read the numerics (defined variables in SNAP) to generate the different cases. The Custom Processing was Pre-Execution Python. So we found this problem: when SNAP was to do Pre-Execution and initialization from a restart, it doesn’t apply the pre-execution python text injection. We reported this to the SNAP people (via Chester bc we don’t have Git) and they came up with the version 4.0.2 and TRACE plugin version 4.4.3. In the changelog they said: "Change Log Version 4.4.3 - Released 2/28/2022: ... The TRACE job step "Retrieve Initial Conditions" feature was updated to more correctly support the modification of the restart case with Pre-Execution Python scripting. ..."

With this change we found that now the SNAP creates a temporal file pre_ic.inp in the working job folder. So we know SNAP now do something different than before. But now, the problem is that when try to initialize they change the "extsou" value to -1E30. That’s when the developer said "is the sentinel value in TPR when the value isn't being set by TRACE" "wonder if this should also be reported to the TRACE development team".

Trace is Patch 5 (trace-V50p5-windows-msvs2017-ivf-x64-Release.exe) SNAP is 4.02 TRACE plugin is 4.4.3

This rises another situation for us. Before this update we thought the Pre-Execution Python was done after SNAP TRACE initialization, but now we know (with the pre_ic.inp file) that is done before initialization. We think that the flow should be like:

Restart Input -> Initialize -> Pre-Execute Python -> RUN

The reason is that you don’t want the initialization to overwrite something you inject with the pre-execution. In our mind the case restart input take the initial conditions for the components, then you modify the input with your numerics (generate multiple cases) and the run each case.

This is our guess, feel free to correct us if we are not doing it right.

[NRCgg]

Feedback from Chris Murray (TRACE dev team):

The issue with extsou was likely corrected with TRACE V5.1340. Extsou was changed from being a persistent data quantity to a state data property (because we added the ability for extsou to be defined by a control block). So now, the value of extsou that SNAP will pick up out of the TPR file should not suffer from being undefined.

Chris

[NRCgg]

(quoted email from Rey Peinado, Luis lrey@iberdrola.es )

Thanks Chris,

This was not happening with previous version of SNAP 3.1.8 and the same TRACE Patch 5 (trace-V50p5-windows-msvs2017-ivf-x64-Release.exe). We should go back to the previous SNAP version to keep working.

I would like to ask you what do you think about the Pre-Processing of the input in SNAP? Do you think it should be before or after the initialization? We still think that it should be after the initialization, to allow the user to further modify the input, but we may be seeing it from a wrong perspective.

Thanks again. Best regards. Luis.

[NRCgg]

@wrd-apt (quoting response from Dunsford, William William.Dunsford@nrc.gov )

I just performed a code review of the SNAP TRACE Plug-in Execution Wrapper (which loads the TPR file). This operation is performed at the same time as the FRAPCON fuel rod import process which occurs immediately preceding executing the TRACE application. So the order of operations is:

Setup Commands -> Pre Execution Commands -> Pre Execution Python -> Retrieve Initial Conditions -> Retrieve FRAPCON Fuel Properties -> Execute TRACE -> Post Execution Commands -> Post Execution Python -> Stage Files / Remove File Flagged for Deletion.

The problem with changing this order is that other users may depend on this order for their scripts / commands etc. However, as of SNAP TRACE Plug-in version 4.4.2, retrieving the TPR file initial conditions no longer throws away any changes made to the ASCII input file. The EXTSOU issue is explicitly a TPR State Data import issue, and will be resolved with the next TRACE plug-in release, which is currently undergoing final review and testing.

Incidentally the EXTSOU issue has to do with the state data value in the TPR file being uninitialized. The uninitialized value sentinel value is -1E30 for floating point data in a TPR file. I’m not clear on why the TPR file contained this value, but the TRACE plug-in will only set the EXTSOU value from a KineticsSD block if the value is not equal to -1E30. In this case the value is explicitly set to 0.0.

[dul-apt]

TRACE plug-in version 4.5.0: The TPR import logic for the EXTSOU property of a power component was updated to prevent loading the "unset" value from a TPR file.