Overview of ICE Data Structures
The many different data structures built into ICE, allowing it to be flexible and support many different uses. This page will briefly summarize the most relevant packages and classes. Users who are compiling ICE from scratch know that the source code is well-documented, but for anyone just looking to understand the process a little better, this consolidation of succinct descriptions and links to the heavier pages should lend some insight.
Versions of the majority of these superclasses can be found in Eclipse's or other third-party libraries, particularly those dealing with the user interface. In an effort to make ICE more independent, these resources are used only when deemed absolutely necessary.
For a visualization and even briefer overview, see the Data Structures in ICE page.
- 1 Forms
- 2 Items
- 3 JobProfiles
- 4 JobLaunchers
- 5 Model
- 6 JobLauncher/Model Pairs in NiCE
- 7 Interfaces
- 8 NiCEResource
The form is essentially the graphic user interface. Developers with the binary build can create custom forms. It's worth noting that ICE's Form class does not use any standard GUI libraries, such as swt, awt, or swing. It uses javax.persistence for persistence and object/relational mapping.
Each Entry is a value in your form. Developers using the class can regulate what kind of values are accepted, assign an acceptable range, and/or set default values. You can set parents, which creates entry dependency. You can mark a certain entry secret, which will obscure it from the user, and you can 'tag' entries, giving them secondary descriptions that won't be revealed to the user.
The primary purpose of a Listener is to monitor for the occurrence of certain events, usually something that the user has done with the mouse or keyboard. While there is a Listener interface in Eclipse's SWT library, for NiCE we designed our own.
A Composite is an SWT widget. Like a Form, it can contain many elements within it, such as components. In fact, within the org.eclipse.swt.widgets package, Composite has a subclass called Form. This is not the same Form we use in ICE, but it's an option, and is intended to serve a similar purpose.
Components are the different sections that make up your form. ICE has different components based on the different needs of each user or Item. These components can act as containers for visualizing data or for accepting input from the user.
BatteryComponent models a battery per the BatML standard. DataComponent is used as a container for entries that are related to each other, and essentially behaves like a Component from the UpdateableComposite package. GeometryComponent contains shapes to help with the visualization of data. MasterDetailsComponent manages a collection of masters and a collection of details. The masters are strings, while the associated details are placed in a DataComponent. MatrixComponent is made to provide the functionality of a two-dimensional array, thus imitating a matrix. The user can add rows and/or columns, allowing both square and rectangular matrices. ResourceComponent manages a set of ICEResources. For example, it can collect output data on a Form. TableComponent is useful when you have a set of entries that are related. As the name implies, it essentially creates a table. It uses java.util.HashTable to map keys to values. All non-null object can be used as a key or as a value. contains methods for adding and deleting rows, TimeDataComponent extends DataComponent, but is specialized for dealing with time loops. There are two modes. The regular mode allows the user to specify a start time, an end time, and the number of steps needed. The second mode, explicit, allows the user to specify each time step. MeshComponent is a composite container for polygons and accompanying data. Mesh is a common term in computer graphics and solid modeling. It refers to the generation of a three-dimensional collection of vertices, edges and faces that define the shape of an object. The faces usually consist of simple convex polygons (triangles, quadrilaterals), since this simplifies rendering, but they may also be composed of more general concave polygons, or polygons with holes. This may sound limiting, but nearly every object can be graphically represented in mesh.
In ICE, when we refer to something as an 'item' within ICE, we mean the actual items you can create when running the program. Currently, this image would represent the selection of 'items'.
This item is used to analyze data produced as part of a reactor simulation. It contains one each of:
- DataComponent - contains the entries for the input and reference data
- ResourceComponent - populated by the generated artifacts
- MasterDetailsComponent - allows the user to select the types of analyses that should be performed, as well as set their properties.
It uses the interfaces IAnalysisTool and IAnalysisDocument.
VisIt is a visualization tool co-developed by the Lawrence Livermore National Laboratory and the Oak Ridge National Laboratory. More information on it can be found here.
The JobProfile will allow users to programmatically create a custom JobLauncher. A tutorial on how to use it can be found here, but it is only suitable for simple tasks. To add complexity, the user should either find a pre-made ICE Item that will better suit their needs or consider compiling ICE from scratch and hard-coding a custom plugin.
This item simulates fuel performance. More on the AMP Fuel Performance code, a tool developed by ORNL, here/pii/S0029549312004141).
As the name would imply, the Model class is used for simulating physical systems. From a coding perspective, it's nearly identical to the Item class from which it inherits. The only difference is that the constructor takes an IProject as a parameter; the IProject is where the Item stores files.
JobLauncher/Model Pairs in NiCE
Many of the Items that can be created in NiCE contain two main classes--one that extends JobLauncher, and one that extends Item, but acts as a model.
CAEBAT is an open architecture software used to computationally model batteries. See our CAEBAT article for more information.
CASL is an acronym for Consortium for Advanced Simulation of Light Water Reactors. ORNL acts as one of many contributors
MOOSE is a software owned by Idaho National Laboratory, but it has many contributors, including ORNL. The acronym expands to Multiphysics Object-Oriented Simulation Environment, and MOOSE's primary purpose is to simplify the process of conducting simulations. The following items use the MOOSE framework:
- BISON -used to analyze fuel performance and has applications for nuclear reactor designers. We have instructions for Using Bison, as well as a YouTube video.
- MARMOT - it shows the microscopic responses of nuclear fuel to irradiation.
- RELAP-7 - expands to Reactor Excursion and Leak Analysis Program.
Nek5000 is actively developed at Argonne National Laboratory and is an open-source computational fluid dynamics solver based on the spectral element method. It's written in Fortran77/C and employs the MPI standard for parallelism.
While PROTEUS is still under development at Argonne National Laboratory, eventually it will be a nuclear reactor core simulator, primarily focused on sodium-cooled fast reactors, used for generating input files for launching neutronics codes, and launching that code.
SHARP, Systematic Human Action Reliability Procedure, is another tool still under development and currently only available to ORNL users. For more information, see Using_SHARP_with_ICE.
For non-programmers, an interface may best be described as a template; it cannot be instantiated as an object the way a class can be. In an interface, there are pre-labelled, but undefined, methods. A group of classes would implement the same interface if they're performing similar tasks, but with variations. This permits more flexibility than inheriting from or extending another class, where the methods have been pre-defined and must be overriden.
For developers, a crucial advantage of either of these techniques is that you can use different print statements for different classes. So if there's ever in an error in the code, checking the print statements on the console can be enough to determine exactly where things began to go awry.
The ItemBuilder interface registers an Item and builds specific Items. This is used as a pluggable service in the OSGi framework to provide the Items to ICE. For more on OSGi services, check this list of references.
The IAnalysisTool is responsible for creating the IAnalysisDocument, which we will examine soon.
- KDDAnalysisTool implements IAnalysisTool and is responsible for creating a KDDAnalysisDocument that performs and displays carious types of data clustering and anomaly detection for nuclear reactors. We have a list of references available for your viewing regarding KDD in general.
- VisItAnalysisTool implements IAnalysisTool for use with VisIt. As mentioned in the VisItViewer section, VisIt is a separate visualization software, which can work as a standalone. However, those who have it downloaded, will be able to view VisIt's images in ICE. More information on how to use it specifically within ICE can be found at our page on Using VisIt in ICE.
- KDDAnalysisDocument realizes the IAnalysisDocument interface and constructs user-specified data-mining algorithms and corresponding plots. It utilizes the Strategy pattern to decouple itself from the actual construction of individual data-mining algorithms.
This interface describes a type of solid in the geometry editor. Each IShape is a node in the CSG tree and can affect the appearance of the final surface or volume mesh when processed with the MeshKit.