Since we have a cross-platform product, we were starting to face a new problem: building and testing system models on each platform at each release. For example, we have a bunch of tutorials and demo cases we distribute with the software. Maintaining and testing all those tutorials is not only boring, but it takes hours to days : we definitely can’t afford it.

We also have some interesting engineering cases. While working on a big model for a customer on a given platform, we suspected that the solver was responsible for bad CPU performances. Someone asked me : “how does it run on other platforms ?”. Very good question, but i really didn’t have days to spend to reproduce the exact same system on the other platforms to answer this question, as interesting it was.

As a matter of fact, we needed some kind of Super Application Program Interface, to control all our simulation platforms in the same way: we could compare simulation results, and even maybe transform a model of a given platform to the others.

Most platforms provide some kind of API:

• SimulationX has a COM interface
• AMESim comes with VBA, matlab and python interface
• Matlab/Simulink provides command lines functions for all operations

As you may already know… I love python ! No way I would use anything else for such high level programming :

• COM is very nicely handled in the win32com library.  SimulationX : checked
• AMESim has a python interface : checked
• Matlab… there must be something to deal with matlab ! My friend Google found this incredibly powerful library : matlabwrap. Matlab: checked

What we wanted is to have an object-oriented interface, common for all platforms, to deal with all basic operations :

• opening/saving/closing a model
• adding components and/or modifying the sketch
• modifying parameters
• getting simulation results

For sure, it has been a mess to code (as each platform’s API is very specific), and it is not completely tested yet. But the prototype is already very handy and quite powerful :

• we can access any component or variable of a model of any platform in a very clear and simple syntax
• parameters/results can be set/returned in standard python or numpy arrays format, for direct post-processing
• transforming a model from one platform to another is almost* automatic

(*) : almost… we didn’t get to transform platform specific models (for control, mechanics, etc…), we properly transform the ‘numenGo’ part of a system (retrieving position, orientation, parameters, connections, etc…). Most of the time, it covers 90-95% of the transformation work. The model is even stored in a neutral format corresponding to our metamodel.

As said above, it may never becomes a standard product, but we can use it on demand for clients who would like to share their models on different platforms.

Now, on this basis, our next move is to work out an automatic solution for cross platform testing : it implies to store some reference results, being able to compare them. So far, I am really considering pytables. Any better idea ?

Of course, I couldn’t start with anything else than our python API. To create our wrappers, we are using the excellent py++. With a few tricks, we managed to reuse our doxygen documentation for each method and class. The python API of our libs is awesome, as many features of our libs really only make sense in a scripting environment, or in a high level programming language (for example the quantities). For engineering studies, we use it for sizing, sensitivity analysis, pre and post treatment. Each time, we try to package it in reusable packages to enrich the API. Our API makes Python an excellent scientific environment, especially when you use it with numpy, scipy and matplotlib.

Another very important use of python is the processing of our models. Since we use MDA, all our models are described in a huge xml file, containing all informations related to the models (documentation, parameters, variables, icons, ports, specific methods…). Thanks to some additional libraries (lxml for xml handling, PIL libary for image handling…), we generate all images needed for our icons, create complex html documentation files (with latex equations generated on the fly as pngs). The complete packaging of our libraries for each platform is done with some python scripts.

When we need simple GUIs for small features of our software (for example, the license manager or the pathlist editor), we program them in python using Tkinter (the default GUI toolkit of python, simple but fair enough for our use). When the python code is fine, we package it as a standalone executable using the pyinstaller library.

Lately, we decided to use a build server to compile all our software when we commit new stuff on our CVS. Once again, we choosed a python based solution, the excellent buildbot. We managed to create a script that automates not only the build, but also all the packaging. Once our build is ready, we automatically upload it on our amazon S3 bucket thanks to the very powerful amazon S3 python API.

As you see, python is almost everywhere in our process, it is our glue and we use it every time we can automate a task.

Python is cross-platform, this way we make sure that everything we script will be reusable, whatever our developpers will use as coding environment.

Python rocks, I love my Python.