KR101208821B1 - Method, arrangement and computer program for determining standardized rod types for nuclear reactors - Google Patents

Abstract

A method, apparatus and computer program for determining a standardized set of fuel rod types for use in a reactor core are described. The method may include defining a set of fuel rod type related limits and determining an initial population of fuel rod types to be evaluated for use in the core of the selected number of nuclear reactor plants. Based on the initial population of fuel rod types, a database of selectable fresh fuel bundle designs applicable to one or more cores may be generated. Bundle data associated with at least one subset of the selectable fresh fuel bundle designs may be retrieved from a database, and based on the retrieved bundle data, the target number of fuel rod types may be selected as a standardized fuel rod type set from an initial population. have.

Description

METHOD, ARRANGEMENT AND COMPUTER PROGRAM FOR DETERMINING STANDARDIZED ROD TYPES FOR NUCLEAR REACTORS}

1 illustrates an apparatus for implementing a method according to an exemplary embodiment of the present invention;

2 illustrates an application server of an apparatus implementing a method according to an exemplary embodiment of the present invention;

3 illustrates a relational database having a subordinate database in accordance with an exemplary embodiment of the present invention;

4 is a flow diagram illustrating a method of determining a standardized set of fuel rods in accordance with an exemplary embodiment of the present invention;

5 is a flow diagram illustrating how an initial population of fuel rod type may be determined, in accordance with an exemplary embodiment of the present invention;

6 is a flow diagram illustrating how a selectable fresh fuel bundle design can be generated, in accordance with an exemplary embodiment of the present invention;

7 is a flow chart illustrating in more detail the setting of the fuel rod type variation set of FIG. 6, in accordance with an exemplary embodiment of the present invention;

8 is a flow diagram illustrating an optimization process for determining a desired fuel rod type for any given candidate fresh fuel bundle, in accordance with an exemplary embodiment of the present invention.

9 is a flow chart illustrating in more detail the optimization of the fuel arrangement of FIG. 8, in accordance with an exemplary embodiment of the present invention;

10 is a flow diagram illustrating the simulating of FIG. 6 in more detail, in accordance with an exemplary embodiment of the present invention;

11 is a flow chart illustrating the ranking of FIG. 6 in more detail in accordance with an exemplary embodiment of the present invention.

DESCRIPTION OF THE REFERENCE NUMERALS

200: application server 210: host processor

230: GUI 250: database server

260: encryption server 275: LAN

300: external user 350: internal user

250: related database server 251: limit database

252: Fresh Fuel Bundle Design Database

253: queue database

254: History Fuel Cycle Design Database

255: Simulator Results Database

256: Fuel Rod Type Database

This application is pending and is part of US Patent Application No. 10 / 325,831 filed by David J. Kropaczek et al. On December 23, 2002 entitled “METHOD AND Arrangement for Determining Nuclear Reactor Core Designs” 35 It asserts national priority to him under USC§120. This application was filed on June 30, 2004 by David J. Kropaczek et al. (Not Assigned) in "Method, Arrangement and Computer Program for Generating Database of Fuel Bundle Designs for Nuclear Reactors" (Representative Document No. 8564-000018 / US / CPB) US patent application (unallocated) filed. The entire contents of both of these applications are incorporated herein by reference.

The present invention relates generally to nuclear reactors and, more particularly, to determining standardized fuel rod types applicable to a plurality of different fuel bundles in the core of different nuclear reactors.

The core of a nuclear reactor, such as a Boiling Water Reactor (BWR) or a Pressurized Water Reactor (PWR), is a fuel bundle (BWR) or group of fuel rods (hundreds of individual fuel rods with different characteristics). PWR). Preferably, these bundles (or groups of fuel rods) are arranged such that the interactions between the rods within the fuel bundle and the fuel bundles satisfy all regulatory and reactor design constraints, including government and customer specified constraints. In addition, in (BWR), it should be determined that the control mechanism, for example rod pattern design and core, can optimize the core cycle energy. The core cycle energy is the amount of energy generated by the reactor core before the core needs to be newly supplied to a new fuel element, and this supply is done during shutdown.

In the case of BWRs, for example, the number of potential bundle structures in the core and the number of individual fuel fuel rod types in the bundle can exceed hundreds of squares. From these different possible configurations, only a small percentage of fuel rod types will meet all applicable design constraints for a particular core of nuclear reactor. In addition, only a small percentage of these fuel rod types that meet all applicable design constraints are economical. Conventionally, typical fuel bundles available for BWR cores may include about ten to thirty or more different fuel rod types. This is undesirable in that the larger the number of different fuel rod types, the higher the manufacturing complexity and cost can lead to higher bundle costs for the consumer.

Traditionally, rod patterns, fuel bundles and / or core designs are determined through trial and error. In particular, when designing a particular design based only on the past experience of the engineer or designer, the initial design was verified. Initially validated designs, for example specific fuel bundle designs for the core, were simulated in a virtual core by a computer. If certain design constraints were not met, the structure was varied and other computer simulations were performed. Typically, several weeks of resources were required before proper design could be validated using the process described above.

