Innovations Project Report

 

 

Abstract

 

This project sought to research into current and past simulations, into teaching methods which use computer graphics and to make a teaching tool that would demonstrate the principles of a nuclear reaction.

 

Introduction

 

Physics and in particular nuclear physics, has been an interest of mine for some time. I felt that the time given to me could be well placed by bringing together this interest and computer graphics. Whilst I know that computer graphics has been used before, most notably in java applets, to convey ideas about physics. I felt that I would be able to perform the necessary research to develop my own tool, one which would utilize 3d graphics ability to observe up-close visualisations of this type.

 

To this end I have researched and designed a particle system which looks closely at the splitting of atoms in nuclear fission. Some of this research was somewhat hampered by heightened restrictions on the entry to Britain’s Nuclear Power stations and public visitor centres preventing me from easily visiting them.

 

Research and Development

 

In choosing to develop a teaching tool I took it upon myself to develop a particle system which would be a visual aid with which to demonstrate some of the key ideas and theories of nuclear physics. Quite often people tend to learn by using and manipulating an object themselves.

 

This meant I needed to look at a number of sources, to find information such as what goes on inside a nuclear reactor. These then had to be broken down into different topics of research in order to produce a coherent and successful product.

 

One of these topics was what goes on inside a nuclear reaction, the mathematics involved and general details about fission. This would allow me to build the correct mathematical model of the system. And it would assist me in modelling the geometry of the system.

 

Another area that needed to be looked into was the development of simulations. Past simulations include outdoor environments or fluid simulations. In a more generalised simulation we are taking a real situation which has a:

 

 Cause -> system -> effect,                  

 

We convert this to a conceptual idea, this is then developed into a simulation where by we have input->simulation->output. At each of these stages it is necessary to verify and validate our system against the real situation.

 

With regards to implementation very little real research had to be performed as I have a prior knowledge of the graphics a.p.i. (OpenGL) I used.

 

The last area of investigation was to find information on implementations of teaching methods used before. I was specifically interested in the case of teaching tools used to explain a nuclear reactor, but also general teaching tools that have been used and are being used now to convey scientific methods and visualisations. Most of these have been quite mathematical and tend not to be accessible to people or they tend to be easily accessible but don’t include any underlying mathematics or rules that exist in the real case. Fake it to make it understandable and teach them seems to be a moto used.

 

My choice for doing this project came from, as stated before, my own interest in physics but also because I feel it is a field in which computer graphics has recently been lacking in. When computer graphics began it was very much a mathematicians tool, where by the graphics output took less precedence than the figures that drove them.

 

Since this time cg had travelled down the route of media and movie driven development so that we have very exciting uses of the algorithms and programs created. Cg seems to have lost touch with its roots, to convey and teach and to expand our knowledge and understanding of situations around us.

 

Donald P Greenberg [ref 5] has said that whilst the use of graphics in media has helped it gain public standing, it will be in the field of visualisation for scientists, engineers and designers that its true worth will be found.

 

In researching the graphical implementation of the program I was given a number of different options. The atom for instance we believe to be constructed from a number of smaller parts (protons and neutrons) which are bound together at the nucleus of the atom by strong binding forces, which when broken release large amounts of energy. To produce a highly accurate model we would want to create these individual nucleons and then group them together and use them as a single element. Certain implementations in the past have chosen not to go down this route. Instead they have represented the atoms as single spheres [ref 12], after all when bound up the collective act as a single mass, much like planets are made up from a larger number of atoms, yet when we describe them or calculate effects on them we assume them to be single mass objects.

 

 

So in this implementation, to display a 5 atom system would require only 5 objects, but in a multi-particle system where you create a nucleon for every nucleon that exists and you place them accordingly within the system. You would end up with an incredibly huge number of particles for a small number of atoms, which restricts the system to the processing abilities of the machine it is being run on.

 

My system is being built from a viewpoint of micro detail which is why protons/neutrons in the atoms are going to be included. (Not electrons, little effect on the purpose of this system.) because I want to be able to display everything that should be there, after all if neutrons are going to be causing this fission by collision then lets demonstrate the truth of this by implementing neutrons and protons in the nucleus.

 

 

