Engineering Computing: Mixing Knowledge Transfer, Programming, and Numerics

Case Study: Model Reduction

Evgenii B. Rudnyi, February 2009, (c) All rights reserved

Some time ago when the term scientific computing was coined, I thought that this could describe well what I do: some mixture between science, programming and practical applications. However, now scientific computing is considered basically as extended numerical analysis. I do use it in my work, yet as a practitioner. My work as such is different and I would refer to it as engineering computing. I believe that the best way to explain what I mean is to give an example.

I have been doing a research on model order reduction for the last 7 years: A certain number of publications have been produced: a book, book chapters, some journal papers, and a lot of conference papers. However, it is not that easy to say what a scientific contribution actually has been made. It was definitely not a contribution to the theory of model reduction, neither to theory in programming or numerics. In order to answer this question let me start with the fact that at the end of the research it was possible to earn a bit of money. This sounds not too scientific but it could be interesting to analyze why. Some answer is considered below. First I will consider different skills (knowledge transfer, programming and numerics), combination of which in my view was essential for the success. Then I will be back to engineering computing.

Knowledge Transfer

When a new theory is developed, it is usually possible to find practical application. This sounds simple but in practice it requires interdisciplinary thinking. My story here is as follows. In 2001 I have started working on an EU project where it was necessary to develop compact thermal models. A typical way among thermal engineers to do it was to build a thermal network and then to find its parameters by optimization. By that time a group of mathematicians has already developed a new theory: Approximation of large scale dynamical systems. However this knowledge has not reached engineers developing compact thermal models.

I am a chemist by background and was trained to start a new research by thorough literature search. A multidisciplinary search has quickly revealed the situation above and it was evident that this concerns not only thermal engineers but rather the whole finite element community. There was a new theory developed by mathematicians but the knowledge about that has not reached yet the potential audience. As a result, research in this direction has been started and a number of publications have been produced. It was shown that the theory is working perfectly for many different finite element models and a methodology on how this can be used in practice was developed for a number of different applications.

The statement above sounds pretty trivial. Yet, I could cite recent papers in this area where one can easily observe that researches often skip literature multidisciplinary search.


In the case described above, the knowledge transfer is only possible in the form of software. Nowadays it is useless to show engineers a new mathematical theory without software implementation. The next decisions seemed to have been crucial:

1) ANSYS has been chosen as the application target,

2) Compiled programming language (C++) has been chosen as the programming language,

3) Available free numerical libraries have formed the computational framework.

I would say that these decisions have not been chosen consciously from the beginning but rather it just happened this way. Points 2 and 3 were based on my previous knowledge and point 1 was due to the fact that our partners have been using ANSYS. Yet, when I look back now, I believe that fortunately these were the right decisions.

I will comment on point 3 in the next section on numerics. Below are just a couple of comments on points 1 and 2.

Alternative to point 1 would be in-house discretization or the use of other commercial software. Some groups have researched on model reduction with models discretized by in-house software indeed. No doubt, it is enough for research but it should be also evident that commercialization along this way is impossible.

The advantages of ANSYS happened to be twofold: a reasonably good documentation on how to extract system matrices, and availability of wide range of finite element problems (multiphysics).

As an alternative to point 2, I have not meant other compiled programming languages like C and Fortran. What to use C++, C or Fortran is a matter of taste. I love C++ but I do not insist that it is the best programming language. What have been meant are the environments for fast prototyping like MATLAB and Mathematica. They are good for research, but not for commercialization.


Model reduction can be also considered as a numerical method and its implementation in turn uses other numerical methods, the most important being a solution of a linear algebraic system. As such, numerical methods were very important for the overall progress. However, in my work it was unnecessary to develop new methods; the practical problem was more the use of already developed methods and the integration of available libraries.

Our task was to solve real life finite elements problems and this implied the level up to one million degrees of freedom. It was necessary to compare different libraries, to choose the most appropriate that could deal with such a dimension effectively and then integrate them in the code. It is again sounds simple and not scientific. It is more about hacking - see for example my instructions on how to compile free numerical libraries at However, the code was initially distributed under the GNU license but only few individuals were able to compile and link the code. For majority people working in this area such an assignment happened to be out of reach.

Engineering Computing

All points above are trivial provided they are taken independently. If however they are considered together, then I believe that the complexity already reaches a certain level and it is time to introduce a new discipline.

When I have started in 2001 working on model reduction, I have already had good background in scientific research, reasonably good experience in programming and knowledge of numerical methods. I believe that this was the key for the success.

The development of software was very important. After the first very rudimentary version was available, the rest was relatively easy. Do you use ANSYS? Do you need compact models? Do you want to try it with our software? This led to the collaboration with many groups in academia and industry and in turn brought back the knowledge of real life needs. This information in turn led to the further development of the software.

Engineering computing, as introduced in this document, is actually similar to scientific computing. The difference is in the goal. While scientific computing pursues theoretical research, engineering computing pursues practical results.

Let me conclude by a statement about the papers made during my research on model reduction. They are not at the Nature level but if one looks in the World of Science then one sees, the papers are cited and have made some impact. And once more, they have allowed me to earn a bit of money.


Louis Komzsik, Re: Engineering Computing: Model Reduction case study, 2 Mar 2009

The discussion with Louis Komzsik at Simulation Driven Engineering by LinkedIn (you have to be a member of LinkedIn)

Discussion at Computational Scientists & Engineers group by LinkedIn (you have to be a member of LinkedIn)