MORLAB -- A Model Order Reduction Framework in MATLAB & Octave
Benner, Peter
Werner, Steffen W. R.
When synthesizing feedback controllers for large-scale dynamical systems, often a reduction of the plant model by model order reduction is required. This is a typical task in computer-aided control system design environments. Therefore, in the last years, model order reduction became an essential tool for the practical use of mathematical models in engineering processes. For the integration of established model order reduction methods into those processes, software solutions are needed. In this talk, we describe the MORLAB (Model Order Reduction LABoratory) toolbox as such a software solution in MathWorks MATLAB(R) and GNU Octave, and its featured integration into established software tools used in simulations and controller design.
 Hi, I'm Stefan Werner, a PhD student from the Max Planck Institute in Magdeburg, working in the fields of numerical linear algebra and model order reduction. In my talk, I'm going to give you a basic overview on the programming and design principles of the Moorlap toolbox. In America, the software solution we are developing at our institute for the purpose of model order reduction. This will be the basic outline of this talk, so I will start with the general model order reduction problem to give you a little bit more background and why we actually need software for this problem. Then we'll continue with an overview on the Moorlap toolbox before going into details on the toolbox design and its integration into MATLAB and Octave. So let's directly start with some problem of model order reduction. And therefore, I brought you a reword example. This is actually a project from the University in Kiel, where the task is to design and control an underwater drone which is shaped like a fish. The outcome is a so-called artificial fishtail model describing the mechanical properties of the structure you can see here on the left. This is basically a fish without the head and the fin. And on the right, you can see the actuation principle, so how an underwater drone which has this fishtail as its basic body is supposed to move. In the un-pressurized state, the fishtail is just straight. And otherwise, you see here, we have left and right chambers in the fishtail. One of those chambers should be pressurized, such as the fishtail is then bending to one side. And the idea is to let the pressure then flow from one chamber to the other, such that the fishtail is bending to one side and then the other side, such that the flapping behavior is happening like a real fish would actually swim in practice. From the mathematical side, this artificial fishtail is described by partial differential equations. And usually, and using modeling tools like measuring and finding elements to do afterwards computations with the model, we end up with such a system of second-order ordinary differential equations describing the discretized physics. This type of system is actually called an input-output system because of the three time-dependent quantities we have in here. First of all, here on the left, we have the inputs. The external forces that we can apply from the outside to somehow influence the internal behavior of the system. In terms of the fishtail, that would be the change of the pressure. Then we have x, the discretized states. Those are describing the physics of the system, and we have y, the outputs. So the quantities of interest that we can actually measure on the outside of the system. For the fishtail, that would be again a sensor at the tip of it, which is measuring the displacement. So how much are we going away from starting position in all three spatial dimensions? Down here, you can see the resulting dimensions of the system. So we have only one input because we only can influence this change of pressure. We have three outputs, the three spatial dimensions the sensor is measuring. And due to the complicated geometry of this artificial fishtail, we have around 780,000 differential equations describing the discretized physics. Now, since we want to control our fishtail, let's do a time simulation with it. That's what you can see down here. So we are applying an input for SU. This is just chosen such as the fishtail is making a turn. And down here, you can see what the sensor at the tip is measuring. So you can really see this flapping behavior of the fishtail, like it's swimming. But now we are running into a problem. This simulation is going over two seconds, but actually we needed four hours of computation time to do this simulation. So we're still having a mind we want to do real-time control of our fishtail at the end. That's completely impossible. The problem arises due to the 780,000 of differential equations we have to solve for this simulation. So in principle, the demand for computational resources here definitely it's time, but also in terms of memory, it's unbearable in practice. So we have the need for a software solution to automatically simplify those dynamic systems in the sense that we give the matrices that are describing the system to the software and then it's in a certain way coming up with a simpler description. Because at the end, we are only interested in the input to output behavior of the system. How internal physics are described, we don't need to care. So there might be an easier description instead of those 780,000 of equations that we could come up with. In a little bit broader setting, we have here on the left side, the rewrite applications that are then modeled by partial differential equations. And after discretizing, we have our input output systems that are then used for simulations and controller design. And usually in practice, those systems become very large. Such that we have a big demand for time and memory when we are performing simulations and controller design and to reduce those demands, model order reduction is one solution. Also having a mind that the surrounding things are actually this lifecycle of systems engineering that is already implemented by software tools, we need a model reduction software that fits right into this lifecycle. A little bit more concrete, what is the model reduction problem? So we have the original system, which is described by many differential equations, making the system very difficult to evaluate, so expensive in terms of time and memory, thinking of the computer. And then by model order reduction, we want to construct somehow a smaller system that is described by only a few differential equations now. So it's way cheaper to evaluate the reduced order model than the original one. Of course, we cannot take any arbitrarily small system, but applying the same input signal U to the systems, the outputs y of the original system and y hat of our approximation should be close to each other. Such that in practice, we could then replace the difficult to evaluate original system by the easy and cheap to evaluate reduced order model. Looking back to our first table, we had this mechanical system structure described by the matrices MeK, BU, NCP. Down here you can see again the dimensions of the system. Remember N was the number of differential equations describing it, so those 780,000s. And now we want to apply model reduction to it such that we get a new system described by those head matrices, which are much smaller than the original ones. So those head matrices are now of dimension r, so we only have r differential equations describing the system. And one software solution that we are developing for this purpose is the Moorlap toolbox. Moorlap actually stands for model order reduction laboratory. So it's a model reduction toolbox in MATLAB originally and nowadays also an octave based on spectral projection methods. A little bit about history, it's already a quite old project. The first release was in 2006 with 1.0, having three model order reductions for standard methods and a few basic matrix equations. So it was for the standalone version. And then after some development time and only internal releases, version 3.0 was released in 2017, 4.0 in 2018, and the latest version is now 5.0 in 2019. The current version of the toolbox has now 10 model reduction methods for a lot of different types of systems like the standard systems were all started, but also the script or in second order systems in the continuous and discrete time setting. And it's coming with advanced system theoretic subroutines, for example, for the evaluation of the system afterwards, and also with underlying matrix equation solvers for the implementation of the toolbox. During all this time, actually a lot of people have already contributed to the code. So you can see here me as the current core developer of the toolbox, Professor Peter Wenner from the Max Planck Institute as the overall copyright holder. And then we have a lot of people that contributed from the MPI in Markterburg, but also from the Otto von Gerich University in Markterburg for the software. So a small feature checklist for our toolbox. First of all, it's open source and free. You can just download it for free for testing from the project website or from Cenodo and it's licensed under the GNU or Farrish General Public License version 3. It's fast and accurate due to the underlying structure of projection methods we are using for the implementation. Usually we can outperform other established software model reduction software tools in terms of accuracy and speed. We have a unified framework, meaning that all model reduction methods belonging to the same class of systems share exactly the same interface such that they can easily exchange and it's very easy to learn how those methods are working. The toolbox is modular in itself, meaning we not only provide access to the top level model reduction routines, which is the main purpose of the toolbox, but also to all the underlying routines which are building up the model reduction methods such that the user can build up their own methods afterwards. Also it's portable by currently using no binary extensions and also it's only the main dependencies are the basic MATLAB version from 2012 or the corresponding version in October. So now I want to talk a little bit more detail about the toolbox design and its integration into MATLAB and October. And therefore first talk a little bit about MATLAB. MATLAB is a multi-paradigm programming language and at the same time, the proprietary IDE that is interpreting this programming language. The main purpose of MATLAB are numerical computations with matrices and its extensions to a lot of different application areas comes from its toolbox design. So there's the basic MATLAB version, but surrounding it, for example, for systems engineering, there are a lot of toolboxes that can be installed for it. In the sense of systems engineering, one should be heard of the Simulink toolbox, the control system toolbox or the robust control toolbox that are the main contribution when working with dynamic assistance there. The nice thing about MATLAB is they also allow for the users to define their own MATLAB toolbox system, which is a very easy way to chip the code, install it for the user and to also implement certain type of documentation for it. Having this design of toolboxes and those already existing ones which are giving us predefined data structures, objects and routines in mind, we came up with certain goals and software design of our toolbox. So first of all, it should be intuitive to handle with having their actual applications of engineers in mind, it should be very easy for them to directly apply the model reduction methods without actually knowing how those model reduction methods are supposed to work. They should be fully customizable, so with going more into detail, the user should be able to change the behavior of the routines without rewriting the code. Also, it should be compatible with all the other established main software out there. Additionally, Octave is one open source and free alternative to MATLAB and to also have our toolbox accessible for everyone that are not used, also for people that are not using the proprietary version of MATLAB, we are trying to be completely compatible with Octave. So to fulfill our design goals of more lab, we decided to design our toolbox in an object oriented way and our main object are those input output systems. And now inheriting from those, we have developed the methods for different type of system classes. The first one that was implemented are standard systems, as you can see it over here. So just the first order of differential equations describing the internal dynamics and the algebraic output equation. And those type of systems are fully supported by the main MATLAB toolboxes, by the so called state space object. So for the integration of more of into those toolboxes, we provide an interface for the state space object, but also have our own interface to be independent of those toolboxes using structs or on the other hand, just pure matrices that are defining the system. Then we have descriptor systems where we have now originally this E matrix in front of the derivative. This type is partially supported by the current main MATLAB toolboxes. The problem for those are actually noninvertible E matrices corresponding to algebraic constraints for the system. But we are, but they are still supporting to have an E matrix. So we also have an interface for that, but we have support more reduction methods that can also handle singular E matrices by using also interfaces with structs and the single matrices and thinking back of our first time model, more of this implementing model reduction methods for mechanical systems of this type. This is currently not supported in MATLAB, but more of this still giving interfaces for the structure version or just the single matrices. Having this in mind, the basic function called a more lab look taxes. So MLCTDSSBT is a more lab function here for continuous time descriptor state space systems with the balanced function method where we are giving the system. So basically an object with the matrices that are defining our differential equations and the algebraic output equation. We have the options, so the way of the user to customize the behavior of the routine from the top level down. Then the routine itself is generating the reduced order model consistent in the data type with what the user used to give the data to the method. And it's also giving some info about the performance of the method. So of the underlying solvers of for example, if the method is providing an error bound for the approximation error we are doing, this will be given back. So then the integration of the two books might look like this. We have on the left side, the preprocessing, so stuff that happened in the design cycle before, which are generating actually the inputs of our system. Then we have our here at TI system blocks, this is taken from the simulink two books. So basically our dynamical system, which is simulated for those given inputs to generate certain outputs, which are then used for post processing steps. Usually this type of system block is realized and muddled up by the state space object. So we can just take the state space object out of this whole framework that the engineer designed, apply the model to work on the state space object. This is defining our original system, which gives us then the reduced order model. This reduced order model is consistent in data type of the original system. So again, a state space object, so we can directly just replace the original system by the reduced order model. And we only touched this one system block in here. So we didn't do anything with the post or the preprocessing for the integration of more lab here. So now let's take a look back on the artificial fishtail. Remember the original system had this mechanical system structure and those 780,000 differential equations describing the internal dynamics, which led to those four hours of computation time for the two seconds simulation. And now we apply a pre-reduction approach plus the routines that we have implemented in the model box to it. And at the end, we get reduced order model, which is of order one. So described by a single second order differential equation to compute this model, it took actually 21 hours. So compared with the simulation at the time, definitely reasonable. And now using the reduced order model as replacement for the original for the two seconds simulation, it just takes 0.06 seconds. So we are around 240,000 times faster with our reduced order model than with the original one. And if you look down here, the reduced order model is perfectly matching the original system in this input to output behavior. So in practice, the reduced order model would be the way to go to real-time control of underwater drones that are based on the artificial fishtail model. With this, I'm basically at the end of my talk. So I just want to summarize again. MOLAP is a model reduction framework in MATLAB and NORCTAF, where we have the design principles based on the underlying applications. We have used an object-oriented programming approach with the system classes as the main objects in behind. And it's compatible and integrable with our established software standards. Also it's open source and modular. And we are not yet at the end of development of our toolbox. So for planned future work, we have, for example, our system classes that we would like to implement with time delays, nonlinearities, further model reduction methods for the system classes we currently have implemented, there are way more out there for our subroutines to support further work in OCTAF, which is actually missing all those nice standard toolboxes that MATLAB has for the implementation. And also we are planning a high performance variant by using highly parallelized binary extensions to make the model reduction methods even more efficient. Now, I'm at the end of my talk.
 Hi, I'm Stefan Werner, a PhD student from the Max Planck Institute in Magdeburg, working  in the fields of numerical linear algebra and model order reduction.  In my talk, I'm going to give you a basic overview on the programming and design principles  of the Moorlap toolbox.  In America, the software solution we are developing at our institute for the purpose  of model order reduction.  This will be the basic outline of this talk, so I will start with the general model order  reduction problem to give you a little bit more background and why we actually need software  for this problem.  Then we'll continue with an overview on the Moorlap toolbox before going into details  on the toolbox design and its integration into MATLAB and Octave.  So let's directly start with some problem of model order reduction.  And therefore, I brought you a reword example.  This is actually a project from the University in Kiel, where the task is to design and control  an underwater drone which is shaped like a fish.  The outcome is a so-called artificial fishtail model describing the mechanical properties  of the structure you can see here on the left.  This is basically a fish without the head and the fin.  And on the right, you can see the actuation principle, so how an underwater drone which  has this fishtail as its basic body is supposed to move.  In the un-pressurized state, the fishtail is just straight.  And otherwise, you see here, we have left and right chambers in the fishtail.  One of those chambers should be pressurized, such as the fishtail is then bending to one  side.  And the idea is to let the pressure then flow from one chamber to the other, such that the  fishtail is bending to one side and then the other side, such that the flapping behavior  is happening like a real fish would actually swim in practice.  From the mathematical side, this artificial fishtail is described by partial differential  equations.  And usually, and using modeling tools like measuring and finding elements to do afterwards  computations with the model, we end up with such a system of second-order ordinary differential  equations describing the discretized physics.  This type of system is actually called an input-output system because of the three time-dependent  quantities we have in here.  First of all, here on the left, we have the inputs.  The external forces that we can apply from the outside to somehow influence the internal  behavior of the system.  In terms of the fishtail, that would be the change of the pressure.  Then we have x, the discretized states.  Those are describing the physics of the system, and we have y, the outputs.  So the quantities of interest that we can actually measure on the outside of the system.  For the fishtail, that would be again a sensor at the tip of it, which is measuring the displacement.  So how much are we going away from starting position in all three spatial dimensions?  Down here, you can see the resulting dimensions of the system.  So we have only one input because we only can influence this change of pressure.  We have three outputs, the three spatial dimensions the sensor is measuring.  And due to the complicated geometry of this artificial fishtail, we have around 780,000  differential equations describing the discretized physics.  Now, since we want to control our fishtail, let's do a time simulation with it.  That's what you can see down here.  So we are applying an input for SU.  This is just chosen such as the fishtail is making a turn.  And down here, you can see what the sensor at the tip is measuring.  So you can really see this flapping behavior of the fishtail, like it's swimming.  But now we are running into a problem.  This simulation is going over two seconds, but actually we needed four hours of computation  time to do this simulation.  So we're still having a mind we want to do real-time control of our fishtail at the  end.  That's completely impossible.  The problem arises due to the 780,000 of differential equations we have to solve for this simulation.  So in principle, the demand for computational resources here definitely it's time, but also  in terms of memory, it's unbearable in practice.  So we have the need for a software solution to automatically simplify those dynamic systems  in the sense that we give the matrices that are describing the system to the software  and then it's in a certain way coming up with a simpler description.  Because at the end, we are only interested in the input to output behavior of the system.  How internal physics are described, we don't need to care.  So there might be an easier description instead of those 780,000 of equations that we could  come up with.  In a little bit broader setting, we have here on the left side, the rewrite applications  that are then modeled by partial differential equations.  And after discretizing, we have our input output systems that are then used for simulations  and controller design.  And usually in practice, those systems become very large.  Such that we have a big demand for time and memory when we are performing simulations and  controller design and to reduce those demands, model order reduction is one solution.  Also having a mind that the surrounding things are actually this lifecycle of systems engineering  that is already implemented by software tools, we need a model reduction software that fits  right into this lifecycle.  A little bit more concrete, what is the model reduction problem?  So we have the original system, which is described by many differential equations, making the  system very difficult to evaluate, so expensive in terms of time and memory, thinking of the  computer.  And then by model order reduction, we want to construct somehow a smaller system that  is described by only a few differential equations now.  So it's way cheaper to evaluate the reduced order model than the original one.  Of course, we cannot take any arbitrarily small system, but applying the same input  signal U to the systems, the outputs y of the original system and y hat of our approximation  should be close to each other.  Such that in practice, we could then replace the difficult to evaluate original system  by the easy and cheap to evaluate reduced order model.  Looking back to our first table, we had this mechanical system structure described by the  matrices MeK, BU, NCP.  Down here you can see again the dimensions of the system.  Remember N was the number of differential equations describing it, so those 780,000s.  And now we want to apply model reduction to it such that we get a new system described  by those head matrices, which are much smaller than the original ones.  So those head matrices are now of dimension r, so we only have r differential equations  describing the system.  And one software solution that we are developing for this purpose is the Moorlap toolbox.  Moorlap actually stands for model order reduction laboratory.  So it's a model reduction toolbox in MATLAB originally and nowadays also an octave based  on spectral projection methods.  A little bit about history, it's already a quite old project.  The first release was in 2006 with 1.0, having three model order reductions for standard  methods and a few basic matrix equations.  So it was for the standalone version.  And then after some development time and only internal releases, version 3.0 was released  in 2017, 4.0 in 2018, and the latest version is now 5.0 in 2019.  The current version of the toolbox has now 10 model reduction methods for a lot of different  types of systems like the standard systems were all started, but also the script or  in second order systems in the continuous and discrete time setting.  And it's coming with advanced system theoretic subroutines, for example, for the evaluation  of the system afterwards, and also with underlying matrix equation solvers for the implementation  of the toolbox.  During all this time, actually a lot of people have already contributed to the code.  So you can see here me as the current core developer of the toolbox, Professor Peter  Wenner from the Max Planck Institute as the overall copyright holder.  And then we have a lot of people that contributed from the MPI in Markterburg, but also from  the Otto von Gerich University in Markterburg for the software.  So a small feature checklist for our toolbox.  First of all, it's open source and free.  You can just download it for free for testing from the project website or from Cenodo and  it's licensed under the GNU or Farrish General Public License version 3.  It's fast and accurate due to the underlying structure of projection methods we are using  for the implementation.  Usually we can outperform other established software model reduction software tools in  terms of accuracy and speed.  We have a unified framework, meaning that all model reduction methods belonging to the  same class of systems share exactly the same interface such that they can easily exchange  and it's very easy to learn how those methods are working.  The toolbox is modular in itself, meaning we not only provide access to the top level  model reduction routines, which is the main purpose of the toolbox, but also to all the  underlying routines which are building up the model reduction methods such that the user  can build up their own methods afterwards.  Also it's portable by currently using no binary extensions and also it's only the main dependencies  are the basic MATLAB version from 2012 or the corresponding version in October.  So now I want to talk a little bit more detail about the toolbox design and its integration  into MATLAB and October.  And therefore first talk a little bit about MATLAB.  MATLAB is a multi-paradigm programming language and at the same time, the proprietary IDE that  is interpreting this programming language.  The main purpose of MATLAB are numerical computations with matrices and its extensions to a lot of  different application areas comes from its toolbox design.  So there's the basic MATLAB version, but surrounding it, for example, for systems engineering,  there are a lot of toolboxes that can be installed for it.  In the sense of systems engineering, one should be heard of the Simulink toolbox, the  control system toolbox or the robust control toolbox that are the main contribution when  working with dynamic assistance there.  The nice thing about MATLAB is they also allow for the users to define their own MATLAB toolbox  system, which is a very easy way to chip the code, install it for the user and to also  implement certain type of documentation for it.  Having this design of toolboxes and those already existing ones which are giving us  predefined data structures, objects and routines in mind, we came up with certain goals and  software design of our toolbox.  So first of all, it should be intuitive to handle with having their actual applications  of engineers in mind, it should be very easy for them to directly apply the model reduction  methods without actually knowing how those model reduction methods are supposed to work.  They should be fully customizable, so with going more into detail, the user should be  able to change the behavior of the routines without rewriting the code.  Also, it should be compatible with all the other established main software out there.  Additionally, Octave is one open source and free alternative to MATLAB and to also have  our toolbox accessible for everyone that are not used, also for people that are not  using the proprietary version of MATLAB, we are trying to be completely compatible with  Octave.  So to fulfill our design goals of more lab, we decided to design our toolbox in an object  oriented way and our main object are those input output systems.  And now inheriting from those, we have developed the methods for different type of system classes.  The first one that was implemented are standard systems, as you can see it over here.  So just the first order of differential equations describing the internal dynamics and the algebraic  output equation.  And those type of systems are fully supported by the main MATLAB toolboxes, by the so called  state space object.  So for the integration of more of into those toolboxes, we provide an interface for the  state space object, but also have our own interface to be independent of those toolboxes  using structs or on the other hand, just pure matrices that are defining the system.  Then we have descriptor systems where we have now originally this E matrix in front of the  derivative.  This type is partially supported by the current main MATLAB toolboxes.  The problem for those are actually noninvertible E matrices corresponding to algebraic constraints  for the system.  But we are, but they are still supporting to have an E matrix.  So we also have an interface for that, but we have support more reduction methods that  can also handle singular E matrices by using also interfaces with structs and the single  matrices and thinking back of our first time model, more of this implementing model reduction  methods for mechanical systems of this type.  This is currently not supported in MATLAB, but more of this still giving interfaces  for the structure version or just the single matrices.  Having this in mind, the basic function called a more lab look taxes.  So MLCTDSSBT is a more lab function here for continuous time descriptor state space systems  with the balanced function method where we are giving the system.  So basically an object with the matrices that are defining our differential equations and  the algebraic output equation.  We have the options, so the way of the user to customize the behavior of the routine from  the top level down.  Then the routine itself is generating the reduced order model consistent in the data type with  what the user used to give the data to the method.  And it's also giving some info about the performance of the method.  So of the underlying solvers of for example, if the method is providing an error bound for  the approximation error we are doing, this will be given back.  So then the integration of the two books might look like this.  We have on the left side, the preprocessing, so stuff that happened in the design cycle  before, which are generating actually the inputs of our system.  Then we have our here at TI system blocks, this is taken from the simulink two books.  So basically our dynamical system, which is simulated for those given inputs to generate  certain outputs, which are then used for post processing steps.  Usually this type of system block is realized and muddled up by the state space object.  So we can just take the state space object out of this whole framework that the engineer  designed, apply the model to work on the state space object.  This is defining our original system, which gives us then the reduced order model.  This reduced order model is consistent in data type of the original system.  So again, a state space object, so we can directly just replace the original system  by the reduced order model.  And we only touched this one system block in here.  So we didn't do anything with the post or the preprocessing for the integration of  more lab here.  So now let's take a look back on the artificial fishtail.  Remember the original system had this mechanical system structure and those 780,000 differential  equations describing the internal dynamics, which led to those four hours of computation  time for the two seconds simulation.  And now we apply a pre-reduction approach plus the routines that we have implemented  in the model box to it.  And at the end, we get reduced order model, which is of order one.  So described by a single second order differential equation to compute this model, it took actually  21 hours.  So compared with the simulation at the time, definitely reasonable.  And now using the reduced order model as replacement for the original for the two seconds simulation,  it just takes 0.06 seconds.  So we are around 240,000 times faster with our reduced order model than with the original  one.  And if you look down here, the reduced order model is perfectly matching the original system  in this input to output behavior.  So in practice, the reduced order model would be the way to go to real-time control of underwater  drones that are based on the artificial fishtail model.  With this, I'm basically at the end of my talk.  So I just want to summarize again.  MOLAP is a model reduction framework in MATLAB and NORCTAF, where we have the design principles  based on the underlying applications.  We have used an object-oriented programming approach with the system classes as the main  objects in behind.  And it's compatible and integrable with our established software standards.  Also it's open source and modular.  And we are not yet at the end of development of our toolbox.  So for planned future work, we have, for example, our system classes that we would like to  implement with time delays, nonlinearities, further model reduction methods for the system  classes we currently have implemented, there are way more out there for our subroutines  to support further work in OCTAF, which is actually missing all those nice standard toolboxes  that MATLAB has for the implementation.  And also we are planning a high performance variant by using highly parallelized binary  extensions to make the model reduction methods even more efficient.  Now, I'm at the end of my talk.