For example, one conventional process used is an independent passive process in which a designer needs to repeatedly enter specific operating parameters of a nuclear reactor plant into an ASCII text file, which is one input file. The data entered in the input file can be configured for new and exposed batches of fuel, blade notch position of the control blade (if the reactor being evaluated is a boiling water reactor (BWR)), soluble boric acid concentration (e.g., Core flow, core dose (eg, amount fused in core energy cycles measured in mega-watt days per short time), and the like.

The core simulation program, which can be implemented as a software program running on a suitable computer, recognized by the Nuclear Regulatory Commission (NRC), reads the final input file and outputs the simulation results in text or binary files, for example. The designer then evaluates the simulation output to determine if the design criteria have been met, and to demonstrate that no violation of margin to thermal limits has occurred. If the design criteria are not met (ie there is a violation of one or more limits), the designer needs to manually change the input file. Specifically, the designer can manually change one or more operating parameters to restart the core simulation program. This process can be repeated until a satisfactory design is achieved.

This process is time consuming. Necessary ASCII text files are difficult to construct and are often error prone. These file types are fixed and often very long, exceeding 5,000 lines of code. Only one error in the file will cause the simulator to crash or, more undesirably, difficult to detect initially, but worsens over time, causing core cycle energy as it occurs in the working nuclear reactor core. Can be reduced. In addition, it does not provide assistance through a manual iterative process to recommend a more suitable solution to the designer. In the current process, the experience and insight of the responsible designer or engineer is the only way to determine the design solution.

Processes that can effectively design useful fuel bundles (or different reactor designs at different plant sites) across a wide range of nuclear reactors, and also satisfy a number of core constraints or design parameters for each of the different reactors, are believed to have not been developed. It is also believed that there is no existing automated process for determining any given standardized fuel rod type set for making fuel bundles applicable to many different nuclear reactors.

An exemplary embodiment of the present invention describes a method, apparatus and computer program for determining a set of standardized fuel rod types configured for use in one or more cores of one or more nuclear reactor plants. In this example, the method may include defining a set of fuel rod type related limits and determining an initial population of fuel rod types to be evaluated for use in the core of the selected number of nuclear reactor plants based on the limits. Can be. Based on the initial population of fuel rod types, a database of selectable fresh fuel bundle designs applicable to one or more cores may be generated. Bundle data associated with at least one subset of the selectable fresh fuel bundle designs may be retrieved from a database, and based on the retrieved bundle data, a target number of fuel rod types may be selected as a standardized fuel rod type set from an initial population. .

BRIEF DESCRIPTION OF THE DRAWINGS The present invention will become apparent from the following detailed description of exemplary embodiments with reference to the accompanying drawings. In the drawings, like elements are represented by like reference numerals, which are given by way of example only and thus do not limit the exemplary embodiments of the invention.

A method, apparatus and computer program for determining a standardized set of fuel rod types for use in a reactor core are described. The apparatus may include a graphical user interface (GUI) for communicating with a user and for interfacing with computer-based systems and / or processing media (eg, software driven computer programs, processors, applications run by an application server, etc.). have. As such, the user may, for example, install a desired fuel bundle that can be implemented in several reactor cores of different nuclear reactor plants, as part of a new core of the reactor plant and / or at the next scheduled downtime for the reactor plant. To determine any given standardized fuel rod type set for a virtual design, a core design loaded with a selected fresh fuel bundle can be virtually generated and evaluated.

1 illustrates an apparatus for executing a method according to an exemplary embodiment of the present invention. Referring to FIG. 1, device 1000 may include, for example, an application server 200 that may act as a central nexus of an accessible web site. Application server 200 may be implemented as any known application server, such as, for example, the Citrix metaframe presentation server. The application server 200 may be operatively connected to the plurality of calculation servers 400, the encryption server 260, and the memory 250. Memory 250 may be implemented, for example, as an associated database server.

Although the present invention is not limited to this encrypted communication medium, the plurality of external users 300 may communicate with the application server 200 via a suitable encryption medium such as encrypted 128-bit Secure Socket Layer (SSL). Can be. The external user 300 can access the application server 200 from one of a personal computer, a laptop, a personal digital assistant (PDA), or the like, via the Internet, using an appropriate interface such as a web-based internet browser. In addition, the application server 200 is accessible to the internal user 350 via an appropriate local area network connection (LAN) 275, as a result of which the internal user 350 has access via, for example, an intranet. In the following, for brevity, the term 'user' generally refers to both the external user 300, the internal user 300, and other designers accessing the device 1000. For example, a user can access a web site to represent a nuclear reactor plant that can determine the required core design for his nuclear reactor, and / or use the method and structure of the present invention to design a core design or core. It may be a vendor employed at a nuclear reactor plant site to develop a fuel bundle design.

The application server 200 provides a user with a centralized location for accessing the application. In essence, each user application session may run on a server but may only be displayed on a user access device (eg, a PC) to allow a user to interact with the application. However, such deployment means are provided as exemplary embodiments and do not limit a given user to only run an application on their access device. The application is responsible for directing all the calculations and accesses of the data to calculate the objective function values, and also creating the appropriate graphical representation of the various features of the core design that the user may want to review. The graphical information is communicated via 128 bit SSL connection 375 or LAN 275 and displayed on the user's appropriate display device.

2 shows an application server 200 associated with the structure of FIG. 1. Referring to FIG. 2, application server 200 uses bus 205 to connect various components and provide a path to data received from a user. The bus 205 may be implemented with a conventional bus architecture, such as a Peripheral Component Interconnect (PCI) bus that is standard in many computer architectures. Other bus architectures such as VMEBUS, NUBUS, address data bus, RDRAM, double data rate (DDR) bus, etc. can be used to implement bus 205 as well. The user communicates with the application server 200 by communicating information to the application server 200 via an appropriate connection (LAN 275 or network interface 225).

In addition, the application server 200 may also include a host processor 210, which may be configured with conventional microprocessors such as PENTIUM processors currently available. The host processor 210 directs, for example, graphical user interface (GUI) and browser functions, directing security functions, and directing calculations of objective functions for various limits for display and review by the user. a central nexus where all real-time and non-real-time functions of the application server 200, such as calculations) are performed. Thus, the host processor 210 can include a GUI 230 that can be accessed through the use of a browser. The browser is a software device that provides an interface and interacts with the user of the structure 1000. In an example embodiment, the browser associated with the Citrix ICA client (part of the commercially available Citrix metaframe access suite software) may be responsible for the formatting and display of the GUI 230.

Typically, browsers are controlled and commanded by standard hypertext, markup languages (ie, HTML). However, an application that is provided or 'serviced' to the user and allows the user to control decisions about the calculations, displayed data, etc., can be implemented using C #, Java or Visual Fortran or any combination thereof. Other well-known high-level languages can also be integrated into application implementations (eg, C, C ++, etc.). All of these languages can be customized or tailored to the specific details of a given application implementation, and images can be displayed in a browser using well-known JPG, GIF, TIFF and other standardized compression methods, XML, Other non-standardized languages and compression methods, such as ASP.NET, the "home-brew" language, or other existing non-standardized languages and methods, can be used for the GUI 230. The application server 200 may be operatively connected to the encryption server 260 via the network I / F 225. Accordingly, the application server 200 executes all security functions using the encryption server 260, and as a result, establishes a firewall to protect the structure 1000 from external security breaches. In addition, encryption server 260 protects external access to all personal information of registered users.

