feature_dicom: Reading of DICOM files and implementation of the CT in BDSIM

[Eliott Ramoisiaux]

The following issue contains relevant material for conversion of CT DICOM images to voxelized geometries into BDSIM.

[Nathan Farber]

Here are the different input files that allow the example to work

[Nathan Farber]

PowerPoint presentation that was held on 29/03/2021

[Laurie Nevay]

I have edited the branch “feature_dicom” to move the relevant code into bdsim/modules/dicom and edited the cmake appropriately. I also added preprocessor if defs to the component factory so we can build without the dicom module on (controlled by USE_DICOM).

I made some edits to fix header includes and match the code base style as well as put in the various licences we need to have.

I have some concern about the dicom code from the Geant4 example as it has a lot of code smells. Certainly, some basic things can be fixed such as initialising all the class members in the constructor. It seems a little unfinished. Obviously, it works to a degree, but I do think it should be improved if we’re going to use it. Smells: exceptionally large functions; huge level of nested ifs (many inside double for loops), unnecessary level of print out for debug and verbosity.

Todo:

• (Laurie) allow placement anywhere of a bdsim component as opposed to just a piece of GDML

‌

[Cédric Hernalsteens]

Thanks @Laurie Nevay !

I agree that the code needs to be improved and cleaned. Also, your to-do is something that will be really helpful! Maybe it is somehow related to secondary beamlines?

A few other to-dos that I propose:

• @Eliott Ramoisiaux @Nathan Farber I fear that your latest code was not pushed here. Please merge, rebase or cherry-pick your most recent commit on the latest commits on “feature_dicom” from Laurie. We must make sure that your contributions to follow are on top of the changes from Laurie.
• Then we can start cleaning-up the code as suggested in the previous comment.
• @Eliott Ramoisiaux please coordinate with @Laurie Nevay to update the documentation in the branch, document the “USE_DICOM” build variable, etc.

‌

[Laurie Nevay]

I’ve now implemented the placement of a single bdsim component. In the placement you can use the parameter

bdsimElement="nameOfComponent"

to specify the name of a component defined in the input. This can be an active (with field) or passive component all the same. I’ve updated the develop manual also:

http://www.pp.rhul.ac.uk/bdsim/manual-develop/model_customisation.html#placements

@Cédric Hernalsteens Multiple beam lines are actually a bit more difficult. Here, I just clone the container volume and place it at the same place in a parallel world. I have a special navigator class for that world for the global transform of the field. In the case of a real beam line, I use a series of cylinders and also two parallel worlds (one for the bridging components) to ensure an accurate transform at the boundaries. It’s on the todo list. To do this, I’ll have to make the auxiliary navigators be given an ID for which pair of parallel worlds to use for curvilinear transforms. This shouldn’t be too bad. The real work is in making the beam lines connect geometry-wise and also the coordinate systems - see Issue #261 where we’re keeping a list of ‘consequences’ / things to implement.

‌

[Cédric Hernalsteens]

@Laurie Nevay Thanks for the info.

@Eliott Ramoisiaux @Nathan Farber Please follow on my previous comment and make sure to test Laurie’s implementation. This is probably the best way to go for the placement of a “CT”, so the documentation on this new feature should also explicitely mention it.