MXPA04002997A - Method and arrangement for determining fresh fuel loading patterns for nuclear reactors. - Google Patents

Abstract

In the method, a set of limits applicable to a core may be defined, and a test fresh fuel loading pattern design, to be used for loading the core, may be determined based on the limits. Reactor operation on at least a subset of the core may be simulated to produce a plurality of simulated results. The simulated results may be compared against the limits, and data from the comparison may indicate whether any of the limits were violated by the core during the simulation. A designer or engineer may use the data to modify the test fresh fuel loading pattern, creating one or more derivative fresh fuel loading pattern design(s) for simulation and eventual perfection as an acceptable fresh fuel loading pattern design for the core.

Description

METHOD AND PROVISION TO DETERMINE FRESH FUEL LOAD PATTERNS FOR REACTORS NUCLEARS BACKGROUND OF THE INVENTION FIELD OF THE INVENTION This invention relates to the determination of designs of / pattern of loading fresh fuel for a core of a nuclear reactor.

RELATED TECHNIQUE A nuclear reactor, such as a boiling water reactor (BWR) or pressurized water reactor (PWR), for example, can operate for approximately 1 to 2 years with a single charge of core fuel. After the end of a given period (energy cycle), approximately ¼ to Vz of the least reactive fuel (the oldest or the most burned) can be discarded from the reactor. The operation of the cycle may depend on the placement of the fuel assemblies (fresh fuel, fuel once burned, fuel burned twice, etc.). Due to the presence of poisons that can burn in the nucleus, such as gadolinium, for example, the characteristics of the assemblies of fresh fuel, fuel once burned and fuel burned twice, can be different. The fresh fuel assembly is typically less reactive at the start of the cycle (BOC), as compared to a fuel bundle once burned, due to the presence of gadolinium. At the end of the cycle (EOC), since much or all of the poison has been burned, fresh assemblies are typically more reactive than fuel once burned. Although the shape of an exposure-dependent reactivity curve of the twice-burned fuel may be similar to that of the fuel once burned, the reactivity of the twice-burned fuel is smaller in magnitude. When combining assemblies of fresh fuel, fuel once burned and fuel burned twice, however, a substantially uniform reactivity can be obtained through the nucleus, through the energy cycle. In addition to the reactivity considerations, the placement of fuel assemblies ("fuel bundles") can impact the thermal limits, energy configuration and economy of the fuel cycle. If the fuel bundles, which are too high in reactivity, are placed adjacent to each other, an inadequate margin may be present at the thresholds of reactivity with the thermal limits. The length of the cycle can also be increased by placing a larger number of reactive beams towards the center of the core, instead of placing these reactive fuel bundles at the periphery of the core. Therefore, a core load pattern can define many of the most important considerations for a nuclear fuel cycle. As a given fuel loading pattern, it may be beneficial to include a plurality of fresh fuel bundles, for example, a fresh fuel charge pattern that forms part of the core charge pattern. By developing multiple fresh fuel charge pattern designs, improvements in a certain power cycle metric are possible, such as the extended cycle length, plant energy overfeeds, increased safety margins, etc. Traditionally, core load design determinations have been made on a trial and error basis. For example, a separate manual kernel load pattern design procedure is used, which requires a designer to repeatedly enter specific operational parameters of the reactor plant into an ASCll text file, which is an input file. The data entered in the input file may include knife notch positions of the control blades (if the reactor evaluated is a boiling water reactor (BWR)), core flow, core exposure, which may be the quantity of burned in a core energy cycle, measured in megawatts (or gigawatt days for short time (MWD / st, GWD / st), etc. A core simulation program authorized by the Nuclear Regulatory Commission (NRC) reads the resulting input file and produces the results of the simulation to a next text or binary file. Then, a designer can evaluate the simulation result to determine if the design criteria are met, and to verify that margins violations to the thermal limits have not occurred. A failure to satisfy the design criteria (ie, v.iolation of one or more limits) typically requires a manual modification to the input file. Specifically, the designer could manually change one or more operation parameters, and redo the core simulation program. This procedure was repeated until a satisfactory kernel charge pattern design was achieved. This procedure can be extremely time-consuming, since the required ASCII text files are laborious to build, and are usually prone to errors. Files typically in an extremely long ASCII format, sometimes exceeding 1000 or lines of code. A single error in the file can occur in a simulator crash, or worse, it can result in a moderately errant result that may be difficult to detect initially, but which could waste time. and iterations to perhaps reduce the core cycle energy, if an actual nuclear reactor core will be charged in accordance with the wrong core charge pattern. In addition, no help is provided through the iterative manual procedure in order to guide a designer to a more favorable core load pattern design solution. In the current procedure, the experience and intuition of the responsible designer or engineer are the only means to determine a core load pattern design solution.

COMPENDIUM OF THE INVENTION The illustrative embodiments of the present invention are directed to a method and arrangement for determining fresh fuel charge pattern designs, wherein a group of limits applicable to a core can be defined, and a fresh fuel charge pattern design of Test, which will be used to load the kernel, can be determined based on the limits. The operation of the reactor in at least one subgroup of the core can be simulated to produce a plurality of simulated results. The simulated results can be compared against the limits, and the comparison data can indicate if any of the limits were violated by the core during the simulation. A designer or engineer can use the data to modify the fresh fuel load pattern by testing, creating one or more fresh fuel charge pattern designs for the simulation and final perfection as an acceptable fresh fuel charge pattern design for the core.

BRIEF DESCRIPTION OF THE DRAWINGS Illustrative embodiments of the present invention will be more readily understood from the detailed description provided below and the accompanying drawings, in which similar elements are presented with similar reference numerals, which are provided only by way of illustration and thus they do not limit the illustrative embodiments of the present invention, and wherein: Figure 1 illustrates an arrangement for implementing the method in accordance with an illustrative embodiment of the invention; Figure 2 illustrates an application server of the arrangement for implementing the method according to an illustrative embodiment of the invention; Figure 3 illustrates a database of relationship with subordinate databases according to an illustrative embodiment of the invention; Figure 4 is a flow chart describing the method according to an illustrative embodiment of the invention; Figure 5 is a flowchart illustrating a step for the determination of fresh test fuel charge pattern design according to an illustrative embodiment of the invention; Figure 6 is a flow chart illustrating a simulation step according to an illustrative embodiment of the invention; Figure 7 is a flow chart illustrating the comparison step of Figure 4 in greater detail in accordance with an illustrative embodiment of the invention; Figures 8A and 8B are flow charts illustrating the modification of a core load pattern design and an iterative modification procedure according to an illustrative embodiment of the invention; Figures 9-15 are screens of an illustrative computer-based application to further describe various features of the illustrative embodiments of the present invention; and Figure 16 is a flow chart describing an optimization routine according to an illustrative embodiment of the invention.

DETAILED DESCRIPTION Illustrative embodiments of the present invention are directed to a method and arrangement for determining a fresh fuel charge pattern design for a nuclear reactor. The arrangement may include a graphical user interface (GUI) and a processing means (e.g., software-powered program, processor, application server, etc.) to allow a user to create virtually fresh fuel charge pattern designs for a nucleus. The data regarding the simulation of the charged core according to the fresh fuel loading pattern can be reviewed in a suitable presentation device through the user. The arrangement can provide a feedback to the user, based on how a core loaded with a proposed fresh fuel charge pattern design solution satisfies user input limits or restrictions for the operation of the simulated nuclear reactor. The user, through the GUI, you can enter limits, which can be plant-specific restriction data, for example, that can be applicable to a core of a selected reactor plant, which will be loaded for simulation, for example , a "virtual core", based on a fresh test fuel charge pattern design. For example, restriction data or limits can be defined as a group of limiting or target core operating and operating values for a specific core reactor or power cycle plant. Through the GUI, a user can determine a fresh fuel load pattern design of initial test, can initiate a reactor simulation (eg, a three-dimensional simulation using simulation codes allowed by the NRC) of the loaded core based on The design of fresh fuel loading pattern test, and see results from the simulation. In accordance with the illustrative embodiments, an objective function can be used to compare how closely a simulated core loaded with the fresh fuel charge pattern design satisfies the limits or restrictions. An objective function is a mathematical equation that incorporates constraints or limits and quantifies adherence to the limits of the fresh fuel charge pattern design. For example, based on the results of simulation and calculated objection function values, the user, who may be a core designer, engineer or plant supervisor, and anyone who has access to the arrangement, for example, may be able to determine if a particular design meets the requirements (limits) of the user design (ie, satisfies a maximum cycle power requirement). Through the GUI, the user can then modify the fresh fuel loading pattern design to create a fresh derivative fuel charge pattern design, and issue commands to repeat the simulation to determine if there is any improvement in performance in the design of fresh derivative fuel charge pattern. In addition, the user, through the GUI, can iterate certain functions, such as simulation, comparison of results with limits, modify the design if the limits are violated, etc., to generate N designs of fresh fuel charge pattern , until a simulated core or an N design satisfies all limits, or satisfies all limits within a margin that is acceptable to the user. The illustrative embodiments of the present invention can use a computing environment to effect a 10-fold reduction in the amount of time necessary to create a desirable fresh fuel charge pattern design for a nuclear reactor, as compared to the manual iterative procedure real. The resulting fresh fuel charge pattern design can adhere almost perfectly and / or exactly to the design limits or user input restrictions, since a fuel charge pattern design is not completed until an objective function value for a particular design solution it is equal to zero. As compared to manual iterative procedures of the prior art, an operational flexible majority may be possible to change the fresh fuel charge pattern designs quickly and simulate the altered designs. No more errors are made when trying to generate a simulator input file, as described with respect to the manual iterative procedure. Figure 1 illustrates an arrangement for implementing the method according to an illustrative embodiment of the invention. Referring to Figure 1, provision 1000 may include an application server 200, which may serve as a central link to an accessible website, for example. The application server 200 can be modalized as any known application server, such as a WINDOWS 2000 application server, for example, the application server 200 can be operatively connected to a plurality of servers. calculation 400, a cryptographic server 260 and a memory 250. The memory 250 can be modeled as a relationship database server, for example.

A plurality of external users 300 may communicate with an application server 200 through a suitable encrypted medium such as an encrypted 128-bit security socket layer connection (SSL), 375, although the illustrative embodiments of the present invention They are not limited to this encrypted means of communication. A user 300 can connect to the application server 200 via the Internet, for example, from any of a personal, portable, and personal digital assistant (PDA) computer, etc., using a suitable interface such as an Internet browser based on web. In addition, the application server 200 may be accessible to internal users 350 through a suitable local area network connection (LAN, 275), such that the internal users 350, from any one of a person, portable computer, Personal digital assistant (PDA), etc., which is part of an Intranet (ie private network), can have access through the Intranet, for example. The application server 200 can be responsible for online security, to direct all calculations and to enter the data in order to calculate objective function values and for the creation of suitable graphical representations of various aspects of a pattern design. Fresh fuel load that a user can review. The graphic information can be communicated through the 128-bit SSL connection 375 or the LAN 275, which will be presented in a suitable presentation device of the 300/350 users. Hereinafter, the term "user" refers to both an internal user 300 and an external user 350. For example, the user can be any of a representative of a nuclear reactor plant who has access to the website to determine a Fresh fuel charge pattern design for your nuclear reactor, a seller rented by a reactor plant site to develop fresh fuel charge pattern designs using the illustrative embodiments of the present invention, or any other person having access to the arrangement 1000 or another system that implements the method according to the illustrative embodiments of the present invention. Figure 2 illustrates an application server 200 associated with the arrangement of Figure 1. Referring to Figure 2, the application server 200 can use a bus 205 to connect various components and provide a path for the data received from the users. The busbar 205 can be implemented with conventional busbar architectures such as a peripheral component interconnect collector bus (PCI) that is standard in many computer architectures. Alternative busbar architectures such as VMEBUS, NUBUS, address data bus, ARM busbar, DDR busbar (double data rate), etc., can, of course, be used to implement the busbar 205. Users they can communicate the information to the application server 200 through an appropriate connection (LAN 275 or network inrush 225). The application server 200 may also include a host processor 210, which may be constructed with one or more conventional microprocessors, such as the PENTIUM processors currently available. The host processor 210 may represent a central link from which real-time and non-real-time functions are performed in the application server 200, such as graphical user interface (GUI) and browser functions, directing security functions, directing calculations such as the calculation of objective function values to compare simulator results with various limits, etc., for the presentation and revision by the user. Accordingly, host processor 210 may include a GUI 230, which may be modalized in the software as a browser. Browsers are software devices that present an interface to, and interact with the users of the 1000 arrangement. The browser is responsible for formatting and presenting user interface components (eg, hypertext, advantage, etc.) and images. Browsers are typically controlled and commanded by the standard hypertext markup language (HTML). In accordance with the illustrative embodiments of the present invention, interactive graphical functions and decisions can be made in the flow control of a browser such as GUI 230 with a virtual private network (VPN). The use of a VPN network may allow the calculation of aspects related to the graphics in the application server 200 only, while the resulting images are presented to the users 300. In addition, or as an alternative, any decision in the flow control of the GUI 230 that requires a more detailed interaction by the user can be implemented using JavaScript. Both languages can be adapted for the specific details of a given implementation of the application server 200, and the images can be presented in the navigated using well-known standardized understanding schemes such as JPG, GIF, TIFF and others. Other languages and non-standardized compression schemes can be used for GUI 230, such as XML, "home" languages or other languages and known non-standard schemes. The host processor 210 can be operatively connected to a cryptographic server 260. Accordingly, the application server 200 can implement security functions through the cryptographic server 260, in order to establish a firewall to protect the 1000 arrangement of security branches. external. In addition, the cryptographic server 260 can secure all registered personal user information. The application server 200 can also be operatively connected to a plurality of computing servers 400. The computing servers 400 can perform all the calculations required to process the data entered by the user, direct the simulation of a loaded kernel according to a Fresh fuel charge pattern design, calculate objective function values for comparison as will be described in detail below, and to provide results that can be presented through GUI 230, under the direction of application server 200. The servers 400 can be modeled as WINDOWS 2000 servers, for example. More particularly, the computing servers 400 can be configured to perform a multitude of complex computations that can include, but are not limited to, configuring the objective function and calculating objective function values, executing a three-dimensional simulator program to simulate the core operation of the reactor in a core loaded with a particular fuel load pattern design of a particular test and to generate results from the simulation, providing result data for access and presentation by a user through the GUI 230 and iterating a routine of optimization as described below. Alternatively, the illustrative modalities may be implemented by a computer program product such as a bundled software program. The software program can be stored in the memory 250 and includes a logic that allows the host processor 210 to simply operate the method according to the illustrative embodiments of the invention, direct the calculation servers 400, the calculation servers as well. having access to memory 250. Figure 3 illustrates an illustrative database server 250 according to one embodiment of the invention. The memory or database server 250 may be a relationship database such as an Oracle 8i Alpha ES 40 database relationship server. The relationship database server 250 may contain a number of database bases. subordinate data that handle all the necessary data and results, in order to implement the illustrative embodiments of the present invention. For example, the relationship database server 250 may include storage areas containing subordinate database such as the limits database 251, which is a database that stores limits and / or design restrictions introduced. by the user for testing fresh fuel charge pattern designs that are evaluated for a particular nuclear reactor. In addition, the relational database server 250 may include a queued database 253, which stores queue data and parameters for a particular fresh fuel charge pattern design of a core to be simulated in the three-dimensional simulator. The results of the simulator can be stored in a simulator result database 255. The simulator results database 255 (and the limits database 252) can be accessed by the calculation servers 400 in order to calculate a number of objective function values that may be applicable to a particular fuel test fuel design pattern. These objective function values can be stored in a database of objective function values 257 within the database server of ratio 250. A database of 259 input parameters of the three-dimensional simulator can also be included within the server of database of ratio 250. The database 259 can include fuel bundle positions and reactor operating parameters for all exposure steps. Since the calculation servers 400 can be operatively connected to, and can communicate with, the relational database server 250, each of the subordinate databases described in Figure 3 can be accessible to one or more computing servers 400. .

Figure 4 is a flow diagram illustrating the method according to an illustrative embodiment of the invention. The method can be described in terms of a fresh fuel charge pattern design for an illustrative boiling water reactor, it being understood that the illustrative embodiments may be applicable to PWRs, gas cooled reactors and heavy water reactors. Referring to Figure 4, a reactor plant is selected for evaluation (step S5) and limits (step S10) are defined which are to be used for a simulation of a core of the selected plant to be loaded in accordance with a fresh fuel loading test pattern. Based on the limits, a fresh fuel load pattern of initial test can be determined, and the "virtual" core can be loaded according to the initial fuel test pattern design of the given initial test fuel (step S20). The operation of the reactor can be simulated (step S30) throughout the core, or in a subgroup of the core, which can be a subgroup of fuel bundles in a reactor core, for example, in order to produce a plurality of simulated results. The simulated results can be compared with the limits (step S40), and based on the comparison, data can be provided illustrating whether any limits have been violated (step S50). The data can provide the user with indications that locations in a simulated core were the biggest violators or largest contributors to a boundary violation. Each of these steps will now be described in detail. Figures 9-15 are screens describing an illustrative computer-based application for additionally presenting other features or aspects of the method and arrangement of the present invention. These Figures may occasionally be referred to in the following description. Initially, a reactor plant is selected (step S5) so that an initial test fresh fuel charge pattern design can be selected. The reactor plant can be selected from a stored list, such as is stored in an accessible database, such as the relationship database 250, for example. The reactor to be evaluated can be any of a BWR, PWR, gas cooled reactor, or heavy water reactor, for example. The data of previously evaluated plants can be stored, and the plant listed under an appropriate accessible folder can be accessed through an appropriate input device (mouse, keyboard, plasma touch screen, voice activated command, etc.) and GUI 230. A group of limits applicable to the core can be defined (step S10). These limits may be related to the key aspects of the design of the particular reactor core to be evaluated and the design restrictions of that reactor. The limits may be applicable to variables that are to be introduced to perform a simulation of a loaded core according to a fresh test fuel load pattern design, for example, and may include restrictions applicable only to the results of the simulation. . For example, the input limits may be related to specific reactor plant constraints entered by the customer and kernel performance criteria. The limits applicable to the simulation results may be related to one or more of the operational parameter limits, and / or design restrictions used for reactor operation, core safety limits, margins for these operational and safety limits, and the other specific reactor plant restrictions introduced by the customer. However, such limits or restrictions are merely illustrative, like other limits or restrictions, so that limits based on a supercharger core design that exceeds actual operational limits may be foreseeable. Figure 9 illustrates specific plant restrictions entered by the user or client, which can be configured as limits in input variables to the simulation and limits in the simulation results. Referring to Figure 9, a plurality of plant-specific constraints entered by the customer are listed as generally indicated by the arrow 905. For restriction, it is possible to assign a design value limit, as indicated by column 910. Figure 5 is a flow chart describing a selection of fresh test fuel charge pattern and a core charge according to an illustrative embodiment of the invention. Figure 5 is provided to explain step S20 of determination, in greater detail. The selection of a fresh test fuel charge pattern, and the loading of a "virtual" core for the selected plant based on the pattern, can be performed in order to simulate the operation of the modeled core reactor based on the design proposed. Initially, a check is made (step S21) to establish if previous iterations have occurred in a fresh test fuel charge pattern. If there is a first iteration, for example, no pre-test fresh fuel loading pattern has been analyzed, information on past cycles or similar plants can be used to provide a basis for a fresh fuel loading test pattern initial (step S22). For example, an initial test fresh fuel charge pattern can be selected from a core load pattern design used for a similar core in a previous simulation. Selected based on a core load pattern design of a reactor that is similar to the reactor to be evaluated, and / or of a real core load pattern design used in a previous core energy cycle in the plant of reactor that is being evaluated, for example. If past iterations have been performed (the output from step S21 is "NO"), the total energy content of the core, using an established core load pattern that conforms to the input limits, can be evaluated, and define a difference from a desired / required energy content (step S23). This can also be done using a fresh fuel loading pattern of step S22, also representing the introduced limits, if this is the first iteration. This "delta" energy is the difference in energy required for the next future cycle as compared to the most recent end of cycle (EOC). For additional iterations, the delta can be reduced as the difference between the actual energy and the desired energy is reduced. In addition, delta negative energies imply that the resulting energy is greater than the desired energy, and this is desirable. The difference in energy must be supplied through fresh fuel assemblies, which could also be part of the fresh fuel loading pattern to load the reactor core, which will be loaded into a next scheduled production, for example. There are typical rules that can help to select the number of additional beams needed (or the number of beams that must be removed) in order to obtain the desired target energy. For example, in a boiling water reactor with 764 beams, four (4) beams are commonly believed to be valued at approximately 100 MWD / st of the cycle duration. Therefore, if the resulting energy is 100 MWD / st greater than the desired energy, four fresh beams must be removed. Similarly, if the resulting energy of more than 100 MWD / st is shorter than the desired energy, four additional cool beams must be added.

The user must select (step S24) the number of fresh fuel bundles needed to develop the energy difference. This can be done by entering a "palette" of fresh fuel patterns previously modeled and stored, or the user can create specific fresh fuel bundles from a beam type database, for example. After the number of fresh beams is determined, which will be used in the test core load pattern, the symmetry of the core load must be identified (step S25). Some plants may require quadrant charge symmetry or medium-core load symmetry, for example. The GUI 230 can be used to access a plant configuration web page, which can allow the user to select a "model size", for example, a quarter of a kernel, half a kernel, or a complete kernel, for evaluation in a subsequent simulation. In addition, a user can select a core symmetry option (for example, octant, quadrant, without symmetry) for the selected model size, by clicking on an appropriate drop-down menu, and the like. By selecting "octane symmetry" the user can model the reactor assuming that the eight (8) distractors (where one octant is a group of fuel bundles, for example) are similar to the modeled octant. Consequently, the time of the simulator in general can be increased by a factor of eight. Similarly, by selecting "quadrant symmetry", the user can model the reactor, assuming that each of the four quadrants (4) is similar to the modeled quadrant. In this way, the simulator time can generally be increased by a factor of four. If the asymmetries in the properties of the beam avoid the octant or quadrant symmetry, the user can also specify that there is no symmetry. The "virtual" core can then be loaded (step S26) according to the initial test fresh fuel charge pattern, representing symmetries and limits. The virtual core loaded according to the fresh fuel loading test pattern is ready to be simulated. With the limits already defined, the fuel test pattern design of the initial test fresh determined and the core loaded in accordance therewith, a simulation can be initiated (step S30). The simulation can be executed by calculation servers 400. However, the simulation can be a three-dimensional simulation procedure that runs externally to the arrangement 1000. The user can employ well-known executable three-dimensional simulators such as PANACEA, LOGOS, SIMULATE, POLCA, or any other known simulator software, where appropriate simulator controllers have been identified and encoded, as is known. The calculation servers 400 can execute these simulator programs based on the entry by the user through the GUI 230. In this way, the user can initiate a three-dimensional simulation at any time using the GUI 230, and can have a number and different means to start a simulation. For example, the user can select a "run simulation" from a window scroll menu, or you can click on an icon that says "RUN" in a web page toolbar, as it is known. In addition, the user can receive graphical updates or simulation states. The queue data related to the simulation can be queued in queue database 253 within the relational database server 250. Once the simulation is queued, the user can have an audio indication and / or visual of when the simulation is completed. Once the user starts the simulation, many automation steps follow. Figure 6 is a flow chart illustrating step S30 of simulation in greater detail. Initially, the definitions for the core load pattern design problem can be converted to a group of three-dimensional instructions (for example, a computer job) for the three-dimensional reactor core simulator (step S31). This allows the user to have the selection of several types of simulators, such as the simulators described above. The selection of a particular simulator may depend on the plant criteria entered by the user (for example, the limits). The computer work can be read from the queue in the queue database 253 of the relational database server 250 (step S33). Storing the data for a particular simulation can enable any potential simulation iteration to start from the last iteration or from the previous iteration. By storing and retrieving this data, future simulation iterations for a fresh fuel charge pattern design can take only minutes or seconds to complete. Concurrently, a program running on each of the available calculation servers 400 scans every few seconds to look for jobs available for running (step S37). If a job is ready to run, one or more of the calculation servers 400 obtains the data from the queue database 253 and runs the appropriate three-dimensional simulator. As described above, one or more status messages may be presented to the user. After the simulation is finished, the results of the simulator can be stored in one or more subordinate databases within the relational database server 250 (for example, simulation result database 255). Accordingly, the relationship database server 250 can be accessed by the user, through the GUI 230 and the guest processor 210, for example, in order to calculate objective function values for the load pattern design. of fresh fuel test. Figure 7 is a flow chart illustrating the comparison step of Figure 4 in greater detail. The objective function can be stored in the relational database server 250 to be accessed by the calculation servers 400. The objective function calculations, which provide objective function values, can also be stored in the server. relationship database 250, such as in a subordinate objective function value database 257. Referring to Figure 7, the inputs to the objective function calculation may include the limits of the limit database 257 and the simulator results from the simulator results database 255. Accordingly, one or more calculation servers 400 can access this data from the relational database server 250 (step S41). Although the illustrative embodiments of the present invention encompass any number of objection function formats that may be used, a modality may include an objective function having three components: (a) the limit for a particular restriction parameter (e.g. design for the reactor plant parameter), represented as "CONS"; the simulation result of the three-dimensional simulator for the particular restriction parameter, represented as "RESULT", and a multiplier for the restriction parameter, represented by "MULT". A group of predefined MULTs can be empirically determined from a large collection of boiling water reactor plant configurations, for example. These multipliers can be set at values that allow the reactor energy, reactivity limits and thermal limits to be determined in an appropriate order. Accordingly, the method of the present invention utilizes a generic group of empirically determined multipliers, which can be applied to more than 30 different core designs. However, GUI 230 allows manual change of multipliers, which is important since the user's preference may wish for certain restrictions to be "penalized" with multipliers greater than the multipliers identified by the preset default values. An objective function value can be calculated for each individual restriction parameter and for all restriction parameters as a whole, where all the restriction parameters represent the entity to be evaluated in a fresh fuel loading pattern of particular test. An individual constraint component of the objective function can be calculated as described in equation (1): OBJPAR = MULTpar * (RESULTADOpar - CONSPAR); (1) where "pair" can be any of the restrictions introduced by the client listed in Figure 9. It should be understood that these parameters are not only parameters that may be possible candidates for evaluation, but are parameters that are commonly used in order to to determine a suitable core configuration for a nuclear reactor. The total objective function can be a sum of all the restriction parameters, or: OBJTOT = SUM (Pair = 1, 31). { OBJPar} (2) Referring to Equation 1, if RESULT is less than CONS (for example, there is no violation of a constraint), the difference is reset to 0 and the objective function will be 0. Therefore, the objective function values of 0 they indicate that a particular restriction has not been violated. The positive values of the objective function represent violations that may require correction. In addition, the simulation results can be provided in the form of special coordinates (i, j, k) and time coordinates (exposure step) (for example, particular time in a core energy cycle). Therefore, the user can see in which time coordinate (for example, exposure step) the problem is located. In this way, the fresh fuel charge pattern can be modified only in the identified exposure step. In addition, the objective function values can be calculated as a function of each exposure step, and totaled for the entire design problem of fresh fuel loading test pattern (step S43). The objective function values calculated for each restriction, and the objective function values for exposure steps, can also be examined by normalizing each objective function value to provide a contribution percentage of a given restriction of a total objective function value (step S45). Each result or value of an objective function calculation is stored in a subordinate objective function value database 257 within the 250 relationship database server. The objective function values can be used in the ml determination of the development of the function. pattern of loading fresh fuel. For example, the values of the objective function calculations can be seen graphically by the user in order to determine the parameters that violate limits. In addition, any change in objective function values with respect to successful iterations for fresh fuel charge pattern designs provides the user with a gauge to assess both the improvement and the damage in their proposed fresh fuel charge pattern design.

Increases in an objective function value with respect to several iterations may indicate that user changes are creating a fresh fuel charge pattern design that is moving from a desired solution, while successive iterations of values of fewer functions Objective (for example, the objective function value that is reduced from a positive value to 0) may indicate improvements in the iterative fresh fuel charge pattern design. The objective function values, limits, and simulation results with respect to successive iterations can be stored in several subordinate databases within the database server of relation 250. Therefore, designs of past iterations can be quickly retrieved, if the latest modifications prove to be of no help. After completing the objective function calculations, the user can be provided with data related to the objective function calculations, which can include limits that have been violated during the simulation of a loaded core according to the load pattern design of Fresh test fuel. Figure 10 illustrates illustrative graphical data that a user can review. Referring to Figure 10, a list of restriction parameters that can represent the input limits is presented, and the values of each objective function value calculation in a basis by restriction. Figure 10 illustrates limits that have been violated with a check in a box, as indicated by the verified box 1005, for example. In addition, for each limit violation, its contribution and contribution percentage (%), based on the calculations and normalization routines described with respect to Figure 7, can be presented. Accordingly, based on this data, the user can be provided with recommendations of what modifications need to be made for the design of fresh test fuel loading pattern for a subsequent iteration. Although individual fresh fuel charge pattern modifications may alternatively be left to the wishes of the user, procedural recommendations may be provided in the form of a drop-down menu, for example. These recommendations can be divided into three categories: beneficial energy movements, harmful energy movements, and excessive conversion margin (from the thermal limit) to additional energy. A preferred technique can be to direct problems using beneficial energy movements instead of damaging energy movements although the illustrative modalities are not limited to this preferred technique, since the damaging movements of energy and / or the excessive margin of conversion can be used for modify a particular test fuel charge pattern. Even if the fresh fuel charge pattern design satisfies all limits (specific plant restrictions entered by the customer, design limits, term limits, etc.) the user can verify that any excess margin for a particular limit is converted to additional energy.

Therefore, the following logical determinations can illustrate the above procedure recommendations: Charitable Energy Movements If the Critical Energy Ratio (CPR) margin is too low towards the core perimeter, move more reactive (less exposed) fuel towards the center of the core. If there is an MFLPD problem (for example, a term margin restriction) in EOC, move more reactive fuel towards the location of the problem. If there is interruption margin problem (SDM) in the perimeter of the core in BOC, place less reactive fuel towards the perimeter of the core.

Harmful Energy Movements If the Minimum Critical Energy Ratio (MCPR) margin is too low in EOC, move less reactive fuel (more exposed) to problem locations. If the KW / ft margin (MAPLHGR) is too low in EOC, move less reactive fuel to problem locations.

Excessive Conversion to Additional Energy Margin If there is an extra margin of MCPR in the center of the core in EOC, move more reactive fresh fuel from the core perimeter location to the center of the core.

Based on the location, and on the time exposure of boundary violations, as indicated by the objective function, a user may choose to follow one or more of the above recommendations to direct and fix restriction violations. The data that results from the cases of objective function can be interpreted in an adequate presentation device. For example, these data may be presented as a list of restrictions with denotated violators, as described with respect to Figure 10. However, the user may enter a number of different "result" presentation screens that may be configurable as bi-dimensional or three-dimensional views, for example. The following Table 1 presents some of the illustrative views available to the user.

TABLE 1 Graphic Views Available to the User Objective function results list Maximum core value graph versus exposure Nodal maximum value graph versus exposure Maximum core value location plot versus exposure Terminal value graph versus exposure Maximum beam value plot versus exposure Graph of rotation of three-dimensional view Report performance in relation to the previous iteration Reporting scales for several designers Presentation of server status Presentation of queue status Presentation of system recommendations Figures 11-12B illustrate graphic views available to the user according to the invention. Referring to Figure 11, a user can display an appropriate display menu from a "view" icon in a toolbar in order to present views of certain restrictions or parameters. As illustrated in Figure 11, a user has selected a Maximum Fractional Limit Energy Density restriction parameter (MFLPD). There are a number of different graphic views available to the user, as indicated by the display menu 1110. The user simply selects the desired view and can then access a page as illustrated in Figures 12A or 12B. Figure 12A illustrates two different two-dimensional graphs of particular constraints, as seen in 1205 and 1210. For example, the user can determine when the violations of the Maximum Average Plane Generation Rate (MAPLHGR) occur (in a maximum core graph against exposure 1205, and a graph of axial values of MFLPD against exposure 1210) for a particular exposure in the core cycle. The limits of these restrictions are shown through lines 1220 and 1225, with the violations generally shown at 1230 and 1235 in Figure 12A. Figure 12B illustrates another view, in this case a two-dimensional view of a complete cross section of a core, in order to see where the major violation contributors for MAPLHGR against exposure are located. As seen in 1240 and 1250, the boxes enclosed represent the fuel bundles that are the largest rape contributors to MAPLHGR in the core (for example, 1240 and 1250 signaling beams that violate MAPLHGR). This provides the user with an indication of locations in the fresh test fuel charge pattern design that may need modification. Figures 8A and 8B are flowcharts describing steps of modification and iteration processing according to an illustrative embodiment of the invention. Referring to Figure 8A, interpretation of the data in step S60, the user may be inclined to initiate a modification subroutine (step S70). In any practice, the initial test fresh fuel charge pattern design will not be an acceptable design, and a modification subroutine will be required. In an illustrative embodiment, the user can direct each interaction of this modification subroutine, with the help of the graphical user interface 230. In another illustrative embodiment, the modification subroutine can be performed within the subunits of an optimization algorithm that Automatically iterates the simulation, objective function calculation and evaluation of the results or values of the objective function calculations for a number of iterations of bar pattern design. The user determines, based on the data presented, if some limits are violated (step S71). If no limit has been violated, the user determines whether any identifiers indicate that maximum energy characteristics are obtained from the fresh fuel charge pattern design. For example, these identifiers may include an indication of a good use of term margin (such as margins in MFLCPR and MAPLHGR) by moving the fuel to the center of the core to maximize the generation of plutonium for the extension of the cycle. It can be seen that the energy requirements are satisfied when the minimum EOC value for the cycle design is obtained (search for its own value) or the desired cycle duration is determined at a set eigenvalue of EOC. If there is an indication that a maximum energy has been obtained from the fresh test fuel charge pattern design (the output of step S72 is YES), an acceptable fresh fuel charge pattern design is determined, the user may have access to a results and data report regarding the accepted fresh fuel charge pattern design (step S73). If limits are violated (the output of step S72 is YES) or the limits are not violated but there is an indication that a maximum energy of the fresh fuel charge pattern design has not been obtained (output step S72 is NO) , then the user determines whether any indicator identifies characteristics of the selection modification of the fresh fuel bundle (step S74). The characteristics that indicate the need to modify the selected fresh fuel bundles can include a shortage of energy, a shortage of margin with acceptable energy, a loss of reactivity due to scheduled production date changes, for example. In addition, if several iterations of fresh fuel charge pattern design changes have been attempted and there has not been a real improvement for the objective function, this is an additional indication that an alternative to load pattern design should be explored. of fresh fuel. Accordingly, if the output of step S74 is YES, the user can create a fresh or modified derivative fresh fuel charge pattern by re-selecting fresh fuel bundles, rounding numbers of fuel bundles as required for core symmetry and charging the core according to the revised or derivative fresh test fuel charge pattern (step S75). Step S75 generally corresponds to steps S24-S26 in Figure 5. If there is no characteristic indicating the need to modify the number of fresh fuel bundles (the output of step S74 is NO), the user can modify the fresh test fuel charge pattern design (step S76) to create a derivative pattern. By making a modification to the fresh test fuel charge pattern based on the procedure recommendations described above, the user can alter the core load through the GUI 230. For example, and by using a suitable input device (mouse , keyboard, touch screen, voice command, etc.) and the GUI 230, a designer can identify the core symmetry option for any fuel bundle in the core design that the user wants to move, you can select these fuel bundles "target", and you can select the "target" fuel bundles in the current core design for replacement by the target fuel bundles. The target and target fuel bundles are then "redistributed with fuel" according to the required symmetry (mirror, rotational, etc.). This procedure can be repeated for any redistribution of fuel bundle fuel that is required to reload a new modified test fresh fuel charge pattern in the desired form. Figure 13 is a screen illustrating modification step S76 in greater detail in accordance with an illustrative embodiment of the invention. Figure 13 illustrates the functionality available to the user to make sudden design modifications to a fresh fuel charge pattern design. A user may select a page 1305 of a fuel distribution and may select a toolbar 1310 to "redistribute fuel to the beam" 1310 in order to present a display 1315 of a portion of a loaded core based on a pattern design of load of fresh fuel. In Figure 13, a fuel bundle designated at 1320 is changed from one type of fuel bundle (type IAT 11) to another (type IAT 12). An exposed fuel bundle can be swept with a fresh fuel bundle selected a fresh fuel bundle in the core design, the fuel bundle exposed, and the "CHANGE" button 1330 selected. The core portion shown in the display 1315 it can be color coded to show the various exposures (GWD / st) of each of the fuel bundles. A key encoded with corresponding color can be presented as indicated in 1327, for example. The selection of items in Figure 13 can be effected through the use of a suitable input device, such as a mouse, keyboard, touch screen, voice activated command, etc. These fresh fuel charge pattern design modifications can be saved in a relationship database 250, such as in the three-dimensional simulator input parameter database 259, for example. Referring again to Figure 8A, without considering that if the test fuel fresh charge pattern was modified as described in steps S75 or S76, steps S30-S50 can be repeated to determine whether the pattern design of Derivative bar satisfies all limits (step S77). This can provide an iterative procedure.

Figure 8B illustrates an iterative procedure according to an illustrative embodiment of the invention. For each fresh fuel charge pattern design derived from step S70 that has been simulated, the user determines whether any data that is related to the comparison between the simulated results and the limits (for example, calculated objective function values) follows indicating that there are limit violations (step S160). If not, (output from step S160 is NO), the user has developed an acceptable tanker fuel charge pattern design that can be used in a particular reactor, and can access graphics results in relation to the load pattern design of acceptable fresh fuel (step S173). If an iteration continues to indicate that the limits have been violated (the output of step S160 is YES), then the modification subroutine in step S70 may be iteratively repeated until all limits are satisfied / maximum energy is obtained, or until all limits are satisfied / obtain maximum energy within a range that is acceptable, as determined by the user (step S170). The iterative procedure can be beneficial in that it allows the user to fine tune a fresh fuel charge pattern design, and perhaps extract even more energy out. of an acceptable fresh fuel loading pattern design than previously possible when done with the manual, conventional iterative procedure. In addition, the incorporation of the relationship database server 250 and a number of calculation servers 400 perform calculations. The iterative procedure as described in Figure 8B can be performed in an extremely short period of time, as compared to a number of weeks using the manual iterative procedure of the prior art of changing one parameter at a time, and then running a simulation of reactor core. Up to this point, illustrative embodiments of the present invention have been described in terms of a user or designer who interprets data through the GUI 230 and modifies a fresh fuel load pattern design iteratively, by hand, using the energy of auxiliary computing of a host processor 210 and / or calculation servers 400 in order to obtain a desired design. However, the aforementioned steps of Figures 8a and 8B can also be effected through an optimization procedure. The optimization procedure can iterate the steps in Figures 8A and 8B with respect to N different fresh fuel charge pattern designs, in an effort to consistently improve a desired fresh fuel charge pattern design to satisfy all limits and user restrictions, to use in a nuclear reactor core. Figure 14 illustrates a screen for initiating said procedure. For example, after selecting the plant and generating a fresh test fuel charge pattern design, the user can present an optimization configuration screen 1405. The user can select 1440 optimization parameters to optimize the flow load, optimize Bar patterns, optimize core flow, optimize sequence intervals and optimize beam selection, for example. Optimizing beam selection means making an optimal determination of the fuel bundle types within the reference core design. As a result of optimization, each fresh location can contain any number of fuel bundle types (for example, lAT types as shown in Figure 13, for example). These types can be selected to maximize energy while satisfying some restrictions, as described above. Optimization of fuel load selection means making an optimal determination of the burnt fuel once and twice. Optimizing bar patterns means making an optimal determination at the position of the control blade (or control bar if it is a PWR). The bar positions affect the local energy as well as the nuclear reaction speed. Optimizing core flow means making an optimal determination of the flow rate of reactor coolant through the reactor as a function of time during the operation cycle. The flow velocity affects the overall reactor energy as well as the nuclear reaction rate. Optimizing sequence intervals means making an optimal determination of the duration of a given sequence (ie, grouping of control rods) that is used to control the reactor during the operation cycle. The sequence intervals affect the local energy as well as the nuclear reaction rate. When using a suitable input device (for ple, keyboard, mouse, touch screen, etc.), the user can select, through GUI 230, one or more of the optimization parameters by clicking on the associated selection box 1442 with an optimization parameter 1440. When selected, a check appears in the selection box 1442 of the selected optimization parameter. By pressing in the selection box 1442, the selection of the optimization parameter is again removed. For ple, to perform an optimization for a fresh fuel charge pattern design, a user could select to optimize beam selection box 1442, as illustrated in Figure 14. Memory 250 (relationship database server) ) can also store restriction parameters associated with the optimization problem. These can be stored in the limits database 251, for ple. The restriction parameters are parameters of the optimization problem that a restriction or restrictions must satisfy, when a restriction may be analogous to the limits described above. Figure 15 illustrates a one-page screen of optimization constraints that lists optimization constraints associated with an optimization problem of a boiling water reactor core design. As shown, each optimization constraint 1550 has a design value 1552 associated therewith. Each optimization constraint must fall below a specified design value. The user has the ability to select optimization parameters to consider the configuration of the objective function. The user selects an optimization constraint by clicking on the selection box 1554 associated with an optimization constraint 1550. When selected, a selection appears on the selection each 1454 of the selected optimization constraint 1550. Pressing the 1554 selection box again removes the selection of the optimization constraint. Each optimization parameter may have a predetermined credit term and a credit load associated therewith stored in the relationship database server 250. Similarly, each optimization constraint has a predetermined penalty term and an associated penalty charge. with it, which can be stored the database server of relation 250, such as in the database of limits 251 and / or database of values of objective function 257. As seen in Figure 15, the Penalty term incorporates the design value (limit or restriction), and the user can change (ie, configure) this value as desired. In addition, the embodiment of Figure 15 allows the user to set an importance 1556 for each optimization constraint 1550. In the 1558 importance field for an optimization constraint, the user may have drop-down menu options of minute, low, nominal, high and extreme. Each option is correlated with an empirically predetermined penalty charge so that the greater the importance, the greater the predetermined penalty charge. In this way, the user selects from a group of charges of predetermined penalty. Once the above selections have been completed, a calculation server 400 retrieves the above selections from the database server of relationship 250 and configures the objective function according to the generic definition discussed above and the selections made during the selection procedure . The resulting configured objective function is equal to the sum of the credit components associated with the selected optimization parameters plus the sum of penalty components associated with the selected optimization constraints. further, this modality provides that the user selects a method to handle the credit and penalty charges. For example, the user is provided with the possible static, death penalty, dynamic and adaptive methodologies for penalty charges; it is provided with the possible static, dynamic and adaptive methodologies for credit charges; and the relative adaptive methodology for both the penalty and credit charges. The well-known static methodology keeps the charges initially at their fixed values. The well-known death methodology establishes each penalty charge to infinity. The well-known dynamic methodology adjusts the initial load value during the course of using the objective function in an optimization search based on a mathematical expression that determines the amount and / or frequency of the load change. The well-known adaptive methodology is also applied during the course of an optimization search. In this method, the penalty charge values are adjusted periodically for each restriction parameter that violates the design value. The relative adaptive methodology is described in the co-pending and commonly assigned U.S. patent application No. 10 / 246,718, entitled Method and Apparatus for Adaptive Determination of Load Factors within the Context of an Objective Function, filed on September 19, 2002.