The application server 200 may also be operatively connected to the plurality of computing servers 400. Calculation server 400 may process user input data, supervise simulation of core design, calculate comparison values described in more detail below, and be displayed via GUI 230 and also provided by application server 200. All the calculations necessary to give possible results can be performed.

Computation server 400 may be implemented, for example, as a WINDOWS 2000 server, but other hardware (eg, Alpha, IA-64) and platforms (eg, Linux, Unix) are possible. More specifically, calculation server 400 configures the objective function to calculate the objective function value, and allows the 3D simulator program to simulate reactor core operation for a particular core design into which the fresh fuel bundle to be evaluated can be loaded. Rating to generate results from the simulation, providing result data through the GUI 230 for access and display by the user, and repeating the optimal routine as described in more detail below (this May be configured to perform a number of complex calculations.

3 illustrates an example database server 250 in accordance with an exemplary embodiment of the present invention. The memory or database server 250 may be an associated database, such as an Oracle related database. Associated database server 250 may include multiple sub-databases that handle all necessary data and results in order to implement the methods of the present invention. For example, related database server 250 may include a storage area that includes sub-databases such as limit database 251, which may include all user input limits for all core designs evaluated for a particular nuclear reactor and / or Or a database that stores design constraints. There may also be a fresh fuel bundle design database 252, which may include a number of different fresh fuel bundle designs previously created, modeled, and stored.

In addition, the relevant database server 250 is a queue database 253 that stores parameters for the core design simulated by the 3D simulator and a reference core design to be selected at the time of generating the reference core design that most closely matches the defined user input limits. A historical core design database 254 that includes a historical reactor core loading pattern design. In addition, the associated database 250 includes a fuel rod type database 256 that can store a number of different fuel rod types and associated fuel rod characteristics, and a number of different bundle metrics for each of the plurality of fuel bundles to be evaluated, for example. It may include a bunch performance metrics database 258 that may store the data.

Simulator results may be stored in the simulator results database 255. Simulator result database 255 (and limit database 251) may be accessed by calculation server 400 to calculate a number of objective function values applicable to a particular core design. These objective function values are ranked for a particular fresh fuel bundle design inserted into the virtual core to be modeled, resulting in determining whether the overall core and / or fresh fuel bundle design satisfies, for example, a given user input limit or constraint. Can be. These objective function values may be stored in the objective function value database 257 in the associated database server 250. The 3D simulator input parameter database 259 may also be included in the relevant database server 250. The database 259 may include the position of the control blades and the reactor operating parameters for all exposure steps. Since the calculation server 400 can be operatively connected and in communication with the associated database server 250, each of the sub-databases shown in FIG. 3 may be accessible to one or more calculation servers 400.

4 is a flow diagram illustrating a method of determining a standardized set of fuel rods, in accordance with an embodiment of the invention. The following method is described and will be described in terms of determining a standardized fuel rod set of BWRs, but this method is standardized for one of, for example, pressurized water reactors, gas cooling furnaces, liquid metal furnaces or heavy water reactors. It may be applicable to determining a fuel rod set. The following description describes the method in terms of operation.

Referring to FIG. 4, for any given nuclear reactor plant, or any given plurality of nuclear reactor plants selected by the user, the user is connected to the database server 250 via the GUI 230 and the host processor 210. By accessing, in particular, a plurality of fuel rod type limit values can be defined by accessing the limit value database 251, which can include a plurality of stored fuel rod type limit values or constraint parameters for each of the nuclear reactor plants being evaluated (S100). . Alternatively, fuel rod type related limits can be entered by the user into the limit database 251. Fuel rod type limits may be associated with fuel rod type manufacturing conditions. For example, manufacturing conditions may include acceptable enriched fusion limits for any given fuel rod type, acceptable flammable absorber fusion limits for any given fuel rod type, and allowable axial zones within any given fuel rod type limit. ), And any given fuel bundle constraint or parameter. These are merely exemplary fuel rod type related limits, and other limits or constraints may be apparent to those skilled in the art.

Based on the defined fuel rod type limit values, an initial population of fuel rod types evaluated in the fuel bundle design may be determined (S200). As will be described further below, the initial population can be determined from a much larger population of fuel rod types, for example, as a function of fuel rod mechanical performance and fuel rod cost. These conditions may represent a filter that develops an initial population.

Once the initial population of fuel rod types is determined, the user may create a selectable database of fresh fuel bundle designs to evaluate the initial population of fuel rod types (S300). As will be described in further detail below, in general, the creation of a database of fresh fuel bundle designs may include a number of sub-processes. For example, a user may create an initial population of candidate fresh fuel bundle designs to be evaluated in a simulated virtual core. This initial population may be generated from a stored history fresh fuel bundle design, which may be stored, for example, in the history fuel cycle design database 254.

To create a modified candidate fresh fuel bundle design, the user can set the fuel rod type variation set to generate any given candidate fresh fuel bundle in the initial population. This fuel rod type variation set can be generated by accessing the fuel rod type database 256, for example, to determine how any given fuel rod type affects a particular bundle performance metric within the fresh fuel bundle to be evaluated. have.

The candidate fresh fuel bundle design to be evaluated can be modified by making one (or multiple fuel rod type variations), and the virtual core loaded in accordance with the modified fresh fuel bundle design may produce a plurality of simulation outputs, or "bundle performance outputs". It can be simulated to produce. Bundle performance outputs may be ranked based, for example, on comparisons to specific user input limits related to bundle and / or core performance. The modified candidate fresh fuel bundle design that satisfies the user input bundle and / or core related limits is stored in the fresh fuel bundle design database 252, thereby generating a database used to determine a standardized set of fuel rod types. .

Once the database is created, the user can retrieve bundle data for at least one subset of the fresh fuel bundle design that satisfies the bundle performance metric for further analysis (S400). Such data may be retrieved from the fresh fuel bundle design database 252.

The retrieved bundle data may be analyzed to select a target number of fuel rod types from an initial population as a standardized fuel rod type set for use in multiple nuclear reactor plants (S500). In this example, this can be generated by creating, from the retrieved bundle data, a histogram of the frequency of fuel rod type occurrences in a subset of the fresh fuel bundle design that was evaluated when generating the database. Based on the frequency histogram, any number of fuel rod types of the initial population can be removed. For example, a fuel rod type having a frequency of occurrence below any frequency threshold is removed from the initial population to provide a fuel rod type of the modified or modified population. The threshold of the frequency of occurrence can be set by the user, and an appropriate graphical display can be accessed by the user through the GUI 230, host processor 210, and associated database 250, which is based on the frequency threshold criteria. Indicates a fuel rod type that satisfies it.

