SMASH supports a binary output version similar to the OSCAR 2013 standard. It is faster to read and write and theoretically needs less disk space. However, currently in ASCII OSCAR 2013 only 5 digits after the comma are written for any real number, while the binary saves the whole double (16 digits). By accident, this makes the sizes of the binary output files approximately the same as the OSCAR ASCII files. The binary format follows the general block structure of the OSCAR format: OSCAR Block Structure. However, for the binary format, the data type specification is stricter. The types used for the output are 4 bytes signed integers, 8 bytes doubles and 1 byte chars.

As for OSCAR ASCII output there are two kinds of binary output: particles and collisions. The specifics for both particles and collisions output are the following:
Header

4*char uint16_t uint16_t uint32_t len*char

magic_number, format_version, format_variant, len, smash_version

magic_number - 4 bytes that in ASCII read as "SMSH".
Format version is an integer number, currently it is 7.
Format variant is an integer number: 0 for default, 1 for extended.
len is the length of smash version string
smash_version is len chars that give information about the SMASH version.

Output block header
At start of event, end of event or any other particle output:

char uint32_t

'p' n_part_lines

n_part_lines is the number of particle lines in the block that follows

At interaction:

char uint32_t uint32_t double double uint32_t

'i' nin nout density xsection process_type

nin, nout are numbers of incoming and outgoing particles

Block header is followed by nin + nout particle lines.

Particle line

9*double int32_t int32_t int32_t

t x y z mass p0 px py pz pdg ID charge

Extended Particle line

9*double int32_t int32_t int32_t int32_t double double int32_t int32_t double int32_t int32_t

t x y z mass p0 px py pz pdg ID charge ncoll form_time xsecfac proc_id_origin proc_type_origin time_last_coll pdg_mother1 pdg_mother2

proc_id_origin, proc_type_orgin record the id and type of the last reaction that the particle has experienced.
time_last_coll records the time of the particle's last interaction (except wall crossing), from which we can calculate the position of this particle at kinetic freeze-out.
pdg_mother1, pdg_mother2 record the pdg numbers of the incoming particles of the reaction where this particle is produced. If the particle is produced in a resonance decay, then pdg_mother2 is set equal to 0. If it is produced in a thermal bubble, then both the pdg_mother1 and pdg_mother2 are set equal to zero. Both the pdg numbers are not affected by elastic scatterings.

Event end line

char uint32_t double char

'f' event_number impact_parameter empty

Where

event_number: Number of the event, starting with 0.
impact_parameter: Impact parameter [fm] of the collision in case of a collider setup, 0.0 otherwise.
empty: 0 if there was an interaction between the projectile and the target, 1 otherwise. For non-collider setups, this is always 0.

Particles output

The particles output is Written to the particles_binary.bin file. It contains the current particle list at specific moments of time. Every moment of time is written as a 'p' block. For options of this output see content-specific output options.

Collisions output

The collisions output is Written to the collisions_binary.bin file. It contains interactions (collisions, decays, box wall crossings) and optionally the initial and final configuration. The interactions are written in computational frame time-ordered fashion, in 'i' blocks, which contains the information of the incoming and the outgoing particles of each reaction written in the 'incoming' and 'outgoing' blocks respectively. Initial and final states are written as 'p' blocks. The process IDs indicating the types of the reaction, such as resonance decay, elastic scattering, soft string process, hard string process, etc., are written in the 'process_type' blocks. For options of this output see content-specific output options.