Quality Checks for your Libraries

As we draw closer to the biannual release of Dymola, at Claytex we also reach the final stages of the library development. As a long standing Dassault Systemes’ partner and Dymola pre-release tester, we are committed to checking the libraries we supply pass our quality checking processes.

Although Claytex supply commercial products to Academia and Industry both directly and via Dassault Systemes, the checks I describe should also be performed on internal libraries that an individual or team might be making use of.

In this blog post, I will explain the benefit of the automated tools we have developed to do this and how each check will benefit both the user and developers of a library.

Figure 1: RegressionTest library and contents.
Figure 1: RegressionTest library and contents. We will focus on the QualityCheck package.

For our quality checks we run functions from the library in Figure 1 which we develop and distribute at Claytex. The main quality checks we run are to check for:

  1. Copyright statements
  2. Existence of adequate length documentation
  3. Existence of experiments settings
  4. Checking for existence of Icons


The copyright statements are essential for a sofware developer and distributor to protect their hard work when used by third parties. We must make sure that every single Modelica class in the libraries we develop is copyrighted. By calling the checkCopyrightText function and selecting the library we want it to check, we can make sure every class in that library has a matching copyright statement. The Modelica classes that fail the check are listed within the Dymola commands window.

Figure 2: Contents of the QualityChecks package.
Figure 2: Contents of the QualityChecks package.

Check documentation

The next check we perform is checkDocumentation. This function checks that each Modelica class within the selected library includes documentation with a prescribed minimum number of characters. The minimum number of characters can be set by the user, particularly to cater for shorter documentation strings, particularly for packages where the documentation does not need to be as extensive.

We need to check for the existence of Modelica class documentation for several reasons:

To give any user or developer of a Modelica class access to information on what the class represents, its limitations and references for any code and equations that are used there-in.

Some of the downsides of not providing documentation can be: difficulty of use, use of class for unintended applications, lengthy email exchange with a user or developer to clear any doubts they may have. Worst of all, if the developer of that Modelica class is no longer accessible (moved company, for example) the task of picking up their work is much more difficult and prone to misinterpretation.

Experiment settings

The checkExperiments function checks all Modelica classes within an Experiments package including experiment settings. These settings are what the Claytex Multi-run and Regression test tool use when simulating experiments to generate results to compare against previous library version results.

In any case, within a model it is useful to store recomended simulation settings that should be used when simulating an experiment. These should be compatible with the scenario being tested. Solver settings can also be stored within the experiment. This is particularly important when a solver other than the default solver “Dassl” is required by the experiment.


The importance of icons is significant. They allow classes to be represented with the use of pictures and diagrams, effectively what is a universal language.

re 3: Screen capture showing the difference in appearance between a system model with no icons drawn (top) vs. one which does have icons (bottom).
Figure 3: Screen capture showing the difference in appearance between a system model with no icons drawn (top) vs. one which does have icons (bottom).

Figure 3 shows how limited the top model is in conveying to the user what it represents. We could of course read the default strings on each object and figure out what it represents (assuming the strings relate correctly to the object). On the other hand, with the use of icon drawing objects we could easily obtain the visual representation of the lower diagram and appreciate we are looking at a ground – linear spring – mass – nonlinear spring – mass system.

The above mentioned function really speeds up the library related quality checks ensuring that you deliver work to a good standard. We have such tools available to acquire including a Multi-run tool, used for running batches of experiments to ensure they are correct and consistent in their results, as well as a RegressionTest tool, the same tool we use for ensuring our libraries comply to the standard that has been set. In terms of the RegressionTest tool, Claytex can advise you in this respect for setting up such a system. Please get in touch for more information. We will be happy to assist you.

Written by: Alessandro Picarelli – Engineering Director

Please get in touch if you have any questions or have got a topic in mind that you would like us to write about. You can submit your questions / topics via: Tech Blog Questions / Topic Suggestion


Got a question? Just fill in this form and send it to us and we'll get back to you shortly.


© Copyright 2010-2024 Claytex Services Ltd All Rights Reserved

Log in with your credentials

Forgot your details?