Optimization Using the Objective Function Figure 16 illustrates a flow chart of an optimization procedure employing the objective function according to an illustrative embodiment of the present invention. This optimization procedure is described in U.S. Patent Application No. 10 / 246,716 entitled Method and Apparatus for Evaluating a Proposed Solution to a Restriction Problem, by the inventors of the objective application, filed on September 19, 2002. For For purposes of explanation only, the optimization procedure of Figure 16 will be described as being implemented by the architecture illustrated in Figure 1. As shown in step S 1610, the objective function is configured as discussed above in the preceding section, then the optimization procedure begins. Step S1612, the calculation processors 400 recover the entry of systems from the relationship database 250, or generate one or more groups of values for input parameters (i.e., system inputs) of the optimization problem based on the optimization algorithm in use. For example these input parameters may be related to the determination of fresh and exposed fuel bundles within the reactor, and / or a fresh fuel charge pattern design with the initial fresh fuel charge pattern for a next energy cycle of a particular nuclear reactor plant. However, the optimization is not limited to using these parameters, as other input parameters could be the selection of groups of bars (sequences) and placement of control bar positions within the groups as a function of time during the cycle , the core flow as a function of time during a cycle, the inlet pressure of reactor coolant, etc. Each input parameter that sets the values is a candidate solution for the optimization problem. The core simulator, as described above, runs a simulated operation and generates a simulation result for each input parameter that sets values. The simulation result includes values (that is, system outputs) for the optimization parameters and optimization constraints. These values, or a subgroup of these values, are values of the variables in the mathematical expressions of the objective function. Then, in step S1614, a calculation processor 400 can use the objective function and the system outputs to generate an objective function value for each candidate function. In step S1616, the calculation processor 400 determines whether the optimization procedure has converged to a solution using the objective function values generated in step S1614. If no convergence is achieved, then in step S1618, the input parameter determinations are modified, the optimization iteration count is incremented and the processing returns to step S1612. Generation, convergence determination and modification operations of steps S1612, S1616, and S 1618 are performed in accordance with any well-known optimization algorithm such as genetic algorithms, simulated fixation, and taboo search. When the optimization is used to determine an acceptable fresh fuel load pattern design, the optimization can be run until the convergence is obtained (eg, acceptable results in steps S73 / S173 of Figures 8A and 8B). The technical effect of the illustrative embodiments of the present invention may be a computer-based arrangement that provides a way to efficiently develop a fresh fuel charge pattern design for a nuclear reactor, as well as a computer-based method to provide to internal and external users the ability to quickly develop, simulate, modify and refine a fresh fuel charge pattern design for existing fuel within, and the fresh fuel assemblies that are going to be loaded inside it, a nucleus of a nuclear reactor in the next programmed stage. The illustrative embodiments of the present invention have thus been described, and it will be obvious that they can be varied in many ways. Such variations are not considered as a departure from the spirit and scope of the illustrative embodiments of the present invention, and such modifications will be obvious to one skilled in the art and are intended to be included within the scope of the following claims.

