MDF: Magnetic Particle Imaging Data Format
Tobias Knopp, Thilo Viereck, Gael Bringout, Mandy Ahlborg, Anselm von Gladiss, Christian Kaethner, Alexander Neumann, Patrick Vogel, Jürgen Rahmer, Martin Möddel
aarXiv:1602.06072v6 [physics.med-ph] 11 Jan 2018
MDF: Magnetic Particle Imaging Data Format
T. Knopp , , T. Viereck , G. Bringout , M. Ahlborg , A. von Gladiss , C. Kaethner , A. Neumann , P. Vogel , J. Rahmer , M. M¨oddel , Section for Biomedical Imaging, University Medical Center Hamburg-Eppendorf, Germany Institute for Biomedical Imaging, Hamburg University of Technology, Germany Institute of Electrical Measurement and Fundamental Electrical Engineering, TU Braunschweig, Germany Physikalisch-Technische Bundesanstalt, Berlin, Germany Institute of Medical Engineering, University of L¨ubeck, Germany Department of Experimental Physics 5 (Biophysics), University of W¨urzburg, Germany Philips GmbH Innovative Technologies, Research Laboratories, Hamburg, GermanyJanuary 12, 2018
Version
Abstract
Magnetic particle imaging (MPI) is a tomographic method to determine the spatio-temporal distribution of magnetic nanoparticles. In this document, a fileformat for the standardized storage of MPI and magnetic particle spectroscopy (MPS) data is introduced. The aim of the Magnetic Particle Imaging Data Format(MDF) is to provide a coherent way of exchanging MPI and MPS data acquired with different devices worldwide. The focus of the MDF is on sequence parameters,measurement data, calibration data, and reconstruction data. The format is based on the hierarchical document format in version 5 (HDF5). This documentdiscusses the MDF version 2.0.0, which is not backward compatible with version 1.x.y.
The purpose of this document is to introduce a file format for exchanging Mag-netic Particle Imaging (MPI) and Magnetic Particle Spectroscopy (MPS) data.The Magnetic Particle Imaging Data Format (MDF) is based on the hierarchi-cal document format (HDF) in version 5 [1]. HDF5 is able to store multipledatasets within a single file providing a powerful and flexible data container. Toallow an easy exchange of MPI data, one has to specify a naming scheme withinHDF5 files which is the purpose of this document. In order to create and access HDF5 data, an Open Source C library is available that provides dynamic accessfrom most programming languages. MATLAB supports HDF5 by its functions h5read and h5write . For Python, the h5py package exists, and the Julia pro-gramming language provides access to HDF5 files via the
HDF5 package. Forlanguages based on the .NET framework, the
HDF5DotNet library is available.The MDF is mainly focused on storing measurement data, calibration data,or reconstruction data together with the corresponding sequence parameters andmetadata. Even though it is possible to combine measurement data and recon-1truction data into a single file, it is recommended to use a single file for eachof the following dataset types:1. Measurement data2. Calibration data3. Reconstruction data
MPI parameters are stored as regular
HDF5 datasets . HDF5 attributes arenot used in the current specification of the MDF. For most datasets, afixed datatype is used, for example the drive-field amplitudes are stored as
H 5 T _ N A T I V E _ D O U B L E values. Whenever a data type has a big- and little-endian version, the little-endian data type should be used. For our convenience,we refer to the HDF5 datatypes
H 5 T _ S T R I N G , H 5 T _ N A T I V E _ D O U B L E , and
H 5 T _ N A T I V E _ I N T 6 4 as String , Float64 and
Int64 . Boolean data is storedas
H 5 T _ N A T I V E _ I N T 8 , which we refer to as
Int8 .The datatype of the MPI measurement and calibration data offers more free-dom and is denoted by
Number , which can be any of the following HDF5 datatypes:
H 5 T _ N A T I V E _ F L O A T , H 5 T _ N A T I V E _ D O U B L E , H 5 T _ N A T I V E _ I N T 8 , H 5 T _ N A T I V E _ I N T 1 6 , H 5 T _ N A T I V E _ I N T 3 2 , H 5 T _ N A T I V E _ I N T 6 4 or acomplex number as defined below.Since storing complex data in HDF5 is not standardized, we define a com-pound datatype
H 5 T _ C O M P O U N D in HDF5 with fields r and i using one ofthe above mentioned floating point types to represent the real and the imag-inary part of a complex number. This representation was chosen becauseit is also the default behavior for complex numbers in Python using numpyand h5py. Complex128 refers to the complex compound type with base type
H 5 T _ N A T I V E _ D O U B L E .For later identification of a data set, we store three Universally Unique Iden-tifiers (UUIDs) (RFC 4122) [2] in its canonical textual representation as 32hexadecimal digits, displayed in five groups separated by hyphens as for example ee94cb6d-febf-47d9-bec9-e3afa59bfaf8 . For the generationof the UUIDs, we recommend to use version 4 of the UUID specification.Whenever multidimensional data is stored dimensions are arranged in a waythat cache is utilized best for fast reconstruction or fast frame selection for ex-ample. The leading dimension in the MDF specification is slowest to access andthe last dimension is the fastest to access (contiguous memory access). That also means that dependent on the memory layout of your programming language theorder of the dimensions will be just as in the MDF specifications (row major) orreversed (column major). Please take this into account when reading or writingMDF files, which includes the usage of HDF5 viewers.
With one exception, physical quantities are given in SI units. The magneticfield strength is reported in T µ − = 4 π Am − µ − . This convention has beenproposed in the first MPI publication [3] and consistently been used in mostMPI related publications. The aim of this convention is to report the numberson a Tesla scale, which most readers with a background in magnetic resonanceimaging are familiar with. The MDF has 8 main groups in the root directory and 2 sub-groups. We dis-tinguish between optional and non-optional groups as well as optional, non-optional, and conditional parameters.Any optional parameter can be omitted, whereas any non-optional parame-ter in a non-optional group is mandatory. Conditional parameters are linked toBoolean parameters and have to be provided, if these parameters are true andcan be omitted if they are false. If a parameter is optional, non-optional, orconditional is indicated by yes, no, or the corresponding Boolean parameter.If a group is optional all of its parameters may be omitted, if this group isnot used. The groups / , /study , /experiment , /scanner , /acquisition con-tain mostly metadata and are mandatory. The /tracer group is only manda-tory if magnetic material has been placed in the MPI system. The groups /measurement , /calibration , and /reconstruction are all optional. In caseof calibration measurements, the /calibration group is mandatory. The re-construction data is stored in /reconstruction . It is possible to store user defined parameters in an MDF. For instance one maywant to store the temperature of the room in which your MPI device is operated.In this case, one is free to add new parameters to any of the existing groups.Moreover, if necessary, one can also introduce new groups. In order to be able to2istinguish these datasets and groups from the specified ones, it is mandatory touse the prefix “ ” for all parameters and groups. As an example, one could adda new group / room that includes the dataset temperature . Using the prefix“ ” will ensure that the stored dataset is compatible with future versions of theMDF.
Several parameters within the MDF are linked in dimensionality. We use shortvariable names to indicate these connections. The following table describes themeaning of each variable name used in this specification.
Variable Number of A tracer materials/injections for multi-color MPI N acquired frames, same as a spatial position for calibration O acquired frames w/o background frames J periods within one frame Y partitions of each patch position C receive channels D drive-field channels F frequencies describing the drive-field waveform V points sampled at receiver during one drive-field period W sampling points containing processed data ( W = V if no fre-quency selection or bandwidth reduction has been applied) K frequencies describing the processed data ( K = V / Q frames in the reconstructed MPI data set P voxels in the reconstructed MPI data set S channels in the reconstructed MPI data set If you find mistakes in this document or the specified file format or if you wantto discuss extensions or improvements to this specification, please open an issueon GitHub: https://github.com/MagneticParticleImaging/MDF
As the file format is versionized it will be possible to extend it for future needsof MPI. The current version discussed in this document is version 2.0.0.
As of version 1.0.1, the most recent release of these specifications can also bealso found at: https://arxiv.org/abs/1602.06072
If you use MDF, please cite us using the arXiv reference, which is also availablefor download as
MDF.bib from GitHub.
If you want to get a basic impression of how to handle MDF files you can visitthe gitub repository of the MDF project: https://github.com/MagneticParticleImaging/MDF
There you will find the directory example, which contains a code example writ-ten in Julia, MATLAB, and Python. More details can be found in the
README of the repository.
A reference implementation for a high level MDF access is available at: https://github.com/MagneticParticleImaging/MPIFiles.jlMPIFiles.jl is a package written in the programming language Julia [4, 5, 6]. Itcan read MDF V1, MDF V2, and the dataformat of Bruker MPI systems usinga common interface. It also provides functions to convert MDF V1 or BrukerMPI files into MDF V2.3
Data (group: / ) Remarks:
Within the root group, the metadata about the file itself is stored.Within several subgroups, the metadata about the experimental setting, the MPI tracer, and the MPI scanner can be provided. The actual data is stored indedicated groups about measurement data and reconstruction data.
Parameter Type Dim Unit/Format Optional Description version String uuid String time String /study/ , non-optional)
Remarks:
A study is supposed to group a series of experiments to support,refute, or validate a hypothesis. The study group should contain name , number , uuid , and description of the study. Parameter Type Dim Unit/Format Optional Description name String number Int64 uuid String description String /experiment/ , non-optional)
Remarks:
For each experiment within a study a name , number , uuid , and description have to be provided. Additionally, the name of the subject im- aged and the flag isSimulation indicating if data has been obtained via simu-lations have to be stored.4 arameter Type Dim Unit/Format Optional Description name String number Int64 uuid String description String subject String isSimulation Int8 /tracer/ , optional) Remarks:
The tracer parameter group contains information about the MPItracers used during the experiment. For each of the A tracers name , batch , vendor , volume , and molar concentration of solute per liter must be pro-vided. Additionally, the time point of injection can be stored.This version of the MDF can handle two basic scenarios. In the first one,static tracer phantoms are used. In this case, the phantom contains A distincttracers. For example, these might be particles of different core sizes, mobile orimmobilized particles. In this case, injectionTime is not used. In the second case, A boli (e.g. pulsed boli) are administrated during the measurement, inwhich case the approximate administration volume, tracer type and time pointof injection can be provided. Note that the injection clock recording the injec-tion time should be synchronized with the clock, which provides the startingtime of the measurement.In case of a background measurement with no applied tracers in the scanner,the optional tracer group can be omitted. Parameter Type Dim Unit/Format Optional Description name String A no Name of tracer used in experiment batch String A no Batch of tracer vendor String A no Name of tracer supplier volume Float64 A L no Total volume of applied tracer concentration Float64 A mol( solute )/L no Molar concentration of solute per litre solute String A no Solute, e.g. Fe injectionTime String A yyyy-mm-ddThh:mm:ss.ms yes UTC time at which tracer injection started5 .4 Scanner Parameters (group: /scanner/ , non-optional) Remarks:
The scanner parameter group contains information about the MPIscanner used, such as name , manufacturer , boreSize , field topology , facility where the scanner is installed, and the operator . Parameter Type Dim Unit/Format Optional Description name String facility String operator String manufacturer String topology String boreSize Float64 .5 Acquisition Parameters (group: /acquisition/ , non-optional)
Remarks:
The acquisition parameter group can describe different imagingprotocols and trajectory settings. The corresponding data is organized intogeneral information, a subgroup containing information on the D excitationchannels, and a subgroup containing information on the C receive channels.The term frame refers to the data collected during one acquisition period.Usually all data within a frame will be combined to reconstruct a single MPIimage/tomogram. In the simplest scenario, this data is acquired during one drivefield/cycle . If block-averaging is applied the amount of data capturedstays the same while the acquisition time increases by a factor of numAverages .In this document we will refer to the product of one drivefield/cycle and numAverages as one drive-field period .In case that the static selection field is changed over time one will mea-sure several drive-field periods each with a different gradient field setting.In a stepped multi-patch sequence the gradient field will be spatially shiftedand/or scaled in between drive-field periods and remain constant within. Insuch a scenario a full frame consists of numPeriodsPerFrame ( J ) periods.The gradient scaling or shift within each period are described by the fields /acquisition/gradient and /acquisition/offsetField . The former has J × Y × × J × Y ×
3. While J labels the drive-field periods, Y can be used to describe dynamic multi-patchsequences where the gradient and offset field change during a drive-field period.Each period is discretized into Y equidistantly spaced time intervals. The valuesin /acquisition/gradient and /acquisition/offsetField describe the gra-dient and offset field at the beginning of each time interval. In case Y = 1 thefields at the beginning of the period J are provided, which can be used to de-scribe a static multi-patch sequence. Higher numbers of Y allow the descriptionof an arbitrarily fine grained gradient and offset field sequence.It should be noted that the combined gradient and offset field can be ex-pressed locally around the scanner center r c ∈ R via the Taylor expansion H ( r ) = H ( r c ) + J H ( r c )( r − r c ) + . . . , (1)where J H ( r c ) is the Jacobian of H at r c . /acquisition/offsetField storesthe field H ( r c ) and /acquisition/gradient stores the 3 × J H . Bothparameters are for most scanner topologies sufficient to uniquely describe theapplied field sequence. In case of non-linear fields and/or a higher degree of free-dom in the number of applied field generators, one may need additional customfields in order to uniquely define the sequence parameters. Parameter Type Dim Unit/Format Optional Description startTime String numAverages Int64 numPeriodsPerFrame Int64 J numFrames Int64 N gradient Float64 J × Y × × − µ − yes Gradient strength of the selection field in x , y , and z directions offsetField Float64 J × Y × µ − yes Offset field applied7 .5.1 Drive Field Parameters (group: /acquisition/drivefield/ , non-optional)Remarks: The drive field subgroup describes the excitation details of theimaging protocol. On the lowest level, each MPI scanner contains D channelsfor excitation. Since most drive-field parameters may change from period toperiod, they have a leading dimension J .These excitation signals are usually sinusoidal and can be described by D amplitudes (drive field strengths), D phases, a base frequency, and D dividers. In a more general setting, the generated drive field of channel d can be describedby H d ( t ) = F X l =1 A l Λ l (2 πf l t + ϕ l )where F is the number of frequencies on the channel, A l is the drive-fieldstrength, φ l is the phase, f l is the frequency ( baseFrequency / divider l ), and Λ l is the waveform. The waveform is specified by a dedicated parameter waveform .It can be set to sine , triangle , or custom . Parameter Type Dim Unit/Format Optional Description numChannels Int64 D strength Float64 J × D × F T µ − no Applied drive field strength phase Float64 J × D × F rad, [ − π, π ) no Applied drive field phase ϕ baseFrequency Float64 divider Int64 D × F baseFrequency to determine the drive field frequencies waveform String D × F sine , triangle or custom cycle Float64 divider )/ baseFrequency . It will not changewhen averaging was applied. The duration for measuring the V data points (i.e. thedrive-field period) is given by the product of period and numAverages /acquisition/receiver/ , non-optional)Remarks: The receiver subgroup describes the details on the MPI receiver.For a multi-patch sequence, it is assumed, that the signal acquisition only takesplace during particle excitation. During each drive-field cycle, C receive chan-nels record some quantity related to the magnetization dynamic. In most casesthese, will be continuous voltage signals induced into the C receive coils, whichare proportional to the change of the particle magnetization. This analog signalwill usually be converted by some sort of analog to digital converter (ADC) toa discrete series of integer numbers r ci for each channel c . To map the these values to the MPI measurement signal u ADCci , one has to scale the numbers r ci and add an offset factor u ADCci = a c r ci + b c . Here, a c and b c are the scaling and offset factors corresponding to channel c ,which can be stored in dataConversionFactor . In case the conversion wasalready performed the dataConversionFactor can be ommited.The MPI measurement signal is acquired at V equidistant time points. Forinductive measurement systems the signal is usually not measured directly atthe receive coils but amplified and filtered first, which may damp and dis-8ort the signal. Therefore, a transfer function can be stored in the parameter transferFunction , which relates the Fourier domain voltage induced at thereceive coil ˆ u coil k and the Fourier domain voltage ˆ u ADC k measured at the ADC byˆ u ADC k = a k ˆ u coil k , k = 1 , . . . , K. Here, a k are the unitless parameters stored in transferFunction for each re-ceive channel individually.For MPS systems one can additionally store a parameter that maps the in-duced voltage to the mean magnetic moment of a magnetic nanoparticle located at the center of the scanner. More precisely, in each receive coil a projectionof the mean magnetic moment onto the coil sensitivity is measured. The re-lation of this projection and the voltage at the receive coil in frequency spacerepresentation is given byˆ u coil k = 2 π i kβ ˆ m proj k , k = 1 , . . . , K. where ˆ m proj k is the orthogonal projection of the magnetic moment onto the coilsensitivity at the scanner center and β is the channel dependent conversion factorthat is stored in the parameter inductionFactor . Parameter Type Dim Unit/Format Optional Description numChannels Int64 C bandwidth Float64 numSamplingPoints Int64 V unit String dataConversionFactor Float64 C × unit yes Dimension less scaling factor and offset ( a c , b c ) to convert raw data into aphysical quantity with corresponding unit of measurement unittransferFunction Complex128 C × K yes Transfer function of the receive channels in Fourier domain. unit is the fieldfrom the /measurement group inductionFactor Float64 C unit A − m − yes Induction factor mapping the projection of the magnetic moment to the volt-age in the receive coil. /measurement/ , optional) Remarks:
MPI data is usually acquired by a series of measurements and op-tional background measurements. Here, we refer to background measurementsas MPI data captured, when any signal generating material, e.g. a phantom or adelta sample is removed from the scanner bore. Initially, all data is available intime domain, where the data of a single frame consists of the signal recorded forall periods in each receive channel, i.e. J × C × V data points per set with thetemporal index being the fastest to access. If several measurements are acquired(indicated by numFrames ), the frame dimension is the slowest to access. Alongthis dimension, the frames are ordered with respect to the time at which they were acquired starting with the measurement acquired first and stopping withthe measurement acquired last. We refer to this data as raw measurement data.In Fourier representation, each frame would be stored by J × C × K complexdata points and K = V / V to W or a corresponding reductionof frequency components K depending on the final representation in which theraw/processed data is stored. The most common processing steps are:9. Spectral leakage correction, which may be applied to ensure that eachindividual frame is periodic.2. Background correction, where the background signal in subtracted.3. Fourier transformation bringing the data from time into the Fourier rep-resentation an storing them in Fourier representation.4. Transfer function correction to obtain the magnetic moment or inducedvoltage that has been measured.5. Frequency selection to reduce the number of frequency components, e.g.bandwidth reduction or selection of high signal frequency components.6. Dimension permutation, which is usually applied to Fourier transformeddata exchanging the storing order of the data for fast access to the frames. 7. Frame permutation to reorder the frames within the data set.For each of the steps above there is a corresponding flag within this group indi-cating if the corresponding processing step has been carried out.During processing one might want to keep track which of the final N framesbelong to background measurements and which do not. Therefore, the binarymask isBackgroundFrame should be used. If frequency selection has been per-formed, frequencySelection stores the K frequency components (subset) se-lected from the set of acquired frequency components. If performed, a framepermutation can be described by a bijective mapping σ : { , , . . . , N } →{ , , . . . , N } of the set of frame indices to itself. If such a permutation isperformed, σ is stored in the one-line notation as σ (1), σ (2), . . . , σ ( N ) in framePermutation .10 arameter Type Dim Optional Description data Number N × J × C × K or J × C × K × N or N × J × C × W or J × C × W × N no Measured data at a specific processing stage isBackgroundFrame Int8 N no Mask indicating for each of the N frames if it is a backgroundmeasurement (true) or not isSpectralLeakageCorrected Int8 isBackgroundCorrected Int8 isFourierTransformed Int8 isTransferFunctionCorrected Int8 transferFunctionisFrequencySelection Int8 frequencySelectionisFastFrameAxis Int8 N has been moved to the last di-mension isFramePermution Int8 framePermutationfrequencySelection Int64 K isFrequencySelection Indices of selected frequency components framePermutation Int64 N isFramePermutation Indices of original frame order11 .7 Calibration (group: /calibration/ , optional)
Remarks:
The calibration group describes a calibration measurement (systemmatrix), although it does not hold the data itself. Each of the calibration mea-surements is taken with a calibration sample (delta sample) at a grid centeredposition inside the FOV of the device. If available, background measurementsare taken with the delta sample outside of the FOV of the scanner. Usually,not the raw measurements are stored but processed data, where at least aver-aging, Fourier transformation, frame permutation and transposition has beenperformed yielding a total of N processed frames. Of these frames O framescorrespond to the calibration scans at the O spatial positions, whereas the otherframes correspond to background measurements taken throughout the calibra-tion process. All processing steps are documented in the /measurement group. If the measurements were taken on a regular grid of size N x × N y × N z , thepermutation is usually done such that measurements are ordered with respectto their x position first, second with respect to their y position, and last withrespect to their z position. Background measurements are collected at the end in /measurement/data , which in combination with reordering of the measurementsallows a fast access to the system matrix. If a different storage order is usedthis can be documented using the optional parameter order . For non-regularsampling points, there is the possibility to explicitly store all O positions. If thecalibration measurement is performed in a MPS system, the spatial positions areusually emulated by applying offset fields, which can be stored in offsetFields . Parameter Type Dim Unit/Format Optional Description method String size Int64 O order String xyz positions Float64 O × x , y , z ) triples offsetFields Float64 O × µ − yes Applied offset field strength to emulate a spatial position ( x , y , z ) deltaSampleSize Float64 fieldOfView Float64 fieldOfViewCenter Float64 snr Float64 J × C × K yes Signal-to-noise estimate for recorded frequency components12 .8 Reconstruction Results (group: /reconstruction/ , optional) Reconstruction results are stored using the parameter data inside this group. data contains a Q × P × S array, where Q denotes the number of reconstructedframes within the data set, P denotes the number of voxels and S the numberof multispectral channels. If no multispectral reconstruction is performed, thenone may set S = 1. Depending on the reconstruction the grid of the reconstruc-tion data can be different from the system matrix grid. Hence, grid parametersare mirrored in the /reconstruction group. For analysis of the MPI tomograms, it is often required to know which partsof the reconstructed tomogram have been covered by the trajectory of the fieldfree region. In MPI, one refers to the non-covered region as overscan region.Therefore, the optional binary field isOverscanRegion stores for each voxel ifit is part of the overscan region. If no voxel lies within the overscan region, isOverscanRegion may be omitted. Parameter Type Dim Unit/Format Optional Description data Number Q × P × S no Reconstructed data size Int64 P order String xyz positions Float64 P × x , y , z ) tripels fieldOfView Float64 fieldOfViewCenter Float64 isOverscanRegion Int8 P yes Mask indicating for each of the P voxels if it is part of the overscan region (true)or not13 Changelog • Version 2 of the MDF is a major update breaking backwards compatibilitywith v1.x. The major update was necessary due to several shortcomingsin the v1.x. • The naming of parameters was made more consistent. Furthermore, someparameters moved from one group into another. • Defined a complex datatype using a HDF5 compound type. • In v1.x it was not possible to store background data. This functionalityhas been added in v2. • We simplified the measurement group and made it much more expressive.In v1.x it was not entirely clear, which processing steps have been ap-plied to the measurement data in the stored dataset. The measurement group now contains several flags that precisely document the state of thestored data. Using this it is now possible to also store calibration data inthe measurement group. The calibration group in turn only stores meta-data about a calibration experiment while the actual data is store in themeasurement group. • Updated Affiliations in the MDF specification. • Improved the general descriptions of fields and groups. • In v1.x the MDF allowed many fields to have varying dimensions dependingon the context. As of version 2.0.0 only one field offers this freedom. Thischange should make implementations handling MDF files less complex. • Number has been introduced as a generic type. • Added a table listing all variable names used in the descriptions of param-eters. • Added a section describing the possibility to add user defined parametersto MDF files. • Added a description for optional and non-optional groups and conditional,optional, and non-optional datasets. • Added a short section on the code examples on the Github repository. • Support for triangle wave forms has been added. • Support for multiple excitation frequencies on a drive-field channel hasbeen added. • Added the dimension A to all fields of the tracer group to be able to de-scribe settings where multiple tracers are used or tracers are administeredmultiple times. • Added the possibility to store the tracer concentration also for non ironbased tracer materials by adding the /tracer/solute field and redefiningthe field tracer/concentration . • Improved documentation for the storage of ADC transfer functions. It isalso possible now to store the measurement data as integer data and usea dataConversionFactor to describe the mapping to a physical represen-tation (e.g. Volt) • Added support for receive coil to ADC transfer functions. • Added support for mean magnetic moment to receive coil voltage transferfunctions. • Split the /study group into the /experiment group and the study group.This allows to provide more fine grained information on study and exper-iment. • Added possibility to mark the overscan region. • Added new section changelog to the MDF documentation to record thedevelopment of the MDF. • Updated
README.md and
MDF.bib in the github repository. • Updated code examples in the github repository. • Added a section on the MDF reference implementation MPIFiles.jl. Sincesanity checks will be covered by this package, the description on sanitychecks has been removed.14 .2 v1.0.5 • Added the possibility to store different channels of reconstructed data. • Added support for receive channels with different characteristics (e.g.bandwidth). • Made dataset /acquisition/receiver/frequencies optional. • Extended the description on the data types, which are used to store data. • Added references for Julia and HDF5 to the specifications. • Clarify that HDF5 datasets are used to store MPI parameters. • Updated Affiliations in the MDF specification. • Included data download into the Python and Matlab example code. • Changes in the Python and Matlab example code to be better comparableto the Julia example code. • Added reference to arXiv paper and bibtex file for reference. • A sanity check within the Julia code shipped alongside the specifications. • An update to the specification documenting the availability of a sanitycheck. • • Updated documentation to the Julia, Matlab and Python reconstructionscripts. • Improved Julia reconstruction script, automatically downloading the re-quired MDF files.
References
Nature , 435(7046):1214–1217, 2005.[4] Jeff Bezanson, Stefan Karpinski, Viral B. Shah, and Alan Edelman. Julia: A fast dynamic language for technical computing.
CoRR , abs/1209.5145, 2012.[5] Jeff Bezanson, Jiahao Chen, Stefan Karpinski, Viral B. Shah, and Alan Edelman. Array operators using multiple dispatch: a design methodology for arrayimplementations in dynamic languages.
CoRR , abs/1407.3845, 2014.[6] Jeff Bezanson, Alan Edelman, Stefan Karpinski, and Viral B. Shah. Julia: A fresh approach to numerical computing.