| Previous | TableOfContents | Next |
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 Smack 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, Smack will start by asking the reader about how many of each indata blocks there are.
Knowing the amount of blocks, Smack will then continue to ask the reader for elements, nodes etc as many times as there are definitions in the indata file. Smack 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 Smack object. It is called during initialisation of the problem and Smack 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 smack 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 Smack.
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 smack 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.
| Previous | TableOfContents | Next |