The modified fuel rod type population may be further ranked (or filtered) based on production or manufacturing costs to form each of the modified fuel rod types. Through the GUI 230, the user can also obtain an appropriate graphical display, if desired, that represents the ranking in terms of both manufacturing cost and frequency of occurrence. The user can then further analyze the remaining population by repeating a high cost, low frequency filter to achieve the target number of fuel rod types. This target number of fuel rod types, which may represent a standardized set of fuel rod types, may be stored in an associated database 250, in particular, fuel rod type database 256, for example.

Thus, apparatus 1000 may be configured to determine a standardized set of fuel rod types adapted for use in one or more nuclear reactor plants. Via network I / F 225, GUI 230 may receive any given constraint parameter from the user. Any given constraint parameter may be a set of associated fuel rod types (which may be stored in limit database 251) and / or plant specific design constraints, core performance criteria, operating parameter limits used for reactor operation, core safety Other user input limit values that may be stored in the database 251, such as limit values and margins for these operational and safety limit values.

The host processor 210 in coupling and / or operative communication with the database server 250 and the computation server 400 may be configured to perform the functions described in FIG. 4. This may be done based on a user direct input command via the GUI 230 and / or by selecting the desired optimization criteria, for example repeating the objective function of the optimization routine.

Apparatus 1000 may determine an initial population of fuel rod types to be evaluated, based at least on fuel rod type related limits, and generate a selectable fresh fuel bundle design that includes an initial population of fuel rod types applicable to one or more cores. can do. As noted above, these generated designs may include populating fresh fuel bundle design database 252 of database server 250. For example, under user input to the host processor 210 via the GUI 230, the calculation server 400 is stored in at least a subset of the selectable fresh fuel bundle designs (stored in the fresh fuel bundle design database 25). It may be configured to retrieve relevant bundle data and, based on the retrieved bundle data, may be configured to select a target number of fuel rod types from the initial population as a standardized fuel rod type set.

Of course, the user or designer can, for example, set and select criteria to select the target number of fuel rod types. Thus, several sub-databases of database server 250 may, for example, include one or more constraint parameters (see database 251), an initial population of fuel rod type (database 256), and a selection in which bundle data is retrieved. It may be configured to store a database of possible fresh fuel bundle designs (database 252) and a standardized set of fuel rod types (also in fuel rod type database 256).

Thus, in accordance with an embodiment, a user can design or model a suitable fresh fuel bundle that includes one or more fuel rod types from a set of standardized fuel rod types determined as described above. Thus, a plurality of different fuel bundles can be fabricated using a reduced number of different fuel rod types (or standardized sets of fuel rod types) that provide significantly greater flexibility in design. The desired fuel bundle can then be generated using one or more standardized fuel rod type sets. The bundles produced may be inserted into any given core of the selected nuclear reactor plant, such as during a planned downtime. In other words, in the selected nuclear power plant to be evaluated, the core may be aligned with one or more fuel bundles designed with one or more standardized fuel rod type sets, for example, to extend the energy cycle and / or the core operation and / or safety. Potentially improved operating efficiency for operating at margins near the limit.

When selecting the target number of fuel rod types, the filtering function of removing fuel rod types from the initial population by frequency of occurrence and / or high cost will not provide the user with a desired set of standardized fuel rod types of target. The user can rerun the database generation of S300 using the modified fuel rod type population to fine tune or modify the fuel bundle database of the selectable fresh fuel bundle design. Based on the bundle data stored in the modified fresh fuel bundle database, which includes a re-evaluation of the modified fresh fuel bundle design using the modified fuel rod type population, the rescan and analysis function is based on filtering criteria related to frequency of occurrence and production cost. It will be repeated until the target number of fuel rod types is achieved.

5 is a flow diagram illustrating how an initial population of fuel rod type may be determined in accordance with an embodiment of the invention. Referring to FIG. 5, in each fuel rod type of the initial population, the user may evaluate the fuel rod mechanical performance based on the comparison with the fuel rod limit value retrieved from the limit value database 251 (S210).

For example, a user can evaluate the fuel rod machine performance of any given fuel rod type in terms of one or more fuel rod type related limits, such as whether the fuel rod machine performance is acceptable in one or more axial sections of the fuel rod type being evaluated. . Another comparison is that fuel rod machine performance is acceptable within each axis section of the fuel rod being evaluated and / or whether the rod machine performance is acceptable at any number of acceptable boundaries in a given number of axis segments of any given fuel rod. Concentration and / or whether there is an acceptable flammable absorber concentration. This assessment of fuel rod mechanical performance based on fuel rod type limits may serve as a first filter to reduce the initial population of fuel rod type candidates.

Then, the reduced or modified fuel rod type population may be affected by the fuel rod cost analysis (S220). These fuel rod types that meet or indicate acceptable mechanical performance can be evaluated as to whether they meet the cost threshold for producing or manufacturing fuel rods. This fuel rod cost threshold may be, for example, a value set by the user for any given application or any given nuclear reactor plant being evaluated. The fuel rod cost threshold may act as a second filter of the modified population to determine which fuel rod type acts as part of the initial population of fuel rod types evaluated in one or more candidate fresh fuel bundle designs. The "survival" candidate may then be stored in the fuel rod type database 256 as an initial population of fuel rod types being evaluated, for example, when determining the standardized fuel rod type.

6 is a flow chart illustrating how a database of selectable fresh fuel bundle designs may be generated in accordance with an exemplary embodiment of the present invention. An initial population of candidate fresh fuel bundles may be generated to generate a fresh fuel bundle database that determines the target number of fuel rod types (standardized set) (S310). To generate an initial population, a user can access or enter a number of user input limits associated with core performance parameters or safety criteria for the nuclear power plant being evaluated from the limit database 251. The user input limit value is different from the fuel rod type related limit value described above.