Claims (10)

1. - A method for developing a nuclear charge pattern design for a nuclear reactor, comprising: defining a group of limits applicable to a nuclear reactor core; determine a test core load pattern design that will be used to load the core based on limits; simulating the operation of the reactor in at least one subgroup of the core to produce a plurality of simulated results; compare the simulated results against the limits; and provide data indicative of boundaries that were violated by the core loaded with the test core loading pattern during the simulation.

2. The method according to claim 1, wherein the step of defining further includes: defining input limits applicable to variables that are to be introduced to perform the simulation step, the input limits related to specific plant restrictions introduced by the client and core performance criteria; and define result limits applicable to the simulated results, the result limits in relation to at least one of the operational parameter limits used for reactor operation, core security limits, margins for those operations and security limits, and specific plant restrictions entered by the client, where the entry limits and the result limits are evaluated in the comparison step.

3. The method according to claim 1, wherein the step of comparing further comprises: configuring an objective function to evaluate the simulated results; and generate objective function values for each simulated result using the objective function; and evaluate the objective function values based on the defined group of limits to determine which of the simulated results violates a limit.

4. - The method according to claim 1, wherein the step of further providing comprises providing data related to an acceptable core load pattern design, if the comparing step indicates that all the limits have been satisfied, or satisfied. within an acceptable range, and provide procedural recommendations for modifying the test core load pattern design, based on the violation of one or more of the limits.

