Sponsored by the U. S. Nuclear Regulatory Commission Volume 13 / Number 1 / December 2013
Download 326.54 Kb.
|
- Navigate this page:
- Items of Interest
Recent RELAP5 User Problems R ELAP5 user problems reported or resolved are summarized in each issue of the newsletter. If you encounter a problem with RELAP5, please report it to Joseph.Staudenmeier@nrc.gov.The complete list of RELAP5 user problems, including a description of the problem, status (resolved, in work, on hold or unresolvable) and, if resolved, the manner of resolution, is available on the https://www.nrccodes.com web site. Since the last TH newsletter was published nine new user problems were submitted. Six of these problems were resolved and two were placed on hold. A description of these user problems is provided below in chronological order. No. 2012-08 (10/1/2012) Code Versions Affected: RELAP5/Mod3.3 Patch04 The user reported an execution error when RELAP5/Mod3.3Patch4 was coupled with PARCS. This error occurred regardless of the PARCS version (v2.7, v3.0, v3.2). However, this error was nonexistent in earlier versions of RELAP5, i.e., Mod3.3Patch3, using the same input deck. The coupled RELAP5/PARCS was simulating an operational transient at Ringhals-3 nuclear power plant. During the steady state calculation, after several time steps, the calculation terminated and RELAP5 produced an error indicating bad void fractions. Checking the output files did not reveal any suspicious / unphysical parameters. Moreover, comparing with those obtained from a successful simulation (Patch3) did not show any significant differences up to the time step the code crashed. Resolution (10-08-12): The input decks were received from the user, and upon further examination, the void fractions were becoming slightly negative (-1.0e-20), which caused the error checking logic in the RDMR to be tripped. Logic was added to the RDMR to include an epsilon of +/-1.0e-6 in the void fraction evaluation. This eliminated the problem and the coupled code ran successfully to the specified end time. No. 2012-09 (10/1/2012) Code Versions Affected: RELAP5/Mod3.3 Patch04 Under certain conditions, discontinuities in the mass flow rate of a two-phase fluid could be observed in a RELAP5 model of Forsmark 1 system 323 sub 2. The discontinuities appeared in a junction, modeling a reducer (diameter 300 mm to 200 mm) in a vertical pipe. During a 5 ms long time interval the mass flow rate oscillates at almost every major time step with approximately 15 kg/s, i.e. 0.08 g of water moves back and forth through the junction during one oscillation. Following initial observation, the cause of the problem was likely due to level tracking turned on in a couple of pipes. Gas surge that propagates through the pipes causes activation of level tracking when it shouldn’t be on. The user was advised to turn off level tracking. In addition, modifications to the level detection logic that would work for the user's calculation scenario could be explored. On Hold (04-09-13): Have not heard any feedback from the user on this issue. No. 2012-10 (10/8/2012) Code Versions Affected: RELAP5/Mod3.3je The user reported problems with a model containing a relief valve opening. Two input files were provided that are the same except that the size of the orifice representing the relief valve is smaller in one case. In the model, there are four relief valves going to one of two tanks. In these input files, the opening relief valve is component 2 while the flow is going to the tank at component 57. The problem was that while the 900 case ran very smoothly, the 475 case was quite unstable. In the 475 case there were a number of pipes (volume 1903 for instance) where things were smooth for the first ten seconds or so, but then when voidf reached a low point of near 0.2, the solution became unstable. It appeared as though the flow regime was switching from slug flow to stratified flow at a high frequency. This was causing all sorts of disturbances in the flow as seen in velocities, densities, etc throughout the rest of the pipe. In the 900 case, the liquid void fraction never dropped below around 0.4 and the flow regimes were steady. Similar behavior has been seen with this instability in several other models; it always seems to happen when voidf approaches 0.2 to 0.3. On Hold (11-14-2012): Several attempts were made to relax the transition between slug / horizontal stratification, and between bubbly / slug and slug / annular mist. In addition, attempts were made to relax the interfacial drag and interfacial heat transfer directly. There was some minimal impact, but ultimately, the oscillations were not mitigated. Some further study is needed to make the flow regime map more consistent across flow boundaries. No. 2012-11 (12/3/2012) Code Versions Affected: RELAP5/Mod3.3 Patch04 When building the code with the “-map” configure option, the compilation of stateq.ff failed. There were numerous failures including variables not declared and endif’s out of place. Resolution (12-04-12): The undeclared variables were addressed by adding the sparms.hh header file along with declaring the spropstat(:) array. In addition, several array indices were changed from ivx to ix and a misplaced endif was replaced with an appropriate if-test. The code now compiles stateq.ff without errors. No. 2013-01 (1/7/2013) Code Versions Affected: RELAP5/Mod3.3 Patch04 The user reported difficulty building the code with Cygwin on Windows 7 64bit SP1 Pro using the IFC compiler. The issue was that some scripts had the ^M end of line character which should have been stripped off. The configure and bldhh scripts called ‘d2u’ to convert these files, but that alias is no longer available in Cygwin. Resolution (01-07-13): The ‘d2u’ calls were replaced with ‘dos2unix’. This resolved the user problem and the build process completed successfully. No. 2013-02 (1/7/2013) Code Versions Affected: RELAP5/Mod3.3 Patch04 The user reported liquid appearing in a model that only contained non-condensable. The user needed to be setting Word 5 on Card 120 to “2”, indicating a pure non-condensable case. However, after setting this value, the case failed early on. Resolution (01-07-13): A change to eqfinl in version 3.3ik broke the code when running pure noncondensables. The logic that was added to version 3.3ik needed to include a test that the case was not pure noncondensables. This if-test was added to the code and pure noncondensable cases now run. No. 2013-03 (3/19/2013) Code Versions Affected: RELAP5/Mod3.3 Patch04 The user reported the following error: “******** number of words on a card or total number of words on cards too large, processing terminated.” The error is due to a limit in inp.ff that restricts the number of available words to 2^19. The user has requested extending this to 2^21. However, when it was previously extended from 2^17 to 2^19 (3.3hi), there were only two additional bits available. Now, there are no more available bits in the mask to extend the limit to 2^21, so a more complicated fix is required. This user problem remains “in work”. No. 2013-04 (4/1/2013) Code Versions Affected: RELAP5/Mod3.3 Patch04 The user reported difficulty getting an input model to run after converting from a Mod3.1.1 input deck. The issue seems related to the modeling of cross flow junctions. Resolved (04-09-13): The user's input model was fixed to work with Mod3.3Patch04. The fix consisted of three things. First, junction 3 of component 200 (crossflow junction) was changed to connect to the side of component 200 rather than the top. This fixed the input processing issue. Second, the problem failed at about 1.4 second due to a high pressure in the CST. The resolution was to make the area of the TDV connected to the top of the CST large (it was very small compared to the CST area). Third, changed the time step control flage for tt = 2 to tt = 3. This allowed the code to complete its calculation rather than fail at about 40 s. There were some follow-on questions concerning valve operations and trip logic that were also resolved. No. 2013-05 (5/8/2013) Code Versions Affected: RELAP5/Mod3.3 Patch04 The user had problems when reading cards 6SS00000. Error messages like these below appear: 0******** too many numbers on cards 60100000 through 60100000 0******** Delete expected but not found on card 0******** too many numbers on cards 60200000 through 60200000 0******** Delete expected but not found on card In addition, some problems were discovered when building the code with the g77 compiler. Resolution (05-10-13): The problem with the radiation enclosure model was a bad indexing location in the ‘a’ array. Using the debugger it was noted that at the beginning of the rradht.ff subroutine, the index number n3 was 486. In this logic, the code searches for card 60000000. If found, the input processing moves forward. It then looks for card number 6SS00000 by calling inplnk. inplnk bumps the index number (n3) by 2. If the card number is found, it then checks to see if the 1st word in 6SS00000 is an integer or a delete card by calling impmod. However, the location to start the check was in the wrong spot, therefore an error resulted. The solution to fix the problem was to reset the index number before calling impmod. Regarding the g77 compiler issues, the cnv32.f and stgd2o.ff routines didn’t compile because intrinsic function ‘trim’ is not recognized by g77. The ‘action=read’ item in the open function also was not recognized by g77. Envrl subroutine psatd2o.ff did not compile because common block declarations were placed after data statements. Relap subroutine rvalve.ff did not compile because a comma was missing in format statement 3140. All of these items were corrected in this update. Items of Interest T he Spring 2014 CAMP Meeting will be held at the Faculty of Electrical Engineering and Computing (FER) in Zagreb, Croatia. The meeting will be May 7 – 9, and additional information, including the registration form, can be found on the NRCCodes Sharepoint site (https://www.nrccodes.com). TRACE V5.0 Patch 4 is currently scheduled for release in March 2014. The focus for Patch 4 has been to make the code more robust and to make key modeling improvements. This version will include the following major features: Make the IAPWS tables the default EOS algorithm Generic working fluids (NIST database) Refactored interfacial heat transfer logic Mechanistic CONTAN models for sprays and films on walls and improved CONTAN/TRACE communication (signal variables, trips) PIPE-based pressurizer modeling Higher order methods, with component-by-component selection of numerical method Multi-step backup capability Fuel rod model improvements Metal-water reaction improvements Helical coil & cross flow heat transfer models AUTO multistep backup capability Improved error message behavior Implicit wall heat transfer modeling option This work has been driven by user needs, which includes adding features needed to model small modular reactors (integral PWRs). Considerable effort is also being spent on making code modifications and improvements to support NRC staff who are using TRACE/PARCS to simulate transients where neutronics/thermal-hydraulics coupling is important. As such, TRACE V5.0 Patch 4 will include PARCS v32m11, which contains the following upgrades: Changes Wielandt shift with adaptive parameter Adds limiters for the ADF adjusting factor in CMFD based on GET Adds I and Pm densities, and core average beta, output to dep file Implements of z-direction discontinuity factors Adds Xe/Sm density calculation at shutdown cooling period Allows user to directly input incremental core average burnup Adds termination logic for control rod critical position search when neutronics have reached maximum iterations but TH solution is not converged Rewrites detector response, and enable detector edit output for each depletion point Adds more Xe/Sm options Adds option for starting transient from subcritical state Adds prediction of reactivity worth of each control rod by bilinear weighting Limits time step size increasing to 2 times at one step unless user requires sudden larger increment Rewrites critical control rod position searching Adds a user input option for linear or quadratic precursor approximation The exponential integration is approximated with 3rd order Taylor expansion when lambda* delt <0.001 which is more reliable than direct evaluation Future improvements of TRACE will continue to focus on enhancing capabilities related to the simulation of new and advanced reactor designs. In addition, the focus will continue to be on improving the robustness and accuracy of the code. You are encouraged to visit the SharePoint site, https://www.nrccodes.com. You can join in discussions, download relevant documents, access TRACE (Bugzilla) and RELAP5 User Problem descriptions and, for CAMP members, access information on the CAMP program including status of proposed and active in-kind contributions, announcements and a calendar of upcoming events. The discussions area supports asking questions and sharing experiences. Chris Murray is the contact point for the SharePoint site. If you have any problems accessing the site, or if you have any questions or would like additional information on the NRC TH codes, please contact Chris Murray at Christopher.Murray@nrc.gov or 301‑251‑7513. Directory: Newsletters Newsletters -> Last year four of the best Afrikaans Christian singers joined forces to tour Down Under with the production ‘Manne wat Glo’ Newsletters -> An Extension Cord to mars Newsletters -> In this issue Newsletters -> - Newsletters -> Acoustics Shock Vibration Signal Processing September 2011 Newsletter Newsletters -> In this issue Newsletters -> Engaging Families Supporting Students from Cradle to Career Newsletters -> Thank You Spring Retirees Newsletters -> Market direction Download 326.54 Kb. Share with your friends:
|