Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multimodality or Multi-ion radiotherapy (MIRT) implementation #731

Open
ktkaamir opened this issue Jun 12, 2024 · 4 comments · Fixed by #709
Open

Multimodality or Multi-ion radiotherapy (MIRT) implementation #731

ktkaamir opened this issue Jun 12, 2024 · 4 comments · Fixed by #709
Assignees
Labels
question stale Automatic label for stale issues

Comments

@ktkaamir
Copy link

Hello! I hope you're doing well. I'm interested in Multi-ion radiotherapy (MIRT) and would like to know if it's possible to use Matrad for creating MIRT plans. Is there a way to implement this?
regards
ameer

@wahln
Copy link
Contributor

wahln commented Jun 13, 2024

There's work for joint optimization on the branch https://github.com/e0404/matRad/tree/dev_MixedModality mainly led by @amitantony and contributions from @tobiasbecher and @remocristoforetti .
While originally built optimizing multiple modalities spread across fractions, it can in principle also be used for multi-ion optimization within a fraction. But @amitantony, @tobiasbecher and @remocristoforetti have a better overview over the code than me, and it is not well documented yet.

@wahln
Copy link
Contributor

wahln commented Jun 19, 2024

I would like to add that one could hack multi-ion pllaning into matRad quite easily, as matRad precomputes alpha*dose and sqrt(beta)*dose matrices for optimization and then does not care anymore about the modality stored in them:

  1. Think about a plan setup (i.e., gantry and couch angles, number of fractions, etc.) and the ions you would want to use. matRad's dev branch currently has proton, helium and carbon generic machines that are usable.
  2. For each of the modalities, independently run matRad_generateStf and matRad_calcDoseInfluence. If you use protons, helium, carbon, you would end up with three dij-structs.
  1. Now comes the hacking: Combine the three dij-structs into one. That is, all the influence matrices (e.g. dij.physicalDose, dij.mAlphaDose, dij.mSqrtBetaDose need to be horizontally concatenated into one). The resulting matrices have the number of columns equaling the sum of spots of all modalities, thus you need to edit some of the other metadata in dij to reflect this (e.g., totalNumberOfBixels as well as the vectors beamNum, rayNum, etc. that map bixel indices to beams.
  2. You can now run a standard optimization based on effect or RBExD. The optimization only cares for the mAlphaDose and mSqrtBeta dose contents and doesn't care about the actual modality used at this point, so you can just provide to it a pln-struct with radiationMode set to carbons.
  3. You will end up with a resulting effect and a spot-weight map. Now you can reverse engineer the individual ion contributions by multiplying the individual matrices with the part of the spot weight map that belong to that modality (or multiply the giant matrix with the spot-weight vector set to zero for spots of the other modalities).

A sustainable implementation should look different:

  • Allow multiple radiationModes to be set directly in the pln.
  • Automatically call the different dose calculation algorithms and combine the matrix.
  • Automatically calculate the individual ion contributions after optimization.
    As said, the branch https://github.com/e0404/matRad/tree/dev_MixedModality does that to some extent, but it targets joint optimization across different fractions.

@amitantony
Copy link
Contributor

Hi @ktkaamir, so @wahln has given a very comprehensive guide above,
but would be easier to help if we had some information into what direction you would like to head in.
eg. multiple ions over entire treatments (single ion fractions) vs MIRT within a fraction etc.

Copy link

github-actions bot commented Jul 6, 2024

This issue was automatically marked as stale because it has been sitting there for 14 days without activity. It will be closed in 14 days if no further activity occurs.

@github-actions github-actions bot added the stale Automatic label for stale issues label Jul 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question stale Automatic label for stale issues
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants