| Previous | TableOfContents | Next |
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 smack (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!
| Previous | TableOfContents | Next |