Defining Parameters for sufficiently accurate Field Simulation

[hofmannmartin]

@gBringout proposed to extend the specifications, such that single sided scanners can be described in #18.

@gBringout could you make a list of things which are not covered by our current specifications (v1.0)?

[gBringout]

Sorry for the delay. It took quite a long time to set up my mind on those subjects.

This issue is directly linked to #17 and #18.

I would like to introduce a differentiation between scanners. As far as I know, for all scanners, all the time related parameters are the "same" and can be described in a similar way. Repetition, number of time point or frequencies etc. And it is good to check them. It can be done in the same way for all scanners.

But all the one related to the field topology (gradient strength, FoV, drive field strength) are strongly dependent on the type of scanner. (I haven't found any proof yet of what will follow (and if anybody has one, please let me know), but I have made several numerical validations (from simulated fields and measured ones)). The concept of a single value describing the gradient and drive field strength is related to the ability to decompose the field in a base, for example of Spherical Harmonics (see [https://github.com/gBringout/SphericalHarmonics](Spherical Harmonics Package). In this base, one value (or a small amount of values, likes 2, 3 or 4) can be used to described an idealized field, deviating by only a few percent from the actual one. In other words the decomposition in this base can be approximated by a small and finite number of coefficients which converge to zero for higher degrees (typically, the coefficient of degree 3 is smaller than of degree 2 and so on). But, the huge difference between scanners, is that it does not always works. The set of coefficients can display oscillations and/or are not converging to zero. For such scanner, the idea of gradient strength is then (in the way I understand it) undefined, and a lot of information have to be provided in order to approximate it. For such cases, the concept of gradient and drive field strength are then not precisely defined

It is easier, I think, to then divided the scanner in either 2 or 3 types than to find a precise way to describe those exotic scanners.

So, we have the scanners with cylindrical coils, with a useful volume in the centre of the cylinder. Those can be perfectly described with what is called at the moment the gradient strength and the drive field amplitude.

We have the scanner with flat coils, like in the single sided scanners. Those cannot be easily described by such concept.

And we have the "hybrid" scanner, as the Human prototype from Philips. This one could be described (if the coil from both side are used in a "good" way) by a small number of coefficient, or not (if only one side is used for example).

So, in order to integrate the single-sided scanner and other "exotic" scanners, I would recommend to add a parameter, "scannerType". It will influence the Checks, to make all field topology checks optional for scanner using coils other than cylindrical one.

What do you think?

[gBringout]

Any comments @MandyA @profix898 @hofmannmartin @tknopp ?

[tknopp]

I agree with all what you have said Gael. But it is less clear what we should do here. A scannerType field of course makes sense. But if we start integrating detailed coil topology descriptions it could soon get pretty complicated. I am not in principle against this but the designing is not easy.

So the suggestion is to introduce scannerType and make DF and gradient optional if an "inhomogeneous" scannerType is chosen? I would be fine with that.

[gBringout]

If you and other agree and think it make sense, I can start to draft some specifications. As you said, it will not be trivial, so I prefer to have some feedback before investing too much time in this :)

The idea is indeed to have a scannerType and make some fields and calculation optional, depending on the value of this fields.

