hexagon logo
Register Sign in
  • State Not Answered
  • Replies 6 replies
  • Subscribers 11 subscribers
  • Views 134 views
  • Users 0 members are here
Options
Related

How to reduce simulation data output using co simulation with Matlab

nils_s
Hello!
I am running a rather complex Adams model in co-simulation with Matlab Simulink​ with high output sample frequency of min 4 kHz over a couple of seconds. Thus the results file is getting pretty big and maybe even slowing down my Analysis. As I have a separate request file with the results of interest I wonder if I can set a variable for that only the request file (and optionally the .gra) will be written?
​
​Maybe someone has some experience with this. Would be nice to know. Thanks!
​
​Kind Regards
​Nils​
  • 0
    Use requests instead of the Results file. Write the output you need into requests and do not write the results Settings/Solver/Output
    Juan
  • 0
    (implementation help)
    If you're running in interactive mode, you can add a few lines to the end of the CMD file to turn off RES file creation,
    output set results model = .model_1 create = off​
    ​
    ​But the other thing that'll slow down interactive mode is having "Update graphics display" checked.  I like to manually turn it off, but it looks like you can add another line to do this:
    ​simulation single set update = "none"
    ​
    ​Lastly, you could instead choose to trim down the RES file to pretty much just the requests by adding this line:
    ​output set results formatted = off xrf = on accelerations = off applied_forces = off displacements = off reaction_forces = off velocities = off data_structures = off system_elements = off linear = off floating_markers = off tire = off friction_summary = off comment = off contact_incidents = off node_incidents = off
  • 0
    I once had a colleague complaining about the res file being too big and the req file being much better to use.
    After using the settings to switch off ANY other res-content than requests, the file size was not much different between res and req.
    Res_Contents
    Then he had the problem of req file sizes of several GB (due to long runs with high sampling rate) and I convinced him that ADAMS can handle large xml's (res-files with XRF-Option) better than large req-files.
    Req_Off
     
    So the solution was as simple as to switch off gra/req and control the res-contents.
  • 0
    Thanks for your replies!
    The reason I was wondering was that in the Adams model I did not set option to output .res, .req or .gra.
    When I did the plant export of the Adams model and import to Simulink I could only set a name for the results of the simulation (in the Simulink block), not which kind of export I like to chose.
    ​
    ​The answer was actually easier than I thought:
    In the exported .adm, there needs to be the command.
    ​
    OUTPUT/
    , REQSAVE
    , GRSAVE
    ​
    Yet ​I cannot tell if that speeds up the simulation, but my feeling is that it does not. 
    ​
    ​Kind Regards
    ​Nils
  • 0
    Do it in a dummy model and export an adm.
    Then just copy the settings at the end of the adm to the adm you exported for matalab.
     
    Should look like this:
    !
    OUTPUT/
    , NOPRINT
    !
    RESULTS/
    , FORMATTED
    , NOVELOCITIES
    , NOACCELERATIONS
    , NOAPPLIEDFORCES
    , NOREACTIONFORCES
    , NODATASTRUCTURES
    , NOSYSTEMELEMENTS
    , NOFLOATINGMARKERS
    , NOTIRES
    , XRF
     
  • 0
    This topic is old, but one important thing hasn't been mentioned here:
    • you don't have to generate an output for each co-simulation step. There is a setting, in the Adams plant mask in Simulink, named something like "communications per output step", or similar.
     
    Basically you set:
    • communication interval = fast enough to capture dynamics between the two packages
    • then set "number of communications per output" to something like "10", meaning you only want to save results every 10th communication.
    That setting, along with the rest described above, can speed things up quite a bit..
     
    HTH,
    Kent
© 2025 Hexagon AB and/or its subsidiaries. Privacy Policy | Cloud Services Agreement