werner_icms_talk_0_527.png werner_icms_talk_528_1139.png werner_icms_talk_1140_2891.png werner_icms_talk_2892_7859.png werner_icms_talk_7860_9191.png werner_icms_talk_9192_10691.png werner_icms_talk_10692_11123.png werner_icms_talk_11124_11603.png werner_icms_talk_11604_11723.png werner_icms_talk_11724_13523.png werner_icms_talk_13524_14159.png werner_icms_talk_14160_16187.png werner_icms_talk_16188_16355.png werner_icms_talk_16356_18467.png werner_icms_talk_18468_20123.png werner_icms_talk_20124_21767.png werner_icms_talk_21768_23207.png werner_icms_talk_23208_23579.png werner_icms_talk_23580_23831.png werner_icms_talk_23832_24083.png werner_icms_talk_24084_24671.png werner_icms_talk_24672_25583.png werner_icms_talk_25584_25859.png werner_icms_talk_25860_26267.png werner_icms_talk_26268_26687.png werner_icms_talk_26688_27299.png werner_icms_talk_27300_28931.png werner_icms_talk_28932_29015.png werner_icms_talk_29016_29663.png werner_icms_talk_29664_30924.png
Hi, I'm Stefan Werner, a PhD student from the Max Planck Institute in Magdeburg, working in the fields of numerical linear algebra and model order reduction. In my talk, I'm going to give you a basic overview on the programming and design principles of the Moorlap toolbox. In America, the software solution we are developing at our institute for the purpose of model order reduction. This will be the basic outline of this talk, so I will start with the general model order reduction problem to give you a little bit more background and why we actually need software for this problem. Then we'll continue with an overview on the Moorlap toolbox before going into details on the toolbox design and its integration into MATLAB and Octave. So let's directly start with some problem of model order reduction. And therefore, I brought you a reword example. This is actually a project from the University in Kiel, where the task is to design and control an underwater drone which is shaped like a fish. The outcome is a so-called artificial fishtail model describing the mechanical properties of the structure you can see here on the left. This is basically a fish without the head and the fin. And on the right, you can see the actuation principle, so how an underwater drone which has this fishtail as its basic body is supposed to move. In the un-pressurized state, the fishtail is just straight. And otherwise, you see here, we have left and right chambers in the fishtail. One of those chambers should be pressurized, such as the fishtail is then bending to one side. And the idea is to let the pressure then flow from one chamber to the other, such that the fishtail is bending to one side and then the other side, such that the flapping behavior is happening like a real fish would actually swim in practice. From the mathematical side, this artificial fishtail is described by partial differential equations. And usually, and using modeling tools like measuring and finding elements to do afterwards computations with the model, we end up with such a system of second-order ordinary differential equations describing the discretized physics. This type of system is actually called an input-output system because of the three time-dependent quantities we have in here. First of all, here on the left, we have the inputs. The external forces that we can apply from the outside to somehow influence the internal behavior of the system. In terms of the fishtail, that would be the change of the pressure. Then we have x, the discretized states. Those are describing the physics of the system, and we have y, the outputs. So the quantities of interest that we can actually measure on the outside of the system. For the fishtail, that would be again a sensor at the tip of it, which is measuring the displacement. So how much are we going away from starting position in all three spatial dimensions? Down here, you can see the resulting dimensions of the system. So we have only one input because we only can influence this change of pressure. We have three outputs, the three spatial dimensions the sensor is measuring. And due to the complicated geometry of this artificial fishtail, we have around 780,000 differential equations describing the discretized physics. Now, since we want to control our fishtail, let's do a time simulation with it. That's what you can see down here. So we are applying an input for SU. This is just chosen such as the fishtail is making a turn. And down here, you can see what the sensor at the tip is measuring. So you can really see this flapping behavior of the fishtail, like it's swimming. But now we are running into a problem. This simulation is going over two seconds, but actually we needed four hours of computation time to do this simulation. So we're still having a mind we want to do real-time control of our fishtail at the end. That's completely impossible. The problem arises due to the 780,000 of differential equations we have to solve for this simulation. So in principle, the demand for computational resources here definitely it's time, but also in terms of memory, it's unbearable in practice. So we have the need for a software solution to automatically simplify those dynamic systems in the sense that we give the matrices that are describing the system to the software and then it's in a certain way coming up with a simpler description. Because at the end, we are only interested in the input to output behavior of the system. How internal physics are described, we don't need to care. So there might be an easier description instead of those 780,000 of equations that we could come up with. In a little bit broader setting, we have here on the left side, the rewrite applications that are then modeled by partial differential equations. And after discretizing, we have our input output systems that are then used for simulations and controller design. And usually in practice, those systems become very large. Such that we have a big demand for time and memory when we are performing simulations and controller design and to reduce those demands, model order reduction is one solution. Also having a mind that the surrounding things are actually this lifecycle of systems engineering that is already implemented by software tools, we need a model reduction software that fits right into this lifecycle. A little bit more concrete, what is the model reduction problem? So we have the original system, which is described by many differential equations, making the system very difficult to evaluate, so expensive in terms of time and memory, thinking of the computer. And then by model order reduction, we want to construct somehow a smaller system that is described by only a few differential equations now. So it's way cheaper to evaluate the reduced order model than the original one. Of course, we cannot take any arbitrarily small system, but applying the same input signal U to the systems, the outputs y of the original system and y hat of our approximation should be close to each other. Such that in practice, we could then replace the difficult to evaluate original system by the easy and cheap to evaluate reduced order model. Looking back to our first table, we had this mechanical system structure described by the matrices MeK, BU, NCP. Down here you can see again the dimensions of the system. Remember N was the number of differential equations describing it, so those 780,000s. And now we want to apply model reduction to it such that we get a new system described by those head matrices, which are much smaller than the original ones. So those head matrices are now of dimension r, so we only have r differential equations describing the system. And one software solution that we are developing for this purpose is the Moorlap toolbox. Moorlap actually stands for model order reduction laboratory. So it's a model reduction toolbox in MATLAB originally and nowadays also an octave based on spectral projection methods. A little bit about history, it's already a quite old project. The first release was in 2006 with 1.0, having three model order reductions for standard methods and a few basic matrix equations. So it was for the standalone version. And then after some development time and only internal releases, version 3.0 was released in 2017, 4.0 in 2018, and the latest version is now 5.0 in 2019. The current version of the toolbox has now 10 model reduction methods for a lot of different types of systems like the standard systems were all started, but also the script or in second order systems in the continuous and discrete time setting. And it's coming with advanced system theoretic subroutines, for example, for the evaluation of the system afterwards, and also with underlying matrix equation solvers for the implementation of the toolbox. During all this time, actually a lot of people have already contributed to the code. So you can see here me as the current core developer of the toolbox, Professor Peter Wenner from the Max Planck Institute as the overall copyright holder. And then we have a lot of people that contributed from the MPI in Markterburg, but also from the Otto von Gerich University in Markterburg for the software. So a small feature checklist for our toolbox. First of all, it's open source and free. You can just download it for free for testing from the project website or from Cenodo and it's licensed under the GNU or Farrish General Public License version 3. It's fast and accurate due to the underlying structure of projection methods we are using for the implementation. Usually we can outperform other established software model reduction software tools in terms of accuracy and speed. We have a unified framework, meaning that all model reduction methods belonging to the same class of systems share exactly the same interface such that they can easily exchange and it's very easy to learn how those methods are working. The toolbox is modular in itself, meaning we not only provide access to the top level model reduction routines, which is the main purpose of the toolbox, but also to all the underlying routines which are building up the model reduction methods such that the user can build up their own methods afterwards. Also it's portable by currently using no binary extensions and also it's only the main dependencies are the basic MATLAB version from 2012 or the corresponding version in October. So now I want to talk a little bit more detail about the toolbox design and its integration into MATLAB and October. And therefore first talk a little bit about MATLAB. MATLAB is a multi-paradigm programming language and at the same time, the proprietary IDE that is interpreting this programming language. The main purpose of MATLAB are numerical computations with matrices and its extensions to a lot of different application areas comes from its toolbox design. So there's the basic MATLAB version, but surrounding it, for example, for systems engineering, there are a lot of toolboxes that can be installed for it. In the sense of systems engineering, one should be heard of the Simulink toolbox, the control system toolbox or the robust control toolbox that are the main contribution when working with dynamic assistance there. The nice thing about MATLAB is they also allow for the users to define their own MATLAB toolbox system, which is a very easy way to chip the code, install it for the user and to also implement certain type of documentation for it. Having this design of toolboxes and those already existing ones which are giving us predefined data structures, objects and routines in mind, we came up with certain goals and software design of our toolbox. So first of all, it should be intuitive to handle with having their actual applications of engineers in mind, it should be very easy for them to directly apply the model reduction methods without actually knowing how those model reduction methods are supposed to work. They should be fully customizable, so with going more into detail, the user should be able to change the behavior of the routines without rewriting the code. Also, it should be compatible with all the other established main software out there. Additionally, Octave is one open source and free alternative to MATLAB and to also have our toolbox accessible for everyone that are not used, also for people that are not using the proprietary version of MATLAB, we are trying to be completely compatible with Octave. So to fulfill our design goals of more lab, we decided to design our toolbox in an object oriented way and our main object are those input output systems. And now inheriting from those, we have developed the methods for different type of system classes. The first one that was implemented are standard systems, as you can see it over here. So just the first order of differential equations describing the internal dynamics and the algebraic output equation. And those type of systems are fully supported by the main MATLAB toolboxes, by the so called state space object. So for the integration of more of into those toolboxes, we provide an interface for the state space object, but also have our own interface to be independent of those toolboxes using structs or on the other hand, just pure matrices that are defining the system. Then we have descriptor systems where we have now originally this E matrix in front of the derivative. This type is partially supported by the current main MATLAB toolboxes. The problem for those are actually noninvertible E matrices corresponding to algebraic constraints for the system. But we are, but they are still supporting to have an E matrix. So we also have an interface for that, but we have support more reduction methods that can also handle singular E matrices by using also interfaces with structs and the single matrices and thinking back of our first time model, more of this implementing model reduction methods for mechanical systems of this type. This is currently not supported in MATLAB, but more of this still giving interfaces for the structure version or just the single matrices. Having this in mind, the basic function called a more lab look taxes. So MLCTDSSBT is a more lab function here for continuous time descriptor state space systems with the balanced function method where we are giving the system. So basically an object with the matrices that are defining our differential equations and the algebraic output equation. We have the options, so the way of the user to customize the behavior of the routine from the top level down. Then the routine itself is generating the reduced order model consistent in the data type with what the user used to give the data to the method. And it's also giving some info about the performance of the method. So of the underlying solvers of for example, if the method is providing an error bound for the approximation error we are doing, this will be given back. So then the integration of the two books might look like this. We have on the left side, the preprocessing, so stuff that happened in the design cycle before, which are generating actually the inputs of our system. Then we have our here at TI system blocks, this is taken from the simulink two books. So basically our dynamical system, which is simulated for those given inputs to generate certain outputs, which are then used for post processing steps. Usually this type of system block is realized and muddled up by the state space object. So we can just take the state space object out of this whole framework that the engineer designed, apply the model to work on the state space object. This is defining our original system, which gives us then the reduced order model. This reduced order model is consistent in data type of the original system. So again, a state space object, so we can directly just replace the original system by the reduced order model. And we only touched this one system block in here. So we didn't do anything with the post or the preprocessing for the integration of more lab here. So now let's take a look back on the artificial fishtail. Remember the original system had this mechanical system structure and those 780,000 differential equations describing the internal dynamics, which led to those four hours of computation time for the two seconds simulation. And now we apply a pre-reduction approach plus the routines that we have implemented in the model box to it. And at the end, we get reduced order model, which is of order one. So described by a single second order differential equation to compute this model, it took actually 21 hours. So compared with the simulation at the time, definitely reasonable. And now using the reduced order model as replacement for the original for the two seconds simulation, it just takes 0.06 seconds. So we are around 240,000 times faster with our reduced order model than with the original one. And if you look down here, the reduced order model is perfectly matching the original system in this input to output behavior. So in practice, the reduced order model would be the way to go to real-time control of underwater drones that are based on the artificial fishtail model. With this, I'm basically at the end of my talk. So I just want to summarize again. MOLAP is a model reduction framework in MATLAB and NORCTAF, where we have the design principles based on the underlying applications. We have used an object-oriented programming approach with the system classes as the main objects in behind. And it's compatible and integrable with our established software standards. Also it's open source and modular. And we are not yet at the end of development of our toolbox. So for planned future work, we have, for example, our system classes that we would like to implement with time delays, nonlinearities, further model reduction methods for the system classes we currently have implemented, there are way more out there for our subroutines to support further work in OCTAF, which is actually missing all those nice standard toolboxes that MATLAB has for the implementation. And also we are planning a high performance variant by using highly parallelized binary extensions to make the model reduction methods even more efficient. Now, I'm at the end of my talk.
design principles of the Moorlap toolbox. In America, the software solution we are developing Kiel, where the task is to design and control an performing simulations and controller design and to reduce those demands, model order reduction is by software tools, we need a model reduction in second order systems in the continuous and established software model reduction software the toolbox design and its integration into toolbox, the control system toolbox or the robust reduction methods for mechanical systems of this or the preprocessing for the integration of more talk.