add microscopic information describing tracer for simulations

[hofmannmartin]

This issue is based on a sub issue raised in #41 by @MandyA.

• In the group tracer it might make sense to specify a diameter of the tracer. This would be helpful, if the data was acquired by simulation.

I think this could be done, but would require a good specific proposal as to which parameters should be stored. The microscopic details should be stored in a separate optional group/subgroup. @MandyA and @profix898 might be the right candidates to think of a prototype for post v2.0.0 releases.

[Neumann-A]

From my simulation code (not all options are shown, some are not needed for some options and thus not generated. And some options are not yet used):

Simulation_Settings.ini:

[Field_Properties]
Amplitude_1 = {0.000000000000000e+00, 0.000000000000000e+00, 0.000000000000000e+00}
Amplitude_2 = {2.000000000000000e-01, 0.000000000000000e+00, 0.000000000000000e+00}
Frequency_1 = 2.500000e+04
Number_of_Amplitudes = 2
Number_of_Frequencies = 1
Number_of_Phases = 1
Phase_1 = 0.000000e+00
Type_of_field = 'sinusoidal'

[Particle_Provider]
Save_individual_particle_settings = TRUE
Use_discrete_distribution_to_select_particle = TRUE

[Particle_Provider.Particle_List]
Particle1 = 'Par1.ini'
Particle2 = 'Par2.ini'

[Particle_Provider.Particle_Numbers]
Particle1 = 100
Particle2 = 1000

[Particle_Provider.Used_Particle_Numbers]
Particle1 = 0
Particle2 = 0

[Problem_Settings]
Problem_type = 'BrownAndNeel'
Use_simple_model = FALSE

[Result_Settings]
Normalize_results = TRUE
Save_intervall = 1
Save_single_name_prefix = 'Simulation'
Save_single_simulations = TRUE
Savefile = 'Results.mat'
Savefile_Type = 'MAT'
Single_simulations_savefile = 'ResultsSingle.mat'
Use_extra_file_for_single_simulations = FALSE

[Simulation_Settings]
Number_of_simulations = 10
Number_of_simulators = 1
Number_of_steps = 10000000
Oversampling = 100
Simulator_type = 'AllSingle'
Timestep = 1.000000e-11

[Solver_Settings]
Solver = 'EulerMaruyama'

My Systemmatrix_Settings: (would be absorbed into some already exisitng settings):

[System_Matrix_Settings]
Slices = {2, 2, 1}
Startfield = {-2.000000000000000e-03, -2.000000000000000e-03, 0.000000000000000e+00}
Stopfield = {2.000000000000000e-03, 2.000000000000000e-03, 0.000000000000000e+00}
Use_start_stop_Voxel = FALSE

One of my Particle settings:

[Particle_Properties]
Temperature = 2.950000e+02

[Particle_Properties.Hydrodynamic_Properties]
Hydrodynamic_Radius = 8.000000e-08
Viscosity = 1.000000e-03

[Particle_Properties.Magnetic_Properties]
Anisotropy_1 = 5.000000e+04
Damping_constant = 1.000000e-01
Gyromagnetic_ratio = 1.760000e+11
Magnetic_radius = 1.532600e-08
Number_of_anisotropies = 1
Saturation_magnetisation = 4.774640e+05
Type_of_anisotropy = 'uniaxial'

[Particle_Simulation_Initialization]
Initial_particle_position = {0.000000000000000e+00, 0.000000000000000e+00, 0.000000000000000e+00}
Use_random_initial_particle_magnetisation = TRUE
Use_random_initial_particle_orientation = TRUE
Use_random_initial_particle_position = FALSE

[Particle_Simulation_Settings]
Anisotropy_constants_distribution_type = 'lognormal'
Anisotropy_constants_distribution_width = {5.000000e-01}
Hydrodynamic_shell_distribution_type = 'lognormal'
Hydrodynamic_shell_distribution_width = 2.500000e-02
Magnetic_radius_distribution_type = 'lognormal'
Magnetic_radius_distribution_width = 5.000000e-02
Use_relative_distribution_width_for_anisotropy_constants = TRUE
Use_relative_distribution_width_for_hydrodynamic_shell = TRUE
Use_relative_distribution_width_for_magnetic_radius = TRUE

[hofmannmartin]

You particle settings seem to be a good starting point :+1:.

Two suggestions for generalizations

• Temperature could be dependent on the spatial position
• distributions could be multi modal
• We would need specification for the coordinate system in which Initial_particle_position is specified.
• The particle distribution could be time dependent

I think as soon as we hit v2.0.0 we can start working on this issue on a new branch. Is this OK @NeumannIMT.

[Neumann-A]

Temperature and viscosity should be moved into a different group called enviroment or something like that.

I dont think time dependet particle distrubtion are needed because you dont want to do a full blown particle movement +rotation and magnetization dynamics simulation. Main focus should lie on simulation of system matrices or something similar and from there you can build up phantoms or other things.

Initial_particle_position is not used (and maybe never will). I simply use the offset field to describe where the particle is. There are also the fields Initial_particle_orientation and Initial_magnetization_direction which are not shown due to them being set to random.

By definition distributions for one particle are monomodal. The simulation can handle multi modal distrbution by using different particles. Thats what this is for:

[Particle_Provider.Particle_List]
Particle1 = 'Par1.ini'
Particle2 = 'Par2.ini'

most of the settings would be moved into /detail/ because they are not helpful for anybody

