NRC-Research / SNAP-issues

This repository was created to provide a public location to record and display the status of "issues" for the SNAP application. The SNAP developers will acknowledge, provide (and maybe request) feedback on the reported issues, and in general use the information to improve SNAP code.
3 stars 0 forks source link

Import TRACE (ASCII / TPR) change the input affecting the results #15

Closed krjones-apt closed 3 years ago

krjones-apt commented 3 years ago

This issue was reported by Luis Rey Peinado, lrey@iberdrola.es: issue003_CNAT2021.zip

Model Editor 3.1.8 TRACE Plugin 4.3.0 trace-V50p5-windows-msvs2017-ivf-x64-Release.exe Input files taken from V50P5MasterList, SStest1.inp and RSTtest1.inp. The goal is to validate the runs via SNAP, comparing the results with the original files executed using the cmd to run TRACE. (trace-V50p5-windows-msvs2017-ivf-x64-Release.exe) The problem is when the input file is imported in SNAP. We tested ASCII and TPR at 0s and both imports are different from the original file. There are several key components changed, fa, hd, rdpw, mixednumerics... The ASCII seems more wrong than the TPR one when comparing with the original file. This issue also happens when inport a case files (RSTtest.inp), although in this case you can open the file and copy the orinal content. I attached the input files for the RSTtest1.inp original and the ones generated via SNAP to see the differences. Also the one for the restart case.

wrd-apt commented 3 years ago

The differences in the models stems from errors in the original TRACE input deck. The errors include an NPIPES value of 0 for the Single Junction component and inconsistent edge data between the Time Dependent Junction and the Pipe inlet.

1: Single Junction 236 has a NPIPES value of 0. SNAP uses the NPIPES value to calculate the appropriate flow area for edges that are shared between components, to ensure that the same total flow area is applied to either side of the connection. In this case, a value of 0 for NPIPES is resulting in a calculated flow area of 0.0. TRACE treats a NPIPES value of 0 as 1 internally, so the SNAP TRACE Plug-in will be updated to automatically convert NPIPES of 0 to 1 during ASCII import. This will resolve the issue of the flow area value on the outlet edge of Pipe 234 being converted to 0.0.

2: The geometric, friction, and initial condition data for the edge shared between Pipe 234 and TDJ 232 are inconsistent. SNAP ensures that connected edges have the same geometric data, friction data and initial condition values. In this case, the original model contains the following different values (TDJ vs Pipe): • Hydraulic Diameter: ( 0.06846575 vs 7.63E-3) • K-Factor ( 0.0 vs 1.3 ) • Rev. K-Factor (0.0 vs 1.3 ) • Liquid Velocity (8.899944 vs 0.0)

In the case of inconsistent edge data during ASCII import the TRACE plug-in will choose one of the edges to populate the shared data. The rules for which edge becomes dominant can be summarized using the following hierarchy:

  1. Single Junction Components (SJ, TDJ, VLV)
  2. Outlet of a Component connected to an Inlet of a Component
  3. Lower Component Number

In this case, the TDJ has the lower component number, and its outlet is connected to the pipes inlet. On ASCII import SNAP will copy the TDJ data to the inlet edge of the pipe. The SNAP TRACE plug-in will be updated to notify the user when inconsistent edge data is encountered during an ASCII import, and indicate which component's data will be used.

The SNAP TPR import process is not fully testing. TRACE itself calculates certain model parameters during the ASCII input phase of the calculation, and places the calculated value in the TPR file. For example in this case the NZMAX of the heatstructures is converted to 36, and the PDRAT field is activated and set to 1.33. The output file from the original case contains warning messages indicating that these fields will be updated.

Attached is a zip file that contains a series of TRACE input files derived from the original input file:

CNAT2021_Files.zip