Output Data Organization – Part 1

Often, it is helpful to create a collection of variables at the experiment level of a simulation which will serve as an output data repository. Part 1 of this topic on output data organization will outline one way to do this efficiently for the variables that are common across all of your experiments.

This experiment level collection of variables will generally contain all the channels the user may like to ‘view’ or ‘use’ once their model is outside the Dymola environment (whether it is exported as an FMU or one of the other options). Variables in the model, other than those listed in this output data collection, are generally considered extra variables that are only really needed for debugging purposes. For this reason, the users are usually OK with all of these extra variables being hidden to minimize the solve time, I/O overhead, and disk writing penalties of their simulation.

In the past, I defined a large set of output variables in every experiment that I created. They often related to vehicle level outputs such as wheel loads, damper travels, or camber. Many of these declarations were identical in every vehicle level experiment, and in these cases I handled the declarations as an extended partial class. However, for the equations that assigned values to these output variables I found myself doing a lot of the dreaded copy/paste (cringe). Despite my best efforts, I always struggled to find a good way to eliminate this code duplication. Recently, with the help of my colleagues at Claytex, I made some progress on this front.

As you may already know based on our recent blog post (Dymola Basics: 9. Modelica Language Classes), records can only contain declarations of variables, not equations themselves. For years, I only used records as a means to define/collect the input parameters that were used in simulations. While this is one use of records that is handy, records can be used for much more. I now use records to define the output data collection in my models. There are a few nuances/tricks that make this work efficiently. The following steps outline one way to create an output data collection that will hopefully help you eliminate some code duplication.

1. Create an OutputData record in your library.
2. Create the variable declarations that follow your organization’s naming/sign convention in this OutputData record.
3. For each of the variables, edit the annotation to have Dymola display each variable in the dialog box.              For more info see this blog post: User-defined input dialogs in Dymola.
4. Instantiate the outputData class into your experiment level as an inner output.                 
5. Instantiate the outputData class into your vehicle level model as an outer output.               
6. Double click on the instantiated outputData record in your vehicle level model and within each input box, type the path to the variable you want assigned to that output variable.

Once your Experiment is working, and ready to export for use outside of Dymola, adjust your solver settings so that Dymola ‘Evaluates’ model parameters to lean out the model.

If building an FMU for use in one of your deployments, go ahead and check the Auxiliary variables filter as well:

Both of these settings can help lighten and speed up your exported model.

Closing

I hope this helps you organize your output data in a manner that requires less overhead than your previous methods. In Part 2 of this installment I will address the experiment specific outputs that are required in your model, hopefully making your Dymola output data organization even a bit more efficient.

Written by: Nate Horn – Vice President

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