I also have the settings in a v7.3 mat file. Could try to directly write it into a hdf5 file to try out my hdf5 wrapper but i think i am still missing support for eigen3 types in containers with those wrappers.

Post v2.0.0 is okay but @MandyA might use totally different settings

[hofmannmartin]

Temperature and viscosity should be moved into a different group called enviroment or something like that.

subgroup :+1:

I dont think time dependet particle distrubtion are needed because you dont want to do a full blown particle movement +rotation and magnetization dynamics simulation. Main focus should lie on simulation of system matrices or something similar and from there you can build up phantoms or other things.

I am not so sure that there is no one out there considering dynamic phantoms. I think the aim should be to have a quite general description which covers more than a hand full of special scenarios.

Initial_particle_position is not used (and maybe never will). I simply use the offset field to describe where the particle is. There are also the fields Initial_particle_orientation and Initial_magnetization_direction which are not shown due to them being set to random.

I thought this parameter describes the particle distribution not the position of a single particle. So what is required is a way to describe the phantom. I.e. the ground truth of the particle distribution.

By definition distributions for one particle are monomodal. The simulation can handle multi modal distrbution by using different particles.

I see. that is how you handle it internally in your framework. It might be a good idea to be a bit more abstract in the MDF and allow the direct description of multimodal distributions.

Post v2.0.0 is okay but @MandyA might use totally different settings

As long as the final specifications support both of you and at best all the others, who perform simulations that is not an issue.

[Neumann-A]

I am not so sure that there is no one out there considering dynamic phantoms. I think the aim should be to have a quite general description which covers more than a hand full of special scenarios.

I am simulating moving magnetic particles which move on a lissjaous trajectory in a static inhomgoneous magnetic field ;). It basically boils down to the applied field sequence. It does not matter if the particles move or not if the field sequence the particle exhibit is correct. (Everything else is just more unnecessary parameters to describe the underlying problem -> /detail/)

I thought this parameter describes the particle distribution not the position of a single particle. So what is required is a way to describe the phantom. I.e. the ground truth of the particle distribution.

Simulate single pixels and superimpose them to a phantom (or system matrix). If you want to have different concentrations use a weighting factor to superimpose them. You are thinking too much in images. The phantom itself would currently be stored in a reconstruction as ground truth. (maybe allow named reconstructions?)

I see. that is how you handle it internally in your framework. It might be a good idea to be a bit more abstract in the MDF and allow the direct description of multimodal distributions.

The approach is modular and I think that is what you want here. Any multimodal distribution will be a sum of monomodal distributions. But if you have another idea feel free to tell me.

[hofmannmartin]

I am simulating moving magnetic particles which move on a lissjaous trajectory in a static inhomgoneous magnetic field ;). It basically boils down to the applied field sequence. It does not matter if the particles move or not if the field sequence the particle exhibit is correct. (Everything else is just more unnecessary parameters to describe the underlying problem -> /detail/)

That is indeed a smart thing to do :+1:. My point is that the simulation description provided within a MDF should be independent of the simulation framework and as descriptive as possible. Therefore I want to describe the particle distribution independent from the fields.

That in the end it makes sense to calculate the effective field dynamic the particles experience is an issue of the simulation framework not of the MDF.

Simulate single pixels and superimpose them to a phantom (or system matrix). If you want to have different concentrations use a weighting factor to superimpose them. You are thinking too much in images. The phantom itself would currently be stored in a reconstruction as ground truth. (maybe allow named reconstructions?) The approach is modular and I think that is what you want here. Any multimodal distribution will be a sum of monomodal distributions. But if you have another idea feel free to tell me.

Maybe I got it wrong. In your framework you need one configuration file per point of your phantom times some number to account for multi modal distributions am I correct? Can you maybe provide a rough structure of how you want to map this into the /simulation/ group as a basis for discussion. Maybe I simply misunderstand what you are trying to do. Thanks.

[profix898]

@NeumannIMT: How does this relate to https://github.com/MagneticParticleImaging/MDF/issues/43? Seems your are both heading in the same direction.

[hofmannmartin]

Indeed @MandyA brought up this issue in #43 and #41. I think both issues have to be resolved at the same time, since we anyways should use a new group to store all these values.

[MandyA]

Indeed @MandyA brought up this issue in #43 and #41. I think both issues have to be resolved at the same time, since we anyways should use a new group to store all these values.

I agree, let combine these two requests in one group.

Post v2.0.0 is okay but @MandyA might use totally different settings

I assume that all things I need are included in you simulation. If you can provide a first draft of the group I am happy to discuss further features.

I am not so sure that there is no one out there considering dynamic phantoms. I think the aim should be to have a quite general description which covers more than a hand full of special scenarios.

Just to be sure: you are not referring to phantoms that change over time? That is something we actually use and need for simulations.

[hofmannmartin]

Just to be sure: you are not referring to phantoms that change over time? That is something we actually use and need for simulations.

I was referring to phantoms that change over time.

[MandyA]

Ok. So, why not use dynamic phantoms? I would have expected something similar to reconstruction data, i.e. L x M with L the different time points of the measurement.

[hofmannmartin]

I think this is a misunderstanding. I was promoting the idea that the MDF should be able to handle dynamic phantoms.

[Neumann-A]

I would have expected something similar to reconstruction data.

Dito

dynamic phantom -> movie of phantom similar how you get a movie of reconstructed images. Just a sequence of different frames.

[MandyA]

Ah okay. Sorry for the confusing. Then we all agree :)