For example, the user input limits may include one or more client input power plant specific design constraints, core performance criteria, operating parameter limits used for reactor operation, core safety limits, and margins for operating parameters and safety limits. The user can enter these limit values into the limit database 251 via the GUI 230 and the host processor 210, or can access them from the limit database 251 (if already stored). Based on the user input limits, the user can navigate past and / or select fresh fuel bundle designs that are most consistent with the user input limits (i.e., designs that provide the required energy characteristics in violation of only a few user input limits). The cycle design database 254 can be accessed. The user can create an appropriate list and initial population for candidate fresh fuel bundle designs from the past fuel cycle design database 254. This serves only as a starting point for developing a fresh fuel database of selectable fresh fuel bundle designs, which can be represented by the database 252.

Once the initial population is created, the user can set the rod type change set to the given candidate fresh fuel bundle design to generate a modified candidate fresh fuel bundle design (S320). As described further below, the rod type change set can be set by evaluating the bundle performance metrics for a given fresh fuel bundle design. In general, for each bundle performance metric, a given fuel rod type may be selected based on its effect on the metric, and other fuel rod changes that extend between the maximum and minimum values or have a range of acceptable bundle performance metrics. Can be determined. Thus, the fuel rod change values can be stored in the bundle matrix database 258 at the relevant database server 250 and can also be used to modify a given fuel bundle design, which can then be simulated in a virtual core and is also an example. For example, the ranking may be given based on the simulation result.

The given candidate fresh fuel bundle to be evaluated may be modified by performing at least one fuel rod change from the rod type change set generated in step S320 (S330). The modified candidate fresh fuel bundle design can be 'loaded' into the virtual core (ie, substantially using the selectable input screen provided by the host processor 210 of the structure 1000) and using appropriate simulation software. By going through the simulated reactor operation to generate a simulation result, also known as bundle performance output (S340).

The simulation may be performed by the calculation server 400, but this simulation may be a 3D simulation process run outside of the structure 1000. The user can use well-known executable software-based 3D simulator programs, for example PANACEA, LOGOS, SIMULATE, POLCA, or any other known simulator software with appropriate simulator drivers defined and coded as known. The calculation server 400 may execute these simulator programs based on the user's input through the GUI 230.

Thus, the user can use the GUI 230 to initiate 3D simulation at any time and can also have a number of different means of initiating the simulation. For example, as is known, the user can select "Run Simulation" from the window drop down menu, or click the "RUN" icon on the application toolbar. The user can also receive graphical updates or status for the simulation. Data related to the simulation may be queued in the queue database 253 in the relational database server 250. Once the simulation is queued, the user may have an audio and / or visual indication of, for example, whether the simulation is complete.

The output from the simulation (ie, the bundle performance output) may be rated based on the user input limit value (S350). The user can display data related to each output compared to whether a user input limit value or constraint parameter has been violated if a given bundle performance output is desired. This allows the user to make a visual comparison of past core designs to determine if any improvements have been made through the virtual cores loaded in accordance with the modified fuel bundle design, for example the defined limit values. It may be defined in terms of not exceeding or satisfying certain energy requirements.

As shown in FIG. 6, the functions S330-S350 can be performed using the optimization process S800. In other words, the processing performance of the example apparatus shown in FIGS. 1 and 2 can be used to continuously modify, simulate, and grade simulations of bundle performance outputs until there is no further improvement in a given fresh fuel bundle design being evaluated. You can implement software optimization routines. If the optimization routine generates a bundle performance output grading (expressed as the corresponding objective function value resulting from the objective function used for optimization), and this does not show improvement from previous iterations, then a modified fresh fuel bundle corresponding to that output The design may be stored to generate a fresh fuel database (S360).

Using optimization in the generation of fresh fuel bundle database is just one exemplary mechanism. For example, repetitive iterations may be performed using the processing power of the example structure 1000 based on a user's manual input command via the GUI 230. For any event, the modified fresh fuel bundle design that satisfies the user input limit (or the required energy requirement, e.g., if it is one of the limits) meets the fresh fuel bundle design database 252. Can be stored to populate.

For each given fresh fuel bundle design, functions S330-S360 may be repeated until all rod type changes from the set are evaluated for a given candidate fresh fuel bundle design (S370). In addition, each candidate fresh fuel bundle design from the initial population may be evaluated according to functions S320-S360 to realize the fresh fuel bundle database 252.

7 is a flow chart illustrating in more detail the setting of the rod type change set of FIG. 6 in accordance with an exemplary embodiment of the present invention. 7 shows a more detailed description of the function S320 for setting the fuel rod change set to modify one or more given fresh fuel bundle designs of the initial population.

Referring to FIG. 7, the user may determine a bundle performance matrix applicable to a given fresh fuel bundle design evaluated by accessing the bundle performance metrics from the bundle performance metrics database 258 (S322). For example, a user can select and view the required bundle performance metrics on an appropriate graphical display by selecting the required bundle performance metrics from the database 258 via the GUI 230.

Each bundle performance metric can be evaluated when building a fuel rod change set to be performed for a given candidate fresh fuel bundle design. For example, a given fuel rod type may be selected from fuel rod type database 256 (S323). This selection can be made based on the impact of the rod type on a given bundle performance matrix being evaluated. Table 1 illustrates fuel rod parameters that can be used to define rod types, and Table 2 shows the bundle performance metrics and, for example, the fuel rod parameters that can have the greatest impact on each given bundle performance metric.

Referring to Tables 1 and 2, a given fuel rod type may be selected based on how the fuel rod parameters of Table 1 affect the given performance metrics of Table 2. In relation to Table 1, fuel rod variables (A-C) represent regional changes that can cause local changes of a given fuel bundle of the core. Fuel rod variables D and E represent global changes or fuel changes that may affect the core as a whole.

For example, reactivity burnout is a measure of neutron propagation factor (k _∞ ) for a bundle of fuel over a historical record of exposure (eg three cycles). As shown in Table 2, fuel rod parameters that most affect the reactive burnout (global impact on the core) include total enriched uranium (D) and total flammable poison (E) for a given fuel rod type.

For the Cool Down Margin Bundle Performance Matrix, which reflects the effect of the bundle on core reaction in the reactor shutdown with all control blades inserted in the core except the control blades that are completely backed off, adjacent to the bundle of interest, Fuel rod parameters that most affect cooling shutdown may include the number and length of shaft sections A, enriched uranium in a given section B, and combustible poisons in a given section C. These fuel rod parameters can have local influence on a given bundle in the core.

Local exposure accumulation metrics reflect the exposure measurements of each rod from the beginning of the rod life to the end of the rod life and can be most affected by the rod variables (A-C). Rod exposure is accumulated based on the local power in each fuel rod integrated over time.

Radial power profiles in which the bundle's power profile has a pin-by-pin shape are due to the critical power ratio (the critical heat flux (CHF) divided by the power present with a margin for CHF). Power in which the thin film is formed). Fuel rod variables D and E may have the greatest impact on the radial profile.

For the axial power profile (z-axis profile, which affects how long the fuel cycle of the reactor can run), the fuel rod parameters (A-C) may have the most impact on the axial power profile bundle performance metrics. Local kW / ft bundle performance metrics reflect local power in pellets, for example fuel temperatures in pellets or cladding of rods. As shown in Table 2, fuel rod parameters (A-C) have the greatest impact on this bundle performance matrix. Thus, depending on the particular bundle performance metric being evaluated, the user can select a given fuel rod type that determines how one or more fuel rod variables affect one or more given bundle performance metrics.

Based on the selected rod type, the user may determine one or more fuel rod changes to be between the maximum and minimum acceptable values for each bundle performance metric, or to have a range of bundle performance metrics (S324). Table 3 shows the fuel rod types that can be achieved over a given bundle performance matrix range.

Referring to Table 3, for example, if the user wants fuel rod fluctuations that can increase the margin upon cooling down, the user may, for example, reduce the toxin content in the upper axis section of the bundle and Fuel rod type variations can be made that can increase uranium enrichment in the upper axis section. Thus, for any given bundle performance metric, a list of fuel rod fluctuations performed for any given candidate fresh fuel bundle design is stored in the associated database 250 for storing in the bundle performance metric database 258. A plurality of fuel rod variations may be selected (S325). When the desired bundle performance metric is evaluated by the user (output of S326 is YES), the fuel rod variation set can be completed.

8 is a flow diagram illustrating an optimization process for determining a preferred fuel rod type for any given candidate fresh fuel bundle in accordance with an embodiment of the present invention. As described above, the functions of S330-S350 of FIG. 6 may be performed using an optimization routine. Here, referring to FIG. 8 as part of the optimization routine S800, the user can select the dominant fuel rod type for replacement in the candidate fresh fuel bundle from the set fuel rod type set (S810). The dominant fuel rod type, for example, has a dominant effect on margins for one or more user input limits, core performance criteria, operation and / or limits, core safety limits and operating parameters and core safety limits associated with a particular plant design limit. It can be a fuel rod giving. This may be selected manually by the user, or may be determined, for example, by suitable criteria for selecting the dominant fuel rod type from the fuel rod type set.

The dominant fuel rod type may be exchanged with an existing fuel rod type in the fresh fuel bundle design to generate a modified candidate fresh fuel bundle design (S820). The replacement of a particular fuel rod in the modified candidate fresh fuel bundle may be determined using optimization (S840) until the bundle performance metric is satisfied (S840). Based on the optimization of fuel rod replacement, any given fresh fuel bundle design candidate to be evaluated that satisfies all bundle performance metrics may be stored, for example, to populate the fresh fuel bundle design database 252. . Otherwise (output of S840 is "NO"), another fuel rod type variation may be selected from the set for correcting the fresh fuel bundle (S850) and the functions S820-S840 may be repeated.

9 is a flow chart illustrating in more detail the optimization of the fuel change of FIG. 8 in accordance with a exemplary embodiment of the invention. 9 illustrates fuel rod replacement optimization S830 processing in more detail.

Referring to FIG. 9, one or more limited fuel rods in the candidate fresh fuel bundle design to be evaluated may be identified (S831). The unlimited fuel rod (s) can then be selected from a list of stored unlimited fuel rods (which can be stored in the relevant database 250 prior to optimization or entered by the user), and the location of the restricted fuel rods within the fresh fuel bundle design. Can be exchanged for the fuel rod (s) in (S832).

A modified fresh fuel bundle design with replaced unlimited fuel rods can be 'loaded' into a suitable fuel cycle core design or "virtual core". The user can select a fuel cycle design from the stored fuel cycle design database 254 that most closely matches the user input limit of the user. In other words, the user selects the overall core design of the virtual core that most satisfies the majority of the user input limit and / or the allowable margin for the user input limit.

When the fuel cycle design is selected, the user may identify the fresh fuel bundle position in the selected design for the virtual core of the improvement target based on the input bundle metric (S834). For example, the user can indicate the top cross section of the simulated virtual core and the targeted bundle location within the core for insertion of one or more fresh fuel bundles from the modified fresh fuel bundle design. The fuel bundle at the target position may then be exchanged (S835) and replaced with the modified fresh fuel bundle design.

The virtual core loaded according to the modified fresh fuel bundle design can then be simulated using a suitable simulation software based simulation program (S836) to generate simulation results (bundle performance output). In order to determine whether the bundle performance metric for the candidate fresh fuel bundle design is satisfied or within an acceptable margin (see S840 in FIG. 8), the objective function is calculated (S837) corresponding to the bundle performance output. Can be used. Thus, the objective function value can be used to rank the bundle performance output of any given fresh fuel bundle design against the bundle performance metric.

10 is a flow diagram illustrating the simulation of FIG. 6 in more detail in accordance with an embodiment of the present invention. FIG. 6 describes, for example, the simulation in S340 of FIG. 6 and the simulation in S836 of FIG. 9.

When the user starts the simulation, several automatic steps follow. Initially, all the limitations to the core design problem are translated into the 3D instruction set (eg computer work) of the 3D reactor core simulator. This allows the user to select some type of simulator, such as the simulator described above. The choice of a particular simulator may depend on plant criteria (eg, limit values) entered by the user. Computer tasks are prepared for queuing in the queue database 253 of each associated database server 250 (S344). By storing data for a particular simulation, potential simulation iterations can begin from the last iteration or previous iterations. By storing and retrieving this data, future simulation iterations for the core design take only a few minutes or seconds to execute.

At the same time, a program running on each of the available calculation servers 400 scans every few seconds to find available jobs to operate (S346). When the job is ready to run, one or more calculation servers 400 obtain data from queue database 253 and run the appropriate 3D simulator. As mentioned above, one or more status messages may be displayed to the user. Immediately upon completion of the simulation, all results of interest may be stored in one or more sub-databases in the relevant database server 250 (eg, simulation results database 255) (S348). Thus, the associated database server 250 can be accessed to calculate the objective function for the test core design.