The exact value of scannerType has still to be found and should cover at least the existing scanners. I oscillate at the moment between "homogeneous/inhomogeneous/hybrid", "cylindrical/open/other" and "finite SHSE/infinite SHSE" (SHSE : spherical harmonics serie expansion".

Gaël Bringout

2016-09-11 12:32 GMT+02:00 Tobias Knopp notifications@github.com:

I agree with all what you have said Gael. But it is less clear what we should do here. A scannerType field of course makes sense. But if we start integrating detailed coil topology descriptions it could soon get pretty complicated. I am not in principle against this but the designing is not easy.

So the suggestion is to introduce scannerType and make DF and gradient optional if an "inhonogeneous" scannerType is chosen? I would be fine with that.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/MagneticParticleImaging/MDF/issues/21#issuecomment-246173309, or mute the thread https://github.com/notifications/unsubscribe-auth/AFt1gmZdLDXQbS43b59py5sCY7rvR5TAks5qo9ijgaJpZM4HRQOO .

[MandyA]

I would welcome if you propose a specification.

For the scannerType I like the idea of "cylindrical/open/other", but I think I would prefer the naming "closed/open/other", which would do fine with the scanners used at the IMT. However, I'm unsure how to categorize TWMPI-scanners with this concept.

[tknopp]

I have thought a little longer about your proposal Gael and would like to understand what issue it aims to solve. Is the main issue that gradient and dfStrength are not defined for single sided scanners? I see a way that is independent of scannerType:

1. we could make the field parameter optional. They are not really needed and we already have the freedom to chose the DF FoV independently of gradient and DF strength
2. We could define that the gradient and field hold at the scanner "center" where center could be a defined point (i.e. for a single sided scanner this is the FFP when no field is applied)

This is nothing in principle against scannerType but I would see scannerType more like an informative parameter and nothing where other parameters depend on. Our scanner would for instance also not fit into cylindrical because it is very inhomogeneous when we measure a little bit off center.

[hofmannmartin]

I think the main intention behind fields like gradient is the reproducibility of measurements. Therefore I think it is not all that important to precisely know the field. Important is the ability to reproduce the measurement conditions (field) with a scanner of the exact same type.

Furthermore, @gBringout seems to want to address the issue that the ideal fields which are described and the actual fields in the measurement do not coincide. One could resolve this issue by providing the current driving the individual coils (static and oscillating) instead of an idealized field, which in turn describes the field only in the centre. In principle this is what we do at the moment. The problem is that our decision to provide gradient and dfStrength only works for a limited set of possible scanner types.

The real fields can then be obtained if the coil sensitivities are known, which could be provided using optional fields. This would then in turn allow to accurately simulate a given scanner configuration.

[gBringout]

Well, I think that we need the scannerType parameter to address all your points. The mains issue is that we are using undefined words to describe systems, which leads to misunderstanding and errors. Like "gradient" and "field strength" which are used

• either to describe MF at a given point and are only true at this point (and then we should properly defined this point in accordance to each coil of the scanner to be able to sort the influence of each coil on this value at this point)
• to refer at the stronger idea of field generator generating MF with a very strong 0th degree or 1st degree.

On the long run, clarifying all those points could allows me to use this data format for my simulation framework. It could also simplify the description of the scanners and allow better "quick" description.

Seeing your comments, I tend to the solution enabling the "SHSE" or "infinite SHSE" values for scannerType. Some points why:

1. A scanner is a sum of magnetic field (MF) generators which are described, in a useful volume, using SHSE. This is true for all MPI scanners.
2. For each generators, this series expansion is either finite (considering a given measurement uncertainty) or infinite. This is true for all MF generators.
3. For an infinite SHSE, any truncation will lead to significant differences of the MF amplitude between the approximated value and the real one. Moreover, the values are not easy to interpret.
4. For an infinite SHSE, it is probably better to exchange either the wire model of the ideal current-carrying path or a mapping of the field value in the volume.
5. For finite SHSE, the exchange of a few coefficients (~150) is enough to offer really good model of "simple" MF. Simple is here understood as mainly dipole or quadrupole fields. No MF of the 45th order and/or degree :). This should also cover the case of Tobias and the off-centre measurement (assuming your are speaking from the Bruker scanner). The Bruker scanner should perfectly fit in the "cylindrical" or "finite SHSE" type.
6. Using SHSE description, the definition of "gradient" and "field strength" is a bit clearer. Those are the 0th degree 0th order coefficient of the main direction. The deviation to those limits of off-center case will then depends on the distance to the center and the amplitude of the coefficient of higher degree.
7. The parameter could be made optional. For me this means that the gradient and dfStrength values are in general undefined and that their definition should be clarified somewhere. We could here imagine something like "finite SHSE"/"infinite SHSE"/"other"
8. The value actually used to reproduce the experiments are only valid on a single scanner type. They should perhaps be better defined if we want to move towards model based reconstruction or model-assisted reconstruction. Using a more accurate description could allow the comparison with other scanner, like FFL scanners.
9. The difference then between ideal fields and actual/realistics fields is not that big. I would always defined the gradient and dfStrength values according the the degree, which should not varies that much between both way to describe a scanner. Integrating a further variable, like ScannerModelType which could be set either to ideal or realistic could address this difference. This could help to quickly make ideal model of scanner available and then refine them. Like what I did in the thesis.

