As stated in Part 1 of the series of blog posts on output data organization, it is helpful to create collections of variables at the experiment level of a simulation which serve as output data repositories. Part 2 of this series on output data organization will outline one way to handle the non-vehicle channels (or experiment channels as I generally refer to them) in a way that is relatively clean and straightforward to manage.
In this post we will make use of a replaceable output record to easily change the set of experiment channel declarations. This record will contain the output channel declarations that are not those that are native to the vehicle itself (which we already handled in Part 1). Some examples of these channels could be the distance travelled along a road, the deviation of the vehicle from the path defined in the road, actuator loads for a 7 post test rig and etc.
Often there are a few common sets of channels that will work well for a few full vehicle experiments. For a project I recently worked on, I ended up with 5 records.
- OutputData_Base
- OutputData_Null
- OutputData_KnC
- OutputData_7P
- OutputData_TrackSim
The last four are extended from the OutputData_Base class. The _Null record was only created due to the desire to conduct a modification to the icon layer that shows up in the Experiment level. I’ve found that icon changes for replaceable classes help me minimize implementation errors during model development. The images below show the different icons across the range of experiments within this particular library.
In the IOLayer that I extend into every experiment (a concept that will be discussed further in part 3 of this series… but for the time being can be thought of as a partial model) I instantiated the OutputData_Base class. Within it’s parameter dialog window, attributes tab, I set the following:
Once the IOLayer is extended into the experiment level simulation, a simple right click on the instantiation and ‘Change Class – All Matching Choices’ selection will provide the developer with the eligible records allowing them to quickly select one that best suits the current experiment. Once the correct channel list has been instantiated, the user can double click on the instantiated record and assign values to the variables.
It should be noted that, unfortunately, a small amount of code duplication is necessary across similar experiment types when utilizing this approach.
Closing
Although this method may not be perfect in terms of code duplication, it is the best way I’ve encountered to manage experiment specific output channels within Dymola. If you find a better way, or have any questions, feel free to email me or the Claytex support team. I hope this helps you organize your output data in a manner that requires less overhead than your previous methods.
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