11 is a flowchart illustrating the ranking step of FIG. 6 in more detail. When ranking bundle performance outputs, an objective function can be calculated to compare how closely the simulation core design satisfies a user input limit (also referred to as a "constrain") with any given candidate fresh fuel bundle design. (See, eg, S837 in FIG. 9). The objective function is a mathematical equation that contains constraints or limits and quantifies the fixed value of the core design for the limits. For example, based on the simulation results and the calculated objective function values, a user who can be, for example, a core designer, engineer, or plant supervisor, may find that a particular core design meets the user limit conditions (ie, Satisfactory).

The objective function may be stored in the associated database server 250 for access by the computation server 400. Objective function calculations that provide objective function values may also be stored in the associated database server 250, such as in the lower objective function value database 257. Referring to FIG. 11, the input to the objective function calculation may include a user input limit value from the limit value database 251 and a simulation result (bundle performance output) from the simulator result database 255. Accordingly, one or more calculation servers 400 may access this data from the associated database server 250 (S352).

Although the method and apparatus of the present invention contemplates a number of objective function types that can be used, this embodiment is a user input limit value for a particular constraint parameter (eg, design constraints of nuclear plant parameters), denoted "CONS". And an objective function with three components of the multiplier for this constraint parameter, denoted "MULT", and the simulation results from the 3D simulator for that particular constraint parameter, denoted "RESULT". . The predetermined set of MULTs can be determined empirically in the configuration of a large-scale nuclear power plant (such as in the form of a set of BWR plants, a set of PWR plants, etc.). This multiplier can be set to a value that allows the reactor energy, reactivity limits, and temperature limits to be determined in appropriate units.

Thus, an entire set of multipliers experimentally determined in accordance with the preferred embodiment can be used, which can be applied to N different core designs. However, the GUI 230 may also be used to manually change the multiplier, since the user's preferences may require certain constraints to be "dismissed" if they have a multiplier greater than the multiplier indicated by the preset default. .

The objective function value can be calculated for each individual constraint parameter and for all constraint parameters as a whole, where all constraint parameters indicate which entity is being obtained at a particular core. Individual constraints of the objective function can be calculated as shown in equation (1),

(1)

(One)

Here, "par" may be any user input limit. It will be appreciated that these parameters are not the only parameters that can be possible candidates for the value, but are commonly used to determine the appropriate reactor core configuration. The overall objective function is the sum of all suppression parameters, or

(2)

(2)

It can also be

Referring to Equation 1, if RESULT is less than CONS (eg, not violating constraints), the deviation will be reset to zero and the objective function will be zero. Thus, an objective function value of zero means that certain constraints (ie, user input restrictions) are not violated by simulation results (ie, bundles of performance outputs). Positive values of the objective function indicate violations and require modification. In addition, the simulation results may be provided in the form of spatial coordinates (i, j, k) and time coordinates (exposure steps) (eg, a specific time of the core energy cycle). Thus, the user can know at what time coordinates (eg, exposure time) the problem appeared. Thus, there may be a modification to the core that targets the identified exposure step.

In addition, an objective function value may be calculated as a function of each exposure step and summed over the entire design problem (S354). The objective function value calculated for each constraint and the objective function value calculated for each exposure step can be further tested by averaging each objective function value and providing a distribution ratio of a given constraint over the overall objective function value (S356). ). Each result and value of the objective function calculation may be stored, for example, in the lower objective function value database 257 in the associated database server 250 (S358).

The objective function value can be used for manual measurement of core development. For example, objective function calculations can be graphically viewed by the user to determine parameters that violate constraints. In addition, any change in the objective function values during successive iterations of the core design provides the user with a criterion to evaluate whether these proposed designs have been improved or degraded.

Increasing the objective function value over several iterations means that you are creating a core design in which the user's change is far from the desired solution, while fewer consecutive iterations of the objective function value (eg, the objective function value is zero from a positive value) Decreases) means an iteration of the core design. The objective function values, constraints and simulation results during successive iterations may be stored in various sub-databases within the associated database server 250. Thus, the design can recover quickly from past iterations, demonstrating that subsequent modifications do not help.

Although the implementation of the preferred method is primarily described with reference to the hardware configuration of FIGS. 1 and 2 above, this preferred method may be implemented in software such as a computer program. For example, a program according to an embodiment of the present invention may be a computer program product that allows a computer to measure a standardized set of fuel rod types used in one or more cores of a plurality of nuclear power plants.

The computer program product may include computer readable media having computer program logic or code portions that, when implemented, cause the processor of the apparatus to measure a standardized set of fuel rod types used in one or more cores of a plurality of nuclear power plants. .

The computer readable storage medium may be an embedded medium mounted in a computer body or a removable medium mounted detachably from a computer body. Examples of embedded media include, but are not limited to, rewritable nonvolatile memory such as RAM, ROM, flash memory, and hard disk. Examples of removable media include optical storage media such as CD-ROMs and DVDs, magnetic optical storage media such as MOs, magnetic storage media such as floppy disks (registered trademark), rewritable cassettes and removable hard disks, and memory cards. And media having built-in ROM, such as a ROM cassette with a possible nonvolatile memory, and the like.

These programs may be provided in the form of computer data signals included in externally supplied transmission signals and / or carrier waves. Computer data signals comprising one or more instructions or functions of the preferred method may be carried on a carrier for transmission and / or reception by an entity performing the function or instructions of the exemplary method. For example, the functions or instructions of the exemplary method may be implemented by processing one or more code segments of the carrier in a computer controlling one or more of the components of the preferred apparatus of FIG. 1, where the instructions or functions are in accordance with the preferred method described herein. Thus, it can be performed to determine a standardized fuel rod type set.

In addition, such a program can be easily stored and distributed when recorded in a computer-readable storage medium. Since it can be easily read by a computer, the storage medium can determine the standardized fuel rod type set according to the preferred method described herein.

Preferred embodiments of the present invention provide several advantages. Preferred methods make it possible to measure the number and positional variations of standard fuel rod types of genuine fuel bundles, which satisfy various core constraints and / or fuel bundle performance criteria of many different reactors.

