Fundamentals of N-Dimensional Lookup Tables in Twin Activate
Altair EmployeeTwin Activate is a block diagram simulation environment for modeling dynamic systems. It features several blocks that approximate non-linear functions using lookup tables, which are often useful in systems modeling.
In this short guide, I want to show how N-dimensional lookup tables blocks should be used in Twin Activate for approximating functions using interpolation on multidimensional data sets. I also want to highlight differences between the available blocks.
Consider this example block diagram with all options for using a 3D lookup table in those blocks:
I’ve used SetSignal and GetSignal blocks to avoid clutter. All lookup table blocks get the same inputs and are connected to the scope block on the right. The image shows three variants of the ND lookup table block:
- LookupTableND: Takes dimension ranges and table data directly as parameters.
- LookupTableND_file: Reads dimension ranges and table data from a .mat file.
- LookupTableND_port: Reads dimension ranges and table data from its additional input ports (U1, U2, U3 and Y).
Arguably, the only thing that might be complex about using these blocks is defining the table data in the correct order. It must be defined as a row-vector containing the output for each possible input combination.
Consider the 3D lookup table that has been defined with two values for its first dimension, [x1 x2], three values for its second dimension [y1 y2 y3] and four values for its third dimension [z1 z2 z3 z4]. The elements must be arranged in a specific pattern covering all possible values for the first dimension, then for the second dimension, and so on. I’ll illustrate how this is done with a diagram:
For declaring the table data correctly:
- First vary x (x1,x2) for fixed y1,z1
- Then increment y and repeat x variation for y2,z1
- Finally increment z and repeat the whole pattern
This would result in the table data row vector TD = [x1y1z1, x2y1z1, x1y2z1, x2y2z1, x1y3z1, x2y3z1, ..., x1y3z4, x2y3z4].
All this can be done from the initialization script. Look at this script, which is self-explanatory apart from the two first lines, which clear the session from previous plots, variables and command line clutter and set the current directory to the model file’s location, to ensure access to the .mat file created:
While variables rU1, rU2, rU3 and TD are used for LookupTableND and LookupTableND_port (given as inputs from constant blocks), LookupTableND_file reads those variables from tableFile.mat.
With this example, it becomes clear that the normal version is the simplest, but when testing out many different tables, it might be more practical to read from an external .mat file. The port version, on the other hand, might be useful for changing the data itself in the middle of a simulation.
I’ve attached the model here, so you can test on your own. You should get identical results from each block:
Download the model and test on your own functions so you can leverage lookup tables and apply this to your use case.