tl;dr: scannerType could simplify the use of the format for simulations and we could use the occasion to have a better definition for crucial terms like gradient and dfStrength.

[tknopp]

I have changed the title to the actual purpose of storing enough data to perform a field simulation. This is an interesting aspect ( in particular for model based reconstruction ) but there are also various different options to do that. For instance one can store the SH coefficients, the coil geometry, or the coil sensitivities. I personally do not know which is the best option.

Regarding the definition of the terms gradient and fieldStrength we may just have to specify the position in space where this holds. If this is given, both terms are perfectly defined even without any series expansion. gradient are simply the spatial derivatives of the field components in the three room directions. The issue is: How to define this point?

[hofmannmartin]

It seems we are discussing two separate issues here. One is related to the way measurement fields are described and one is related to a full field description for simulations.

Regarding the definition of the terms gradient and fieldStrength we may just have to specify the position in space where this holds. If this is given, both terms are perfectly defined even without any series expansion. gradient are simply the spatial derivatives of the field components in the three room directions. The issue is: How to define this point?

At least for FFP scanners such a definition is easy. We already have the fieldOfViewCenter within or specifications. We could alter the definition of gradient and fieldStrength such that both are field properties within this point. Due to way FFP scanners are build there is only one field setting to provide this gradient within this point.

[gBringout]

For me this is not only related to scanner simulation, but to the way scanner and acquisition are described.

Taking the single scanner as example, which is a FFP scanner, giving the a gradient and a field strength at a given point is not enough to precisely describe the scanner. From those two informations, any "FFP Field of View" or related information could not be calculated precisely. Moreover, extending the number of point required to describe a field goes in the SH directions.

If we want to be able to clearly store informations about an acquisition which is done on other scanner than Bruker's, a better scanner description, and thus, a better magnetic field description has to be used. And something like the scannerType could be the beginning of this description.

[hofmannmartin]

Taking the single scanner as example, which is a FFP scanner, giving the a gradient and a field strength at a given point is not enough to precisely describe the scanner.

I agree that the two parameters gradient and fieldStrength might be insufficient to describe anarbitrary scanner. As a general notice the informations provided within the mdf files should enable us to reproduce a measurement insead of proving a complete description of a scanner. This is the main point of the format. And at least for Bruker scanners the two fields provided are sufficient to do so.

From those two informations, any "FFP Field of View" or related information could not be calculated precisely. Moreover, extending the number of point required to describe a field goes in the SH directions.

For exactly this reason we store the fieldOfView within the format.

In general I admit that the knowledge of SH helps for simulations, or if you want to build a similar scanner, but I think that they are just too much for non technical operators of MPI scanners. These will see MPI as some sort of black box and want to measure without knowing all the details about SH. In this regard we should also keep in mind that the solution to the problem (describing the scanner settings) should be as simple as possible.

Additionally, I would like to mention, that we already have three fields manufacturer, model and topology, which can be used to describe a scanner. For which reason do we need the field scannerType?

[gBringout]

Ok, I took more time to think about it, and I agree with @hofmannmartin that the format is not suited for what I would like to do.

Thank you for your contribution and time! I will try to find some other solution for what I need.

[hofmannmartin]

Thanks for the discussion on this issue.

This issue can be closed since the discussion came to a conclusion without any further work to be done.