Unlike current core designs, which can use any number of different types of fuel rods regardless of cost or performance, to improve the design of fuel bundles or fuel rod patterns for a particular core of a particular nuclear power plant, a specific standardized fuel rod type The set can be measured. Thus, a small number of different fuel rod types can be used to produce potentially infinitely different fuel bundles. This increases the efficiency and flexibility of the core design, reduces manufacturing costs and potentially allows for improved stability against the thermal limits of the core.

In addition, the preferred embodiment can significantly reduce the time it takes to manufacture a set of preferred standard fuel rod types for use in other reactors using a computing environment. This method fully follows the user's input constraints or design limitations for a particular reactor core design, and uses fewer fuel rod types to rapidly change the core design and simulate the varied design compared to conventional manual iterations. It can provide greater operational flexibility. Also, as explained for the manual iteration process, the error when trying to generate the simulator input file no longer occurs.

While preferred embodiments of the invention have been described, it will be apparent that this may be varied in a variety of ways. For example, the functional blocks of FIGS. 1-11 that illustrate preferred apparatus and / or methods may be implemented in hardware and / or software. Hardware / software implementations include a combination of manufacturing processes and articles. The article of manufacture may further comprise a storage medium and an executable computer program.

The executable computer program may include instructions for performing an operation of the described function. The computer executable program may be provided as part of an externally supplied radio signal. Such modifications do not depart from the spirit and scope of the preferred embodiments of the invention, and all such modifications apparent to those skilled in the art are intended to be included within the scope of the following claims.

Claims (10)

A method of determining a set of standardized fuel rod types configured for use in one or more cores of one or more nuclear reactor plants, the method comprising: Defining a set of fuel rod type related limits; Based on the limits, determining an initial population of fuel rod types to be evaluated for use in the core of the selected number of nuclear reactor plants; Creating a database of selectable fresh fuel bundle designs that include one or more of the initial population of fuel rod types and are applicable to the one or more cores; Retrieving bundle data associated with at least one subset of the selectable fresh fuel bundle designs from the database; Based on the retrieved bundle data, selecting a target number of fuel rod types from the initial population that meets the set of fuel rod type related constraints as a standard fuel rod type set; How to determine standardized fuel rod type set. The method of claim 1, Defining the set of fuel rod type related limits includes: an acceptable concentrated fusion limit for a given fuel rod, an acceptable flammable absorber fusion limit for a given fuel rod, an allowable axial zone within the given fuel rod limit, A user inputting a fuel rod type manufacturing condition comprising one or more of the acceptable fuel rod types for a given fuel bundle limit value, and storing the limit value set; How to determine standardized fuel rod type set. The method of claim 1, Determining the initial population of the fuel rod type, For a given candidate fuel rod type, Evaluating whether the fuel rod mechanical performance of the given candidate is acceptable with respect to the fuel rod type related set of limits; For candidates determined to have acceptable machine performance, Comparing the candidate cost with a desired cost threshold, Populating the initial population by storing performance information and fuel rod type characteristics for each candidate that is less than the cost threshold, The initial population with relevant performance information and fuel rod type characteristics is accessed to generate a database of the selectable fresh fuel bundle designs. How to determine standardized fuel rod type set. The method of claim 1, Generating the database of selectable fresh fuel bundle designs may be performed using one or more optimization processes. How to determine standardized fuel rod type set. The method of claim 1, Generating the database of selectable fresh fuel bundle designs, Generating an initial population of candidate fresh fuel bundle designs to be evaluated in the virtual core from the stored historical fresh fuel bundle designs; Establishing a set of fuel rod type changes made to a given candidate in said initial population to produce a modified candidate fresh fuel bundle design; Modifying a given candidate fresh fuel bundle by making at least one fuel rod type change from the set; Simulating reactor operation of the loaded virtual core using the modified bundle design to produce a plurality of simulation results including bundle performance outputs representing the modified bundle design; Ranking the bundle performance output based on a plurality of user input limit values; Storing the modified candidate fresh fuel bundle design if the bundle performance output meets or is within an acceptable margin for the user input limit to generate the database. How to determine standardized fuel rod type set. 6. The method of claim 5, For each bundle design of the initial population, Further comprising repeating the modification, simulation, ranking, and storage steps to populate the database using additional candidate fresh fuel bundle designs, The modifying step, simulation step, ranking step and storage step are performed for some or all of the fresh fuel bundle design of the initial population. How to determine standardized fuel rod type set. 6. The method of claim 5, A given candidate fresh fuel bundle design represents a design for one of a single fresh fuel bundle, a plurality of fresh fuel bundles, and a plurality of groups of fresh fuel bundles to be evaluated in a given core. How to determine standardized fuel rod type set. 6. The method of claim 5, The user input limit includes one or more of plant specific design constraints entered by the client, core performance criteria, operating parameter limits used for reactor operation, core safety limits, and margins for these operations and safety limits. How to determine standardized fuel rod type set. The method of claim 1, Selecting the target number of fuel rod types, Generating, from the retrieved bundle data, a frequency histogram of fuel rod type occurrences in the subset of fresh fuel bundle designs; Based on the histogram, removing fuel rod types of an initial population having a frequency of occurrence less than a given threshold; Ranking the fuel rod type population modified based on the manufacturing cost; Removing the high cost, low frequency fuel rod types from the modified population until the target number of fuel rod types is obtained. How to determine standardized fuel rod type set. An apparatus for determining a set of standardized fuel rod types configured for use in one or more cores of one or more nuclear reactor plants, An interface for receiving constraint parameters including fuel rod type related limits, plant specific design constraints, core performance criteria, operating parameter limits used for reactor operation, core safety limits and margins for these operating and safety limits; Based on at least the fuel rod type-related limits, determine an initial population of fuel rod types to be evaluated for use in the core of the selected number of nuclear reactor plants, and determine one or more of the initial population of fuel rod types applicable to the one or more cores. Generate a selectable fresh fuel bundle design comprising: retrieve bundle data associated with at least one subset of the selectable fresh fuel bundle design, and based on the retrieved bundle data, a target number of fuel rod types from the initial population A processor device configured to select a as the standardized fuel rod type set; Memory for storing one or more of the constraint parameters, an initial population of fuel rod types, a database of selectable fresh fuel bundle designs from which the bundle data is retrieved, and a set of standardized fuel rod types Standardized fuel rod type set determination device.

Images