5. The method according to claim 1, further comprising: modifying the test fuel charge pattern design to create a derivative core charge pattern design; and iteratively repeating the steps of modifying, simulating, comparing and providing to develop N iterations of the derivative core load pattern design and, for the selected N iterations, where the step of repeating iteratively is performed until the comparison in an iteration particular indicates that all limits have been satisfied, or satisfied within an acceptable margin; store information regarding core load pattern design, limits, simulated results and comparison data in each iteration; and produce data related to an acceptable core load pattern design for the nuclear reactor.

6. An arrangement (1000) for developing a fuel charge pattern design for a nuclear reactor, comprising: an interface (230) that receives a group of limits that are applied to a core of the nuclear reactor; a memory (250) for storing said group of limits; a processor (210, 400) that determines a test core load pattern design that will be used for core loading based on the limits; a simulator for running a simulation reactor operation in at least one subgroup of the core, loaded in accordance with the test core pattern design, to produce a plurality of simulated results, the processor (210, 400) comparing the results simulated against the limits, and the interface (230) providing data indicating limits that were violated by the core during the simulation.

7. - The arrangement (1000) according to claim 6, wherein: the interface (230) is a graphical user interface (GUI) accessible by a user (300, 350) through an Internet or intranet, and the user (300, 350) enters the limits through the GUI, the limits are related to plant-specific core operation parameters and plant-specific restrictions on operational reactor parameters.

8. - The arrangement (1000) according to claim 6, wherein the processor (210, 400) provides procedure recommendations to a user (300, 350) through the interface (230) to modify pattern designs of core load, based on the violation of one or more of the limits.

9. - The arrangement (1000) according to claim 6, wherein, in response to the data indicating the violation of one or more limits, the interface (230) receives a command that modifies the charge pattern design of test core to create a derivative core load pattern design; the simulator repeats the simulation in the design of the derivative core charge pattern, the processor (210, 400) compares the simulated results against the limits, and the interface (230) provides data indicating limits that were violated by the pattern design of derivative fuel loading during the simulation, wherein, in response to the data for each N derivative core charge pattern design indicating the violation of one or more limits, the interface (230), the simulator and processor (210, 400) perform N iterations of the modification functions, simulation, core load pattern design comparison and data rate, until the processor (210, 400) determines, in a particular iteration, that all limits have been satisfied or satisfied within an acceptable margin.

10. A method for determining a core charge pattern design for a nuclear reactor, comprising: receiving parameters input by a user that are applicable to a core of the nuclear reactor that is charged in accordance with a charge pattern design core test; simulating the operation of the reactor in at least one core subgroup to produce a plurality of simulated results; compare the simulated results against the limits; present data indicative of boundaries that were violated by the core during the simulation to be reviewed by the user, and modify the load core design of the test core based on the presented data to create a derivative core load pattern design, unless all the limits have already been satisfied, or satisfied within a margin that is acceptable to the user.