The picture shows how Impact is structured. Impact is strictly object oriented in its design and I will use quite a few of the terms in the coming explanation. To appreciate the terms of object oriented programming, please read any book on the subject. Have a look in the Theoretical base for recommendation.
The elements and the nodes have each got their own class. Since there can be several types of elements, the element class is a superclass and it is also abstract which it acts as "format" for how a subclass should be written, which methods it should have etc. The element super class also contains some methods which are general and usable by all the element classes.
Impact is the main class. All it does is to immediately initiate an instance of the class ModelSmp and then it tells that instance to initiate, solve and postprocess the problem. ModelSmp also includes a large array of nodes and elements which in fact is the actual model. When asked to solve the problem, it runs down these arrays and tells each element to update itself, over and over again.
Another important class is the material class. Since there can be several different types of models for a material, this is a superclass and then there are several subclasses. Right now, there are two material models available. One for pure elastic materials and one elasto-plastic materials (materials which are elastic to a point and then acts as gum beyond that point).
A model also contains constraints, forces and boundary conditions. Each of these have their own class and each element which has forces defined on it, knows about that by having a handle to the respective constraint etc.
Each element also knows about which nodes it has so that it can feed it's mass and forces to the nodes when asked to.
Finally, the reader class handles the reading of indata files (where the problem is defined) and the writer class handles the writing of the result files. Both are super classes in order to allow for several different indata and outdata file formats. This allows Impact to be compatible with other programs such as LS-Dyna and Radioss in the future.
The Impact class is the main class of the program. It is here the program starts and the following happens:
In the future, something like a command centre can designed in this class, creating a nice user interface. The possibility of initiating several solutions running in parallel is also easily accomplished. Just create several objects from the ModelSmp class!
The ModelSmp class is the centre of Impact. Here, the model is stored in two large arrays. One array for the Elements in the model and one array for the Nodes.
In addition, a number of smaller arrays are also used to store the Loads, Constraints and Materials that are defined in the problem indata file.
In short, an object created from the ModelSmp class will do the following:
The reader class is the abstract parent class for different file translators. The challenge with structuring Impact was to figure out a good way of separating the input file format from the rest of the program. This was the result.
The reader class (or rather any chosen subclass) have two main tasks:
These tasks mean that the reader class must be able to interpret the indata file in terms of grammar and words.
Imagine now, that the reader class reads a typical indata file. A problem was that if the reader class must be able to know all the parameters that a certain element needs (for example), read these, generate the corresponding element object and then feed that object with all the data from the file, this means that the programmer must go in the the reader class and change when he/she adds a new element class or changes a class.
It is more attractive if the reader class can be independent from the element class. The solution used in Impact is that part of the interpreter is actually included into the element class, namely the part that reads the element parameters. The reader class just feeds the element with the actual indata file line where the parameters are written and the element does the rest.
You can read more about this solution in the element chapter
The writer class is the mother class of all the different writer classes. Each subclass provides a different output format.
A writer object is created at the start of the solution run and it is then called every time that Impact wants to print to an outdata file. This can happen several times during a solution. The writer class then walks through the database of elements and nodes and asks each of them to write their status.
An equal challenge as for the reader class is present here regarding being able to add new element classes without having to go into the writer class and change. The solution is the same, namely that the writer class asks the element object to print it's own line of outdata (in the right format), which is then directly written to the outdata file. All the preparation is made inside the element itself.
Due to how the outdata file is structured, the method that writes the data in the element is somewhat complex. The writer calls the same method several times, depending on if it wants the element to write data for a header or for another location in the outdata file. This is accomplished using control codes and is more explained in the element chapter.
This layout means that the element class needs to have one method for each new reader class (output file format), but since the amount of file formats are significantly less than the amount of element types, this is feasible.
The element class has been carefully designed to be self containing and easy to expand. The problem when writing a program is usually that when a programmer wants to add another feature (such as a new element type), it also means digging around in a lot of code which is indirectly related to the new element type.
The benefit of Impact is that this is not the case here. The programmer only needs to consider the following:
Once that is decided, the programmer is then free to add the new element along the lines described later in this manual. The basic method is to add a new subclass to the existing abstract class "Element" and then fill that new subclass with code.
When Impact is run and a number of elements are read in from the input file, a corresponding number of element objects are created. One object for each element.
The object will get a "memory" where it remembers which nodes it has attached to it, which material it is made of and so on.
If we stop a bit at the material "memory", I'd like to explain a little bit more in detail how it is handled. Some material laws need a memory in itself. This is the case since once some deformation has been made, a permanent deformation remains after unloading. This phenomenon means that the element (and material law) needs to remember how much it has been loaded in the past to accurately model the permanent deformation.
How to solve this? Well, the solution is quite simple. Once the element object has been created, a local internal material object is created which is based on the material law that the element is supposed to use. One can then think of the element object actually encapsulating it's own material object.
From here on, the element object talks only to it's own material object and since the material object keeps track on where it has been, the element object also has a memory of how much it has deformed.
A Solution run in Impact basically means that the solution loop (which is located inside ModelSmp), runs down a list of element objects and tell each of them to:
Since the element knows about its nodes and has a local material law to talk to, everything can be handled inside the element.
The purpose of the abstract element class (encircled) is threefold:
Each element class interprets its own indata. This means that the programmer does not need to change the reader or the writer class when adding a new element class. This is handled by the actual element class itself.
More details about this comes later in the chapter about how to add an element
A model consists of elements and nodes. The Node class defines the nodes behaviour.
In explicit codes, nodes are a bit extra important since the elements really only provide forces that act on the nodes.
All the mass of the elements are moved out into the nodes at the start of the solution process (initialization) and from there on, the simple formula of A=F/M is used to calculate the acceleration resulting from the forces put on the nodes by the elements.
The only thing the node has to do really is to be able to calculate it's acceleration, velocity and position in space and to accept forces and mass from the elements.
In the future, contact intelligence will also be built into the nodes.
As mentioned before, the node class is used by the reader class to create one node object for each node defined in the indata file. The node object is then fed some indata like its position in space and any constraints that might be applied on it.
The Load class is more or less a container for data regarding the different load cases that can be applied to elements and nodes.
In the start of a run, the indata file is scanned for load sets. For each load set, a load object is created and fed with the corresponding data (example Fx = 5 kN).
Each element or node which uses this load set, then has a handle to load object and can ask it about which loads that is applied. This is used especially by the nodes to figure out which loads that has to be added before it updates it's position.
The setup for the Constraint class is quite similar to the load class.
In the start of a run, the indata file is scanned for constraint sets. For each constraint set, a constraint object is created and fed with the corresponding data (example Ax = 5 m/s2).
Each element or node which uses this constraint set, then has a handle to it and can ask it about which constraints that are applied. This is used especially by the nodes to figure out which constraints that has to be applied before and after it has updated it's position.
There can be several different types of constraints. Therefore the constraint class is a superclass and there are different subclasses. Examples include the standard BoundaryCondition and RigidBody.
The controlset class is a special creature. It contains all the different control parameters that can be used to control the solution of a problem. Examples of such are:
At the start of a run, the indata file is read (by the reader) and a controlset object is created and fed with all the control data. Note that there can only be one control set object for each solution.
The controlset object is used by the ModelSmp object to control the solution. The main solver routine inside ModelSmp asks the control object about all the things in the list above so that the solution is performed correctly.
This class is the abstract "mother" class for all the different material laws that can be defined. The basic function of a material law is to calculate stresses from a given strain matrix and a given strain increment (also in a matrix format).
For a purely elastic material law, this is quite simple. Stress = Young's_modulus * strain, if we think one dimensional. When we move into elasto-plastic material laws, life becomes a little bit more complicated, but the basic principle remains. Return a stress, given a set of strains.
For reasons described in the element class, a local material object is created and embedded into each element object that is created. This material object is then "alive" throughout the whole solution and is having a frequent communication with its "mother" element, all the time answering the same question (about the stress).
The purpose with the abstract material class (encircled) is threefold:
At the current state of writing, there are only two material subclasses defined. One elastic material law and one elasto-plastic.
Each material law class interprets its own indata. This means that the programmer does not need to change the reader or the writer class when adding a new material law class. This is handled by the actual material class itself. More about this can be read in the chapter about how to add a material law sub class
The tracker class has been carefully designed to be self containing and easy to expand. The problem when writing a program is usually that when a programmer wants to add another feature (such as a new tracker type), it also means digging around in a lot of code which is indirectly related to the new tracker type.
The benefit of Impact is that this is not the case here. The programmer only needs to consider which input syntax the new tracker should use. Once that is decided, the programmer is then free to add the new tracker along the lines described later in this manual. The basic method is to add a new subclass to the existing abstract class "tracker" and then fill that new subclass with code.
When Impact is run and a number of trackers are read in from the input file, a corresponding number of tracker objects are created. One object for each tracker.
The object will get a "memory" where it remembers which nodes or elements it should read results from and so on.
A Solution run in Impact basically means that the solution loop (which is located inside ModelSmp), runs down a list of tracker objects and tell each of them to:
Since the tracker knows about its nodes, everything can be handled inside the tracker.
The purpose with the abstract tracker class is threefold:
Each tracker class interprets its own indata. This means that the programmer does not need to change the reader or the writer class when adding a new tracker class. This is handled by the actual tracker class itself.
More details about this comes later in the chapter about how to add an tracker
The TrackWriter class is the mother class of all the different TrackWriter classes. Each subclass provides a different output format. An example of such a subclass is the GidTrackWriter class which prints results so that they can be read by the GID pre- and postprocessor.
A trackwriter object is created at the start of the solution run and it is then called every time that Impact wants to print to an outdata file. This can happen several times during a solution. The TrackWriter class then walks through the database of elements and nodes and asks each of them to write their status.
An equal challenge as for the reader class is present here regarding being able to add new element classes without having to go into the trackwriter class and change. The solution is the same, namely that the trackwriter class asks the element object to print it's own line of outdata (in the right format), which is then directly written to the outdata file. All the preparation is made inside the element itself.
Due to how the outdata file is structured, the method that writes the data in the element is somewhat complex. The trackwriter calls the same method several times, depending on if it wants the element to write data for a header or for another location in the outdata file. This is accomplished using control codes and is more explained in the Tracker chapter.
This layout means that the tracker class needs to have one method for each new TrackWriter class (output file format), but since the amount of file formats are significantly less than the amount of tracker types, this is feasible.
One of the most challenging parts of a dynamic finite element program is to design a simple and robust contact searching algorithm. The following chapter describes the one used by Impact
There are two major classes of contact algorithms. One searches nodes and checks them against a surface to determine if contact is imminent. The second class searches element surfaces and checks them against other surfaces (and edges) to determine shortest distance and thereby if contact is imminent.
The element to element concept is a bit trickier to implement since we want a concept that is as general as possible and not dependent on any element shape or type. The node to element type is simpler in design and well documented which makes it the Impact choice for now.
The distance from a node to a surface can be tricky to calculate if the surface is complex. If, however, the surface is a simple triangle, it is just a matter of linear algebra. We also want a general method which works for different type of elements. These two reasons has resulted in a concept where contact "finite surfaces" are used.
Any element uses one or several contact surfaces to handle the contact with other elements (or rather nodes). When the element is asked to check its contacts, the element in turn asks each of its surfaces to check for contacts. The resulting contact forces are then distributed onto the element nodes. Each element handles its own surfaces.
An example could be the BLT Quad shell element already implemented in Impact. Since this element is flexible and can bend, two flat triangular contact surfaces cannot accurately model the shell element. In this case, a number of four would be suitable. Each of them connected to a centre point on the shell element and to two corner nodes respectively. It would represent the curvature in a rough but simple way and even allow for self contact, i.e. when the element wraps around and contacts itself. This can happen for example in a fold of a member in crush.
The beauty with this approach is that every new element can use the suitable configuration of these surfaces thus allowing a very general implementation. The logic of contact search etc is all isolated and put inside the contact surface "element", making it easy to upgrade in the future.
Due to the object oriented approach in Impact, it is natural that each node should have a handle to the closest neighbouring node on both sides. This handle is constantly updated for the node when a new position is calculated. The "neighbour" knowledge of the nodes comes in handy now when nodal search must be done. Put simply, the element in question only needs to search the nodes in its immediate vicinity and that means searching all the nodes between it,s own nodes since these are on the edge of the element.
The neighbour search works only in one direction. Currently, this is programmed to be the global x-direction in the solution space. That means that any element must start with the one of it,s nodes with the smallest x-coordinate. Next, ask that one which neighbour node it has with higher x-coordinate. Check this node for contact. Next, ask that node for it,s neighbour and so on until it reaches that of it,s own nodes with the highest x-coordinate.
The amount of nodes to search now becomes much smaller than before and can usually be even smaller if the model is oriented optimally in the x-direction. For the shell element in this example, four contact surfaces needs to be checked against each node. All of this coding is isolated inside the element. The only command given to the element is to check for contact.
Contact handling in Impact is implemented through the use of contact elements. Contact sensing against surfaces are handled by the Contact_Triangle element and sensing against edges or beams are handled by the Contact_Line element. The implementation of these elements will now be described.
The basic element to sense surface contact is the triangle. A triangle defines a plane on which the node to be checked for contact can be projected. The process looks like this:
The Contact_Triangle element can be either used on its own by the user, just like an ordinary element, or embedded into another element to provide contact handling by default.
Embedding is a simple way of providing contact handling to your element. One example is the Shell_C0_3 element which uses one Contact_Triangle element. As the indata file is read in the Parse_GID method, a Contact_Triangle instance is created (unless the user has chosen not to). This instance is immediately fed the appropriate input into it's own Parse method, given the thickness of the element (which is also the contact thickness) and the shell elements own nodes.
The only thing remaining now is to run the appropriate methods on the contact element as the various methods of the shell element are run. For example, as the calculateContactForces method is run, the shell element only executes the same method on the embedded contact element. Some elements may require several embedded contact elements and it is up to the programmer to make sure they are all executed in the right manner. Have a look in the Shell_C0_3 element to see how the implementation has been made.
The Contact_Line element is used to detect contacts between line segments. This type of contact is useful in rods, beams and edges of shell or solid elements. It differs a bit from the surface to node contact in that contact checks are only made between line elements and nodes are not involved. This makes the scan somewhat more complicated and also more difficult to get computationally effective.
The algorithm is as follows:
Similar to the Contact_Triangle element, the Contact_Line element has no stiffness and can therefore be embedded in various elements. The element has a contact diameter. Any other contact_Line element coming within this diameter will sense contact.
The Element is the main part of a finite element program. It is here that the program spend about 80% of it's time during calculation, but when it comes to Explicit Finite Element codes, the task that the element should perform is quite simple.
One can say the the task of a finite element is to do the following:
These three tasks are repeated over and over again in a simulation, once for every timestep. If an element has more than one integration point, the process has to be repeated once for every integration point as well. This means that the calculation for an 8-integration point solid element is 8 times longer per timestep, than for an 1-point solid. This is also the reason why some fancy techniques such as hourglass control have been developed to increase speed and allow use of fewer integration points in elements.
If you want to add a new element, the challenge will be to find the formulas you need to calculate the above tasks and then implement them. The framework on how to do this is already within Impact and starts with creating a new element type. It means creating a new sub-class to the Element class. Examples of sub-classes are the Beam_2, Rod_2, Shell_BT_4 and Solid_Iso_6 classes
Each subclass has the same set of methods (which are decided by the Element class), but the coding is very different. We will investigate each method later on in this chapter.
If you want to add a new element type, the easiest way is to pick a type which can use the currently available material laws. At the time of writing the material laws can handle:
The three dimensional stress is used in solid elements while the plane stress is used in shell elements. One dimensional is used in the Rod element.
You can read more about this in the material chapter
The second digit is a group number (ex. rod has 0 and Beam has 1)
The third digit is an index. If there are several different rod types this is used to separate them
Allows you to set or clear that parameter mentioned above.
Roughly, the procedure is as follows:
This is done in the following way:
After each timestep, the nodes will update themselves to see if their closes neighbour has changed.
Start by calculating the local force using stress in rod and cross sectional area
force.set(0, 0,stress.get(0,0)*cross_section_area);
force.set(1, 0, 0);
force.set(2, 0, 0);
global_force = local_coordinate_system.times(force).copy();
node1.addForce(global_force.times(1));
node2.addForce(global_force.times(-1));
xpos1 = node1.getX_pos();
ypos1 = node1.getY_pos();
zpos1 = node1.getZ_pos();
//
xpos2 = node2.getX_pos();
ypos2 = node2.getY_pos();
zpos2 = node2.getZ_pos();
new_length = java.lang.Math.sqrt((xpos2 - xpos1) * (xpos2 - xpos1) +
(ypos2 - ypos1) * (ypos2 - ypos1) + (zpos2 - zpos1) * (zpos2 - zpos1));
The strain increment can now be calculated. Note that his is true strain.
dstrain.set(0,0,Math.log(1+(new_length-initial_length)/initial_length) - strain.get(0,0));
Finally, calculate the cross section area of the rod, assuming incompressible material.
cross_section_area = initial_cross_section_area*initial_length/new_length;
The strain matrix will be updated when the material law is used to calculate the stress.
material.calculateStressOneDimensional(strain,dstrain,stress);
If we look at how the material object is initialised, here is example code:
try {
material = (Material) material.clone();
} catch (CloneNotSupportedException e) {
System.err.println("Object cannot clone");
}
The material object is told to clone itself and the handle is reinitialised
This method simply assigns a number to the element.
local_coordinate_system = new Jama.Matrix(super.calculateLocalBaseVectors(node1.getX_pos(),node1.getY_pos(),no de1.getZ_pos(),node2.getX_pos(),node2.getY_pos(),node2.getZ_pos(),node2.getX_pos ()+1,node2.getY_pos()+1,node2.getZ_pos()+1).getArray());
A material law reflects the behaviour of a certain material. Steel behaves different from clay and so on. To be able to model the material behaviour correctly, a material law is needed. The law "rules" how the stress response should be based on a strain input. Some laws depends on the history of the material i.e. if the material has been stretched before, it may behave differently if one tries to stretch it again. For the material law to reflect this, it needs to have a memory which makes it ideal to make the law into an object which is put inside each element that uses it. You can read more about that under the chapter adding an element.
The material law has only one purpose; To determine the correct stress matrix based on a strain matrix and a strain increment matrix. There are several versions of these matrices where the most general one is of course the three dimensional one. It is used in the hexahedron element for example.
Other versions are plane stress matrix which is used in shell elements and a single one dimensional matrix which is used in a rod element. For the material law to be able to calculate all of these cases, the material law class (which is where the material law code resides), has several methods as can be seen in this figure:
The methods has to be present in all the different material law classes and be called the same for the concept to work.
The material class is the mother class of all the different material laws. This class contain a large amount of abstract methods which are the ones you have to define in your subclass, should you choose to add a new material law. It also contains a few general methods which are usable for all the material subclasses. The methods will be listed in the later subsection.
All the code in Impact is written in such a way that it treats all material laws as just instances of the Material class. This is a well known concept that can be used in object oriented programming. It allows the programmer to extend Impact with new material laws without having to change code in other parts of the program. If you want to add a new material law, you just have to create a new material sub class and fill in the code in the methods that are declared in the mother class as abstract methods.
If you compare the methods in the mother material class and the methods in any of the sub classes, you will see that they are exactly the same apart from the code inside the methods. As an element is created (in a problem that is to be solved), a material object is also created and put inside the element. That material object is an instance of the material law subclass that was chosen for that very element in the problem indata file.
During the simulation, the element will call on the material object over and over again (once every timestep). Basically, the question will be the same, namely "here is my strain matrix. What is my state of stress?" The material law will then do some calculations to find this out and return the stress matrix to the element.
In the picture there are two subclasses defined. The elastic subclass is very simple since it only multiplies the strain with Young's modulus and returns the stress. For two and three dimensions you have some more calculations to do but the concept is the same. The elastoplastic law however is more advanced. The material behaves like in the elastic material law up to the yield stress of the material. After that level is passed, the material starts to behave like plastic material (similar to a gum) and the strain will be irrecoverable. That means that the strain will not go back to zero again should the stress drop, or seen in another way, the stress will not be zero if the strain goes back to zero. This material law has a memory. It remembers if it has passed yield stress before and even remembers the maximum stress level it has reached.
Other more advanced laws that can be added are not only depending on the strain and the loading history, but also the speed at which the material is extended, so called strain velocity hardening. Most steels constitute a significant strain velocity hardening component (up to 25% higher stress level at rapid loading).
Now follows a description of each method in the material law. We will start with the general methods that are defined in the mother class and which are usable for all material classes.
This method will clone the material object i.e. make an identical copy. It is used my the elements to create a local copy to embed inside themselves for the duration of the solution.
This method returns the density of the material
This method returns the name of the material
This is a useful method for getting a number from a string containing several number separated with commas. It is useful in the parsing stage.
Returns the Youngs Modulus of the material.
Returns the number of data points in an indata string by looking at the number of commas used for separation. Used in parsing of indata.
Sets the name of the material object
These methods need to be coded in the subclasses. The coding will be unique for each new material law.
This method calculates a stress given a strain and strain increase since the last timestep. In this case all matrices are assumed to be of the standard 6x1 type.
| Strain | dStrain | Stress |
| Epsilon XX | dEpsilon XX | Stress XX |
| Epsilon YY | dEpsilon YY | Stress YY |
| Epsilon ZZ | dEpsilon ZZ | Stress ZZ |
| Gamma XY | dGamma XY | Stress XY |
| Gamma YZ | dGamma YZ | Stress YZ |
| Gamma ZX | dGamma ZX | Stress ZX |
The stress is given as an input to the method, but is changed inside the method to the return value.
Similar to the above method but for plane stress situation (used by shells)
Similar to the above method but for three dimensional stress (used by all solid elements)
This is the method where the material law object will interpret and set it's indata. The data is taken from the indata file by the Reader object and sent here for interpretation as a string.
To parse this string you can use the methods numberOfPoints and getNumber explained above to sort out the data.
If more indata formats are added in the future, there will be more methods like this to define when you add a new material law
In this method you check that all variables has been read in and set. You also set the ones you need to set before solution starts.
Returns the speed of waves through the material. This is for one dimensional situations and is used by rod elements to determine smallest timestep.
Returns the speed of waves through the material. This is for three dimensional situations and is used by solid elements to determine smallest timestep.
Returns the speed of waves through the material. This is for two dimensional situations and is used by shell elements to determine smallest timestep.
Keep your variables private inside your class to prevent others from fiddling about with them in ways you didn't expect
Read the code. There are plenty of documentation
Go for it! Good luck!
Impact is designed to be able to handle several different indata formats. For explicit finite element solvers, there are currently several different formats available and they are all connected to one of the commercial programmes. Examples are:
These formats all date back some time and has evolved. Recent advances include free format syntax. They all include a large amount of parameters and will require some work to understand. For this reason, Impact comes with it's own indata format, called Fembic (Basic Finite element = FemBic).
The objective of Fembic is that it must be readable and logical in format but most of all, simple! Never the less, impact is designed to be extendable to read the other formats as well and to do this, the reading and parsing of the indata files has been given to the Reader class. The design of this class and how to extend it will now be explained.
The reader class is the mother class for all the different indata file readers. The Fembic format has it's own subclass to the Reader class. Impact is written so that all the code uses the reader class when a data file is to be read and parsed. In reality however, it will be one of the sub-classes that will do the job but it does not matter since the right routines will be run in any case. The benefit is that as a programmer, you do not have to worry about the rest of the program when you change something in your class, or when you add a new class. This is a very nice feature of object oriented programming.
The reader class is an abstract class. It contains very little code. It does also contain several methods which also are abstract and contains no code. They are important to understand however since you have to write each of them in your subclass and fill the method with your code.
Impact assumes that every problem can be described in the following building blocks:
The reader class therefore has methods that reads and interprets these blocks from the indata files. If an indata file is structured differently in any given format, the challenge for the reader class (or rather the specific sub-class) will be to restructure the data to fit into these blocks. They are described a little later.
When you want to add a new reader for a new file format (such as Dyna), you have to create a new sub class to the reader class. As you can see, there is already one called Fembic (for the Fembic file format). In this case we would call it Dyna. Now, you have to fill this class with methods according to the methods defined in the Reader class. Next you have to fill each method with the appropriate code.
As you will see later, you will also need to add methods in the element class, material class, and all their subclasses.
The subclass is initiated by the ModelSmp object. You will also have to modify that class to make it aware of the fact that there is one more file format to select reader for. After initiation, ModelSmp will start by asking the reader about how many of each indata blocks there are.
Knowing the amount of blocks, ModelSmp will then continue to ask the reader for elements, nodes etc as many times as there are definitions in the indata file. ModelSmp will handle the opening and closing of the indata files automatically.
Methods are defined in the Reader class. There are general methods which automatically are inherited to the sub-classes and are useful additions. There are also abstract methods which the programmer has to generate in his/her's subclass and fill with appropriate code, specific for the file format to be read by that sub-class method. A description of each method will now be done:
Scan the file and return the number of constraints that are defined
Scan the file and return the number of controls that are defined
Scan the file and return the number of Elements (of all different types) that are defined
Scan the file and return the number of loads that are defined
Scan the file and return the number of nodes that are defined
Scan the file and return the number of materials that are defined
This method is called from the ModelSmp object. It is called during initialisation of the problem and ModelSmp will start by creating a controlset object. This object is then used as indata to the method.
The method takes the controlset object and feeds it all the control data defined in the indata file. This means reading one or several lines of the indata file. Each line must be parsed and then fed to the object. After completion, there is no need to return anything since the object already was created in the ModelSmp object.
Parameters in the control set are things like start and stop time for the solution. Time step size (or autostep). When to print.... This method is only called once since there can only be one controlset object in a solution.
This method is called several times. One for each known constraint. Each time, a constraint object is created and is then fed with parsed data from the indata file. The parsing is done in this method.
The method assumes that the file already is opened. The reason for this, is that since this method is called several times, it is important that the same constraint is not read twice. The pointer that decides which part to read, is reset when the file is closed, so that cannot happen between each call to the method.
Similar to the other method, it is assumed that the file already is opened. This method is called once for each element that is to be parsed.
Since there are several different types of elements the type of element must be known before creation of the element object. The creation is made in this method and the object is then fed the rest of the indata string defined in the indata file.
Let's illustrate this in an example. The indata file starts with a block header describing a block of elements of type rod. The reader object must now remember this since the coming element will all be of this type. The next line then describes all the data for the first element. The reader creates an element object of the right type and gives the string of the indata to that element object to parse itself.
The element method used to parse the data for a Fembic indata file is called parse_Fembic For another file format, there will be another method in the element.
The problem now is that for each new file format, you have to add a parse method in every element subclass. This means additional work for you apart from writing the reader subclass.
You might ask why this is the case. The reason is that priority has been put to simplify addition of a new element type rather than a new file format. There are much more element types than file formats. Had the parsing of element data been put inside the reader subclass, the element programmer would have been forced to go digging into all the reader subclasses when all he wants is to add a new element. Doing it this way enables him to stay inside his own element subclass with all his work.
There is also another method that has to be added in the element mother class. Selection of an element type based on a name is made in the getElementOfType_Fembic, with a similar reasoning about the name of the method as above.
This method is called once for each load in the indata file. Similar to the other methods it assumes that the file is already opened. It does all the parsing of the load object data itself and feeds them to the object. After completion, the object is returned to ModelSmp.
This method is very similar to the getNextElement method in that there can be several different material types which forces a similar layout when it comes to adding extra methods in the material classes.
This method reads the indata file and creates a node object. The indata is parsed in this method. On thing to remember is that the data for a node includes references to constraints and loads. This means that the node object must be given references to the right constraint and load objects. In order to find those objects, this method has two lists included in the parameters given to the method. These lists are the constraint lists and load lists. They contain the previously defined constrain objects and load objects so that the method can search for the right constraints and loads to give to the node object.
When the definition is finished, the node object is returned to the ModelSmp object where it is inserted into the great node array.
Opens the indata file and sets up some parameters for the parser, such as which characters are to be treated as numbers, words and comments etc.
This is a useful little method which checks a given word to see if it is a defined keyword. It is used during parsing to figure out if a new block has been reached in the indata file. The keywords are file format specific and are stored in an array called keywords[]. It is defined directly under each subclass.
Closes the indata file.
Impact is designed to be able to write result data in various formats. There are several different post-processors available to view this result data and the default one for Impact is GID.
To enable writing of data, a writer object is used. The object is initiated as soon as the indata file is read because it is the indata file that decides which format to print in. If nothing is specified, the GID writer object is used.
The writer class is the mother class for all the different writers. Similar to the Reader class, it mainly contains abstract methods and a few general methods for the subclasses to use. They will be described later.
Adding a new output format means adding a new subclass to the writer class. This subclass has the task of structuring and directing the output. It works by calling the elements and nodes (which contain the results) and asks them to print their data one by one. The whole "orchestration" of this procedure is done by an object initiated from this subclass.
At the time of writing, there is only one subclass, called GidWriter. The main method for this class is the write method which is used by the ModelSmp object to order printing of results. During the simulation, this method will be called several times since explicit programs dump their results frequently during simulation. We will go through this method in detail in the next part.
The data we want to print is all contained inside element and node objects. To make matter worse, the data is also encapsulated inside these objects in private variables, making them unreachable from our GidWriter object. The way to print this data is then to ask the elements to print it. But how does the element know which format to print the results in? The output can look very different from format to format.
The solution is to create a unique printing method for each output format. For each new output format added to Impact, it will mean that each element sub-class will have to add one more print method. (The node class already has methods which provides the results data). This approach makes it "messy" to add new output formats since the programmer has to add code in other classes than the writer and writer sub-classes, but since the amount of output formats are far less than amount of element types, this seems to be the most rational approach.
We will soon have a look at what the extra methods in the element classes will mean.
When this method is called, it is time to write the output data from the solution. The implementation of this method in the GidWriter looks as follows:
public void write(String fname, double currtime) {
filename = new String(fname);
time = currtime;
try {
if (counter == 0) {
writeMesh();
}
writeResult();
counter++;
} catch (IOException ioe) {
System.out.println(ioe);
return;
}
}
Two private methods are used here, writeMesh and writeResult. They are the ones doing the main job. The first time the write method is called, some mesh data is written through the writeMesh method in addition to some results. The following times, no more mesh data is written. This is what the GID post-processor wants as input so that is what we must write.
This is a private method. It may only exist for the GidWriter class but I will explain what it does in any case to give a good feeling for this concept.
The method basically gets information from the node objects by asking them for their position in space and then formatting this information to print a mesh data file in the correct format. It can ask the nodes directly since there are general methods for all the data in the node.
It also asks the elements to print all their data about which nodes each element is connected to. This is data that each element object knows, but it is private data. Have a look at this line of code:
bw.write(temp_element.print_Gid(Element.MESH, 0)
Here, the element is asked to print the data using a special control code (Element.MESH). In other cases, the element may be asked to print something else and then another control code will be used. The resulting string of data is then directly written to the file (bw).
The principle used in this method is the same. Each element is asked to print it's data but by using a control code, the data printed by the element may differ according to need. You can find the details in the code itself.
Each element must contain a method to print it's data. The name of this method is standardised to print_name where name is the name of the output format.
The method should access the data in the element and create an output string which will be printed by the writer object. The request from the writer may differ depending on situation and therefore a control code must also be sent which the method must follow to do the right thing
The second parameter is the gauss point number of the element. Since each element will contain at least one Gauss point and the results are stored there, printing will be made for each gauss point. This parameter specifies which gauss point to read and print.
Naturally, the implementation of this method will differ from element type to type which is why each element type needs this method. Remember now when you write a new output format to go through each element sub-class and add this method.
The results generated by the simulation cannot always be presented in the right way. Sometimes there is a need to "measure" the movement or force on a single node for example and this is where trackers come in handy. The measured results can be calculated upon and the written to a data file specified by the user.
There are a range of trackers available:
If you want to add a new tracker, the framework on how to do this is already within Impact and starts with creating a new tracker type. It means creating a new sub-class to the Tracker class. Examples of sub-classes are the NodeForceTracker or SectionForceTracker classes
Each subclass has the same set of methods (which are decided by the Tracker class), but the coding is very different. We will investigate each method later on in this chapter.
If you want to add a new tracker type, the easiest way is to pick a similar type which already reads the kind of data you are interested in and modify it.
The Tracker class is the mother class for all the different tracker types. This class does not actually contain any code, apart from a number of general methods which can be used by the sub-classes. The rest of the methods are abstract methods. This means that they act as a framework for the subclasses and if you don't include each of the methods in your sub-class, you will get an error when compiling.
The rest of Impact relies on that your new sub-class has code for each of these methods. If you don't, you will not be able to solve problems with your tracker.
Creating a sub-class is simple, but you should give it a proper name. If you look at the names currently defined, they reflect what the tracker does, for example nodeforce etc.
When you create a new sub-class you must update the list of trackers in the getTrackerOfType_Fembic method and if more file formats exists also in these related methods.
The Methods in the tracker class are either Abstract or General. General means that they are supposed to be used by all the tracker sub-classes, but the coding resides in the tracker class since it does not change from sub-class to sub-class.
The general methods are automatically inherited and can be used by all sub-classes. Here follows a description:
This method is used by the reader class to generate trackers based on how they are described in the indata file. The reason for putting this method here and not in the reader class is once again to keep all the related work of adding an tracker type, strictly within the tracker class. Therefore, the reader will use this method to determine which tracker object to generate.
The_Fembic part of the name is related to the fact that the Fembic type indata format is assumed. If a new indata file format is added, i.e. a new reader sub-class is written, an extra method will be required here, which is tailored to that file format.
This method searches the database and returns a handle to the node object with a specific number. It is used by the parse method in the tracker sub-classes to interpret tracker indata.
This is quite a useful method. When you have a string with a range of numbers that are separated by commas, this method picks the n:th number in this string, converts it into an integer and returns it. It can be useful when reading indata and is used by the tracker sub-classes in their parse method.
The Abstract methods are empty in coding in the tracker class. This is because every sub-class has a different implementation of these methods. As a programmer that wishes to add a new tracker sub-class, these methods are the ones that he/she has to write. Here follows a description of each method
This method is run by ModelSmp (the master class that runs the simulation) to order the tracker to ask around and collect all the needed data from the nodes or elements that it wants to measure.
The measured data is here calculated to get the resultdata for the tracker. This is usually the "heart" of the tracker.
This method is used to check that all the necessary data has been given to the tracker from the indata file and that the numbers given are accurate.
This method simply returns the number of the tracker. This number is the one that was defined for the tracker in the indata file.
As described before, some of the interpretation of indata files has been put into the tracker itself. This method is called when a Fembic indata file is read and the indata for the tracker needs to be read and interpreted.
The beauty with this approach is that the tracker can read the indata string and set all its variables by itself. The variables can then be kept private and encapsuled inside the tracker.
Another benefit is that the programmer only needs to work in this class when he/she adds a new tracker. There is no need to fiddle around elsewhere in impact.
When a new file format is added, a new additional method is required for this file format and the programmer needs to add this new method to all tracker types in impact.
This method is the opposite of the parse_Fembic method described above. It creates an output string which is then printed into the outdata file. This very method prints the outdata from the tracker in GID format. GID is a pre- and postprocessor which is free and a good complement to Impact.
This method is called every time the TrackWriter object wants to print something, but there could be different things from time to time like header data or bulk data. A control parameter is supplied with the call to signal what is to be printed.
This is the initialisation method for the tracker and it is called once at the beginning of the solution.
This method is simply used to assign the number to the tracker.
Have a good look at the coding of the NodeForce and the SectionForce tracker. The code is full of comments. Good luck!
Impact is designed to be able to write result data in various formats. There are several different post-processors available to view this result data and the default one for Impact is GID.
To enable writing of tracker data, a trackwriter object is used. The object is initiated as soon as the indata file is read because it is the indata file that decides which format to print in. If nothing is specified, the GID trackwriter object is used.
The trackwriter class is the mother class for all the different trackwriters. Similar to the Reader class, it mainly contains abstract methods and a few general methods for the subclasses to use. They will be described later.
Adding a new output format means adding a new subclass to the trackwriter class. This subclass has the task of structuring and directing the output. It works by calling the different trackers, asking them to collect and calculate the results and finally to print their data one by one. The whole "orchestration" of this procedure is done by an object initiated from this subclass.
At the time of writing, there is only one subclass, called Gidtrackwriter. The main method for this class is the write method which is used by the ModelSmp object to order printing of results. During the simulation, this method will be called several times since explicit programs dump their results frequently during simulation. We will go through this method in detail in the next part.
The data we want to print is all contained inside tracker objects. To make matter worse, the data is also encapsulated inside these objects in private variables, making them unreachable from our Gidtrackwriter object. The way to print this data is then to ask the trackers to print it. But how does the tracker know which format to print the results in? The output can look very different from format to format.
The solution is to create a unique printing method for each output format. For each new output format added to Impact, it will mean that each tracker sub-class will have to add one more print method. This approach makes it "messy" to add new output formats since the programmer has to add code in other classes than the trackwriter and trackwriter sub-classes, but since the amount of output formats are far less than amount of tracker types, this seems to be the most rational approach.
Remember that as you add a new trackwriter type, you must add that type to the trackwriter getTrackWriterOfType_xxxx method(s).
When this method is called, it is time to write the output data from the solution. The Gidtrackwriter just asks each tracker in turn to write it's result through the use of the writeResult method.
As of version 0.5.3, Impact supports calculations performed across a networked set of clients often referred to as a cluster. This allows Impact to split up a model into smaller parts and distribute them over the network, letting a client calculate only a unique section of the model and thereby speeding up the calculation. There is no need to have a special type of network although a capacity of 100Mbit or greater is preferrable. This is standard today on most PC:s.
The network communication and synchronisation is a complex topic. Therefore, Impact uses a special software to handle all this, called JavaParty. Developed by the University of Karlsruhe this software is 100%PC% java in itself which means no further dependencies. Furthermore, JavaParty assumes there is a way to connect from one client to another without a password. Default setup uses ssh (secure shell) login and how to set this up correctly is explained at the JavaParty webpage. A link to JavaParty as well as downloads is avalilable on the Impact webpage
Impact assumes that your directory is shared across the clients in the network. This is the most common setup on a LAN and is accomplished by NFS or similar. If this is not the case, you have to arrange this with the system administrator. Reason for this assumption is that the printout of the results become significantly simpler to implement since all the clients can access the same file.
In a typical finite element simulation, approximately 80%PC% of the CPU resource is spent on figuring out the nodal forces as a result of the element geometry, material attributes and contact situation. The remaining 20%PC% are mainly spent calculating the node displacements and sorting them. Since the nodal forces are easy to communicate and of limited size, the first 80%PC% have been parallized and the nodal forces are communicated across the network at every time step.
Since the nodes are the connection points for elements, most nodes will recieve force contributions from several elements. If these elements are placed on different machines, how does the communication know where to transmit the forces? The solution chosen for Impact is quite simple. Each client broadcasts the forces it has calculated onto the net. The other clients listens and picks up the force if applicable. This means that for each time step, there is a separate broadcast from each client.
Each client holds a complete model with all the nodes and every node is kept updated with regards to position, velocity etc separately on each client. The elements however are distributed which means that on each client, only some of the elements are calculated and kept updated. When printing of element results are made, each client in turn prints data from the elements that are kept updated there. A complete copy of the nodes are calculated locally on each client. This simplifies contact search since the algorithm scans the nodes around the area of contact to determine the result. If the nodes are distributed together with the elements, this becomes much more complex.
The change required to implement the cluster version has been limited. The main class is called ModelCluster and one object instance is created for each client in the cluster. These will then run in parallel but synchronized. The solution loop looks very similar to the SMP version but with extra steps included where the nodal force data is exchanged as well as synchronized.
Additionally, there are separate startup scripts for the SMP version as well as the cluster version. Main modifications has also been made in the printing where a print_parallel method has been added.
If you want to examine the code, a good place to start would be the Impact.java file This is where the solution is started, the separate instances created and executed. You can then follow the code from there.