What goes on inside a real reactor?

 

At this point I feel I should explain what actually occurs within a real reactor and explain what nuclear fission is.

 

Imagine everything is made from atoms. Small tiny particles, each one has kinetic and potential energy. There are some, dependant on size, that are more stable than others. Large isotopes like u235/236 have a large number of protons/neutrons, which makes them unstable and likely to decay. On the other hand certain elements such as Iron are far less volatile because a balance is struck between the forces of repulsion and attraction within the atom.

 

The act of nuclear fission [ref 15] is when an atom is broken down into two smaller elements/isotopes of elements by forced collision with another object. This other object is typically a neutron since any charged particles such as an electron or proton would be repelled away by electrostatic forces.

 

When this breakdown occurs the energy required to bind the two newly formed atoms together is less than that which was required to hold the parent together, this energy is released in the form of kinetic energy and heat to the surrounding area.

 

The reason for the presence of such a large binding energy is due to the need to overcome the repulsive desire of the protons to one another.  This repulsive force is large because of the close proximity of the protons to one another when trapped in the nucleus.

 

Nuclear reactors were developed because of the ratio of energy we can obtain from the fission compared to the energy that was required to cause the fission.  Released heat energy is transferred via fluid convection flows, which in turn becomes steam which is converted to automotive energy and ultimately electrical potential.

 

Should an unstable atom be hit by another particle flying at high speed, which can transfer energy into the atom, then we can cause fission. This can then be extended to try to form a sustainable chain reaction which can hopefully be controlled. This is typically managed in a modern reactor but having a number of fuel rods held within a sealed container flooded with a high conduction coolant. The mixture within these rods is u235 and u236, the quantities ratio of the two is derived from the accessibility of the products, the efficiency of the system wanted and the desired waste products (i.e. high breed = plutonium). The efficiency is important because the two isotopes have different properties when hit by speeding neutrons, 236 tends to fission better with fast neutrons and 235 with slower ones.

 

Were there not to be right ratio we wouldn’t be making full use of the neutrons presently flying around inside.

 

The starting neutrons are supplied because of the principle of critical mass where the number of naturally decaying atoms creates a number of neutrons that can start the chain reaction and sustain it.

 

 

The breakdown of the fuel releases additional neutrons which increase the rate of fission because of the greater likelyhood of collision. To prevent the system from running out of control, rods made of a compound mixture which absorbs these free neutrons are inserted between the fuel rods, since the neutrons are free and can travel outside of the fuel rods they pass though the space occupied by the controlling rods, this allows for control over the number of free moving neutrons in the reactor which in turn leads to a control rate of reaction.

 

Current Simulations

 

This leads me to methods used within real reactors to try and see what’s going on inside of them. Within new reactors control of the core is beginning to be taken over by computers, however, traditionally it was controlled by skilled and experienced operators. Because there were any number of factors that could be affecting the system and the operator would have to respond accordingly by measured amounts. They use a previous knowledge of events to try and second-guess what will happen and produce an appropriate response, in the past due to binary logic computers could not create an adequate response. This response might differ each time.

 

As far as simulating the core it is impossible to model mathematically this is due to:

 

 

Some larger knowledge can be applied to a simulation that looks at the overall state of the core rather than individual elements. Because of the uncertainty in knowing what’s really happening using binary logic (if …then) would be unsuitable [ref 2].  This requires a fuzzy logic situation. Adaptive laws are developed which state…

 

            At this point do some of this but not all, or do this or not.

 

Using a knowledge bank contains all the previous info about the situation, and then dynamically adapts its responses depending on the current data it receives. In time it will hopefully be accomplished.

 

In the past Simulations involving a reactor have consisted of heat flow and vapour/fluid dynamics/flow. It’s often needed to know what its doing or going to do given a particular situation. TOUGH2 [ref 4]

System Setup

 

The core of the system is formed from the positions of all the points, stored within two lists, which are continuously updated and redrawn to the screen. During the update loop, controls are applied to the particles which alter their states given a set of boundaries and individual additional attributes such as colour and direction.

 

Given that during this update loop any number of conditions or state changes can be made, so then the particles can easily grow in complexity and accuracy of the real world situation.

 

At this point we have a set of particles, they are contained in a list having a position, direction/velocity and colour. What we now need is for some of these to be bound up, grouped as larger objects, not just as individual entities but also as a part of a larger entity.

 

In order to achieve this state a second list was created in which we define the position of these larger entities and the number of particles that are contained within them. These entities were then given the name of atoms to distinguish them from the individual particles. To access any particular particle it is then necessary to parse through the number of particles in the atoms before. For example if each atom contains 5 particles then to reach the third particle in the third atom we have to parse the prior particles in the neutron list:

 

Func count ()

{

While (! third Atom)

{

I = Atom.NumParticles;        

}

I+=first three particles;

}

 

I = 5+5+5+3, which would give us the 18th particle.

 

Controls on Particles

 

During the update loop three new controls were placed on the lists. The first of these a rotation for the atoms and a system by which they have a small oscillation indicating their latent energy level. The second control, collision detection checked each of the free neutrons against the list of atoms for any hits against one another.

 

The third control used the collision between atoms and free neutrons to control its trigger, when triggered it caused the current atom being checked for collision to be split and broken down into two smaller parts.

 

The collision detection was implemented by first checking the distance between the point that’s flying though space and the point in the centre of an atom, if that distance was equal to or less than the radius of the atom then we can easily say that it must have come into contact.

Of course it is possible that even when an atom and a neutron collide that there won’t be fission. This could be down to a number of reasons the most likely to be either that the neutron hit with too little force to overcome the nuclear binding force or that when it hit it the angle of incidence was at too shallow an incline so that it glanced off of the atom, failing to transfer its energy correctly.

 

Assuming that fission has been achieved the act of splitting the atom falls down to a data management algorithm which reassigns a number of the particles to a new atom, updating the old one to account for the loss of mass. A random direction could then be assigned to the new and old atoms so that they move apart over the succeeding seconds.

 

With the particles set up into their free and grouped states, visualisation of the system can begin. However it would be stupid to allow the particles to move off on their own without some control as they would spread apart and never interact. The solution to this was to place a large bounding box, a simple cube around the particle system. As the particles approached the boundary they are reflected back at an opposite direction to their incident vector.

 

User Interactivity

 

User interactivity, one of the main aims of this project, (to try to produce a program that anyone can pick up and learn from), needed to be built into the main program. The current implementation being used allows for semi/full interaction between the user and program.

 

Having created the system all we have is an opengl view with particles within this view. Camera movement is restricted to looking up/down, sliding left/right and zoom in and out. Since this program is supposed to be a learning tool the user should have control of the actual system rather than merely observing from a distance.

 

Once they’ve input the starting variables such as the number of atoms or number of free neutrons they don’t have any real control other than being able to reset the system back to its initial state.

 

So what needed to be designed was a user interface which would allow the user to directly control how fast the reaction is running inside the system. We know that in order for there to be a reaction a neutron must hit an atom. This gives several different methods to control the rate of reaction.

 

The easiest way to increase rate of reaction is to increase the number of free neutrons, as an atom is split you get an extra neutron for free, so that over time, theoretically the system should increase its rate of reaction. Assuming the fissionable material doesn’t run out and assuming neutrons aren’t wasted by escaping or slowing down.

 

Another way to increase the rate of reaction would be to increase the density of the atoms in the system so that then the neutrons that are there have a greater likelihood of hitting those atoms.

 

The final method of control is to take away neutrons; atoms cannot be removed as they are sealed within the solid. But as the neutrons are moving, if we can trap them as they pass through a particular point in space, then they can be taken away from the system. This is implemented by the use of control rods. These control rods are essentially volumes of space which are slid in and out of the 3D world. If a neutron enters into this space it slows down to a stop and is removed from the system. This way by pushing in the control rod to its furthest extent, the volume the neutrons have to pass through is quite large, so the chance of them entering the space is greater than for a small volume. This system allows for the removal of large numbers of neutrons at high speed and thus an efficient way to reduce the rate of reaction.

 

When the control rods aren’t in place the rate of reaction will increase on its own due to the release of neutrons with each fission.

 

Having this control visually is very useful, however additionally with this user interaction we want to be able to output values.

 

Number of reactions (counter)/timer (1second) = ROR

Energy released = ???

Implementation

 

In order to provide functionality and to save time so I wouldn’t have to create many of my own data types and functions, I decided to make use of Jon Macey's graphics library as this had data types such as 3d points, vectors, and rng and this would allow me to easily implement mathematical formulas without having to spend time writing the math myself.

 

When the program loads it reads in no command line arguments. Before the main is called the program creates some global data types for use throughout the program. These include typedef for a std::vector list of atoms and a std::vector list of nucleons. After the typedef an atomlist and nucleonlist are created with the name Atoms and Nucleons respectively. Other global variables that are created are the bounding box and information about the camera and window size and shape to be passed to the camera class and to the glut main loop.

 

Having initialised the global variables, Main() is called. In order to reduce the  outward complexity of the system so that someone with very little command line experience can use the program the decision not to make use and passed arguments from the command line was made. Instead the program prints out to the console requesting each of the variables that it needs for initialisation, as it needs them.

 

The system makes an extensive use of random numbers to determine initial positions and directions, so a seed is set for the Random Number Generator (RNG). This is taken from the current system time, in seconds.

 

Next, having prepared for the particles, the system needs to know how many atoms/groups of  particles and how many free particles it can create. These are read in from the command line and placed into temporary files which can be passed to the initSystem() function.

 

The initSystem function can be broken down into three sections, each responsible for the creation of a particular aspect of the system. The first of these is responsible for the creation of the particles contained within the atoms. A loop iterates through each of the atoms in turn and from the beginning, reading in their atomic mass and atomic number, both of which are used to decide on the number of particles and whether they should be neutron or proton, before creating them and adding them to the nucleon list. The second of the sections is responsible for the creation of the free particles. A read is made of the atomic mass of the final atom in the atomlist and the free particles added to the list. In the third of the sections the control rods and bounding box are given locations and normals.

 

Each of the particles is added to the list by the process of creating a nucleon data type and setting its variables. This particle is then added to the end of the particle list by the use of a  push_back function from the std template library.

 

Now that the system has been created the program moves into the update and draw loop. Again this has been split into separate parts so that improvements can be swapped in/out depending on the need.

 

The update works by first updating the position of the particle according to the attributes it currently has. This is accomplished by the now tested practice of iterating through the particles and calling updates that move the particle in a certain manner depending on the attributes of the particle. Once all the particles have had their states updated the calls to the controls can be made.

 

The first of these is the inter-particle collision function which tests for collision between the particles and any of the atoms.

 

The atomCollision() func detects if any of the particles are touching or within the volume of space defined around the atom. This is accomplished by checking each of the particles in turn against each of the centre points of the atoms and determining whether the distance between these two is less than the radius of the particle, if this is true then there must have been a collision. A new reflected direction vector for the particle to travel in is then calculated. Using the surface normal of the parametric sphere at the point of collision and the incident direction of the incoming particle, as parameters in a dot product equation,  a factor for the new direction is found. This multiplied by the surface normal and then subtracted from the original vector results in the new vector.

 

Should there be a collision the program calls upon the atom splitting function –splittingTheAtom(). This function takes in as its parameters: the current atom being checked against, and the particle  being checked against it. What then happens is more an act of data management than one of graphical or physical mathematics. Whereby 144 of the 235 particles held within the atom are transferred to a new atom. The act works by first setting the colour of the particles in the atom hit, to a new colour. Next the position of the current atom is taken and stored in a temporary variable, the atomic mass and atomic number of the atom are reduced to account for the first 144 particles and a random value is set to the atom[i].Dir.

 

Next a new atom is placed into the array, at the point just after the current atom (current+1), this is set with the same position as the current atom but seeded with a newly generated random number. This then leads to the two atoms moving apart over time. The Atomic number and mass of this new atom is taken as the remainder of the particles that are no longer assigned to the original atom.

 

Finally a flag is set on the two atoms instructing the atom collision function not to call the splittingtheAtom function should either of these new atoms be hit by another particle, this prevents the system from trying to split them again, an action that would cause the system to fail.

 

Having checked all of the particles against each other to determine if any collisions have occurred the system now calls the second of the controls, the shellCollision() func which detects if the particles have collided with the bounding box, if so then they are reflected back in a similar manner to the inter-atom collisions. However in the case of the bounding box it is necessary to perform the check six times, once for each normal that defines a side of the bounding box.

 

In a final check the system now asks whether any of the particles need to be removed from the system because they’ve come into contact with one of the eight control rods. This check uses a system very similar to that of the atom-particle collision check but with two slight differences/optimisations.

 

To begin, the program creates a loop to check each of the free particles against the control rods. Next it performs a quick check to see if the y component of the particle’s position is within the bounds of the top and the bottom of the control rods. If the particle isn’t then it is possible to trivially discard it as having not hit the control rods. If the particle cannot be easily discarded in this way it is necessary to check the distance between the centre of the rod column at the height of the particle and the centre of the particle. If this distance is found to be less than or equal to the radius of the rod then the  particle is erased from the particle list the atomic mass of the last atom in the atoms list is decremented by one.

 

Now that the controls that alter the state of the particle have been dealt with, the program moves to dealing with updating the positions of the particles and the atoms. This is performed by iterating through the list of particles and adding to their position the distance specified by their direction. Secondly, for the atom bound particles, a local rotation around the centre of the atom mass is made. To achieve this local rotation a translation back to the origin has to be made. This is followed by the rotation before finally translating the particle back  to the position of the atom mass. This translation to and from the origin is necessary in order to have the particles rotate around the centre of the atom and not the origin.

 

Having completed the update loop the program now moves into the display function. The program begins by setting the viewing matrix to take account of any movement of the camera by either mouse or keyboard presses. After drawing a simple glut wire cube (to represent the bounding box)  to the buffer, a clipping algorithm is called. This algorithm takes in the current viewing matrix for the window and then checks each of the particles to see if it can be seen within the view. Only those particles that can actually be seen are then passed to be drawn, any others are trivially discarded. Another potential optimisation algorithm used in the program is a depth test, here the distance from the camera eye to the particle is taken and then used to choose a level of detail with which to draw the sphere. This level of detail ranges from particles with around 25 vertices to particles with 3 vertices. 

 

Having completed the drawing loop the program will return to the update loop until an interrupt causes it to either reset or exit.

 

The reset is achieved by copying the initial state of the system into a second two lists at the beginning of the program. Then when the reset is called the original list is destroyed clearing out the changes that have occurred to it. A new list is then inititated with the values from the copy of the original list. This new list is then passed to the update and draw loops.

 

When the interrupt to exit the program is made the std template library automatically destroys the lists created and returns to the console.

 

The user interface for the program has been created using standard glut and OpenGL callback and keyboard/mouse controls. When either the mouse or keyboard is used a call back is sent to a function in the program which checks to see if it is a particular key that has been pressed, and to check which of the mouse buttons has been pressed/released.

 

Should the key pressed be one on which a function has been mapped then that function will be called. An example of this is the space bar which calls for the system to be reset. The left mouse button and various keys manipulate the user view and a right mouse click causes a pop up window to be opened which holds several options for the user.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Conclusions and Evaluations

 

When considering the success of this project and trying to evaluate it, it is not only necessary to cast a look at the original aims and objectives, but to also begin to think about future work that can be carried out on the project to extend and improve on that which has been completed.

 

I’ll begin by evaluating the tool I’ve built during the time of this project. My initial personal views on the program/system/tool are that whilst it has managed to reach some of the aims that were set, for the most part it has failed to be as user friendly, accurate and efficient as it should have been. I also feel that, having looked at the system closely, it fails to simulate the act of nuclear fission in a manner that makes it understandable.

 

This said, the system does have many positive attributes to it and has the potential to become a highly useable and creative teaching tool with continued development.

 

The original aims of the project were to:

 

Create a teaching tool that whilst mathematically accurate was also easy to use and understand.

 

As we look at these aims I’m  going to break down the system to show ways in which it has achieved the aims, at least in part, and to give details of how given a little more development time it would/will be possible to raise their standard to a point where they fully meet the requirements of the aims.

 

The Core

 

The first of the aims was to produce a particle system that held atom objects and smaller free nucleon objects. At this the system has been able to successfully achieve its aim.

 

 

I have been able to create several lists of ‘atoms’ and ‘nucleons’  in a manner that has given me the ability to manipulate the particles in several demanding ways. Having the atoms stored as conceptual objects that then have their geometry stored within the larger particle list, allowed for the control of the atoms and their children to be performed separately and hierarchically. An example of this is in the update function, here we find that it is possible to rotate the small particles around the centre of the atom yet at the same time it is possible to translate the atom by a given vector, this translation is then passed on down to the child particles so that they follow the atom and maintain  relative position.

 

The use of two separate lists also allowed me to add to one list without it affecting the other in any great way. This can be seen in either the reset, addneutron, add atom, controlrod functions. Each in some way used the ability to either introduce particles to a point in the system or to take away from the system.

 

I’ve been able to show that the system core, the data management in this case had reached a level whereby it is now possible using various combinations of functions and function parts to manipulate the particles in any way we wish.

 

The structure of the program was also implemented in a way that permits new functionality and controls to be added to the program. These can be included into the main program at the update function stage but can have their source written separately. This modularity was achieved by the use of a semi oo structuring of the system with the use of classes and the c++ programming language.

 

 

Of course any system can be improved on and  in future work there are a few areas  that could be altered.

 

For instance when traversing the particle list it is necessary to count the number of particles to the point you require before accessing this point, this means that loops are needed which can slow down the execution of the system, an alternative to this might be to use pointers to the first particle that forms an atom, this would allow for easier manipulation of the particles and optimisation of the system.

 

The system would also benefit greatly from further optimisation, at present I have been able to increase speed by clipping particles that fall outside of the current viewing matrix, and to reduce the number of vertices used to draw a particle at a distance.

 

Further optimisations could be to investigate the use of OpenGL extensions, passing drawing and window processing to the graphics card thus relieving the load on the processor. However the impact of these extensions will probably not be that great without changing the drawing methods used to describe the atoms.

 

This is because for every atom in the system there are 235 particles created, so when 10 particles have been created the system has already reached over 2,000 particles. To increase performance use of the data management code can be used to change the way the atoms are held subject to their distance from the camera eye. So instead of representing the atoms from many particles we can use single spheres, until the atom reaches a certain minimum distance from the eye. At this point we can create individual particles to represent the atom and swap these into the drawing loop instead of the single sphere. When the atom moves away we can swap back again and delete the small particles.

 

Another optimisation may be the order in which the source code is executed, is it better to make many loop though the particle list making all checks for one particle before moving onto the next, or is it better to loop through the list several times, one for every check? The list of optimisations and improvements is endless as for each improvement a new improvement will be wanted.

 

So whilst I can say with reasonable confidence that as a particle system with grounds for vast improvements the project has been a success. I find that in terms of the user interface the project is far from being finished. There were key elements I wanted to include that unfortunately due to time management failures were not added into the program. One of the most important of these is a way of outputting to the OpenGL buffer what is happening within the reaction. I had intended to inform the user the rate of reaction and the amount of energy being released by the system. Instead at present the system prints to the console when collision has occurred and also shows the number of free neutrons whenever they change in number.

 

Another user interface improvement might be to choose the particles the user wishes to show, for instance only display the green collided neutrons or purple released neutrons.

 

These user problems I believe will be solved in time, a major revision will be the porting of the code into a GUI application using the designer software released by QT. This allows for cross platform GUI elements to be created which interact with our own source code.  

 

With this addition to the program I believe that the tool will have reached its aims successfully and have a possible true worth. This of course would have to be topic of further investigation.

 

 

 

Summary

 

Having looked over the aims I have, the project, and considered the conclusion. I feel that the project came out with a surprising level of success. Whilst it may not be the user-friendly program I had wanted it to be, it possesses the essential elements needed to improve it.

 

I think that I should have been more careful with the time management aspects of the project and also performed more research on ways people have implemented ideas like this before.

 

Additionally I realise that after starting out wanting to develop a clever system I ended up working on more of a project about data management than physics. This is why I no longer feel that stringent obeying of the laws of physics is necessary for a program of this type. It isn’t a real situation so there is no reason not to cheat.

 

To conclude, I am happy with the results I have obtained from the completion of this project. But I feel that it would be in the best interests of the system to help it reach its full potential by continuing work on its user interface at a later date.

 

References

 

  1. Cesare frepoli, john h,mahaffy, katsuhiro ohkawa 2003– dots on the implementation of a fully-implicit numerical scheme for the two-phase three-field flow model – Nuclear Engineering and Design 225 191-217

 

  1. M. Mars Guerra, E. Zion 2003 – Model-free fuzzy tracking control of a nuclear reactor - Annals of Nuclear Energy 30, 953-981

 

  1. jerzy karczmarczuk 2003– structure and implementation of quantum mechanics – a functional framework – acm 1-58113-758-3/03/008

 

  1. Erik elmroth, Chris ding, yu-shu Wu, karsten pruess 1999 - A Parallel Implementation of the Tough2 Software Package for the large scale nmultiphase fluid and heat flow simulations – ACM 1-58113-091-8/99/001

 

  1. Donald P.Greenberg 1998 - Coons Award Lecture – Communications of the ACM Vol 31 No. 2

 

  1. f. douglas swesty, paul saylor, dennis c.smolarski SJ, e.y.m.wang 1997- Scalable, hydrodynamic and radiation-hydrodynamic studies of neutron stars mergers - acm 0-89791-985-8/97/0011

 

  1. Louis G. Birta, f.nur Ozmizrak 1996 – A Knowledge-Based Approach for the Validation of simulation ModelsL thru foundation – ACM 1049-3301/96/0100-0076

 

  1. Charlie Gunn 1993 -Discrete Groups and visualisation of the three-dimension manifolds – University of Minnesota

 

  1. Robert C.Crain et al 1992 – keynote address, celebrating twenty-five years of progress – proceedings of the 1992 winter simulation conference

 

  1. Mark Phillips. Charlie gunn 1991 – Visualizing Hyperbolic Space: Unusaul uses of 4x4 Matrices – the geometry centre

 

  1. Misako Ishiguro, Mitsuhiro makino and naohisa shinozawa 1988 – Vector and Parallel Processing of the Nuclear Reactor Transient Analysis code RELAP5 - IEEE CH2617-9/88/0000/0230

 

  1. Nelson L. Max – ATOMLLL :- Atoms with Shading and Highlights – Lawence Livermore Lab

 

  1. Joseph s.griffen, John Crag Comfort – A Fault Tolerant Computer System for the simulation of Complex Systems - Annual Simulation Symposium

 

  1. Susan Cooper 2000 - Particle and Nuclear Physics, MT 00

 

  1. Tony Hey and Patrick Walters 1997 - Einstein’s Mirror – Cambridge University Press ISBN 0-151-43504-8

 

  1. Jim Breithaupt – understanding physics for advanced level 3rd ed – 1995 isbn 0-7487-1579-7

 

  1. OpenGL ARB 1999 – OpenGL Programming Guide 3rd Ed – isbn 0-201-60458-2

 

  1. http://www.hazelwood.k12.mo.us~grichertsciwebnuclear.htm

 

  1. http://nuclearweaponarchive.orgLibraryNukesims.html

 

  1. Qt designer by Trolltech – www.trolltech.com