The many different data structures built into NiCE, 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_NiCE_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 NiCE more independent, these resources are used only when deemed absolutely necessary.
For a visualization and even briefer overview, look at the [Data_Structures_in_NiCE] page.
The form is essentially the graphic user interface. Developers with the binary build can create custom forms. It's worth noting that NiCE'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 NiCE, but it's an option, and is intended to serve a similar purpose.
TreeComposites are used to provide a multi-level hierarchical 'tree' of NiCE Components. They can have as many children and as much data per node as needed.
The components are elements that make up your form. There are different types of components to suit different needs, but for NiCE, components are almost always used for the visualization of data.
The BatteryComponent models a battery per the BatML standard, although the code is super suspicious. Maybe it does nothing.
This class is used as a container for entries that are related to each other, and essentially behaves like a Component from the UpdateableComposite package.
As the name implies, this component 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.
A MasterDetailsComponent manages a collection of masters and a collection of details. The masters are strings, while the associated details are placed in a DataComponent.
A 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,
This component 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--explicit mode--allows the user to specify each time step.
Unlike the other components, this one is found in the gov.ornl.nice.nicedatastructures.form.geometry package, and it contains shapes to help with the visualization of data.
The 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 NiCE, when we refer to something as an 'item' within NiCE, we mean the actual items you can create when running the program. Currently, this image would represent the selection of 'items'.
The JobProfile will allow users to 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 NiCE Item that will better suit their needs or consider [Compiling_NiCE_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.
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.
Many of the Items that can be created in NiCE contain among others, two main classes. One that extends JobLauncher, and one that extends Item, but acts as a model.
Bison is a MOOSE-based application for fuel performance and has applications for nuclear reactor designers. We have instructions for [Using_Bison], as well as a YouTube video.
CAEBAT is an open architecture software used to computationally model batteries.
CASL is an acronym for Consortium for Advanced Simulation of Light Water Reactors. ORNL acts as one of many contributors
MARMOT is also MOOSE-based--it shows the microscopic responses of nuclear fuel to irradiation.
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.
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, check out [Using_SHARP_with_NiCE].
This item is used to analyze data produced as part of a reactor simulation. It contains a DataComponent, a ResourceComponent, and a MasterDetailsComponent. The MasterDetailsComponent allows the user to select the types of analyses that should be performed, as well as set their properties. The DataComponent contains the entries for the input and reference data, and the ResourceComponent is populated by the generated artifacts. 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.
For non-programmers, an interface may best be described as a template; it cannot be an instantiated as an object the way a class can. 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 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 NiCE. 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.
This class 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 NiCE. More information on how to use it specifically within NiCE can be found here.
This class 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 anode in the CSG tree and can affect the appearance of the final surface or volume mesh when processed with the MeshKit.