Question about VMAT branches

[chh105]

I had a question about the various VMAT branches (i.e. dev_VMAT_merge, dev_VMAT, dev_4DVMAT, etc.). I'm hoping to pick one to use for a research project and was wondering which of these branches would be the best option. It seems the dev_4DVMAT one is the most up-to-date (according to what I was told in a previous github post), though the file structure is completely different from the master branch of matRad. Other branches like dev_VMAT_merge have similar file structures to the master branch but may not be as up-to-date (?).

Is there a working branch for VMAT that you guys would recommend? As always, thanks for your help and advice!

[eric11210]

Sounds good.

I don't think I ever went below ~28 degrees for the FMO spacing, so no I have not noticed that. I'm a little surprised by that, to be honest. What do you mean by not converging? Can you post an image of the obj function versus iteration?

[chh105]

Sure I'll try to reproduce the behavior and upload a picture tomorrow

[chh105]

Sorry for the delayed response. I've noticed that the issue when performing FMO might be caused by a mistake I made with the FMO angle sampling. Initially I was using an offset of 362 for all the angle sets (half of the dao and dose angle spacing). I think this places the FMO beams pretty much right on top of each other which may be an issue for the optimizer as the number of variables becomes large (large number of beams). I'm thinking it might be better to use an offset of 376 (360 + 2 + 14) for all of the angle sets.

[chh105]

Hi again, just wanted to post another update. I'm currently wrapping up a project that performs automated treatment planning using the dev_VMAT branch. I just wanted to thank you all for the help and advice that you've given me, especially with the problems posted in this github thread. I've also released the source code for that project, so feel free to check it out. Cheers

[eric11210]

Great, happy to help @chh105. I'm glad to see VMAT being used in matRad!

[Boomxx07]

Hi all, in regards to the VMAT branches has the DICOM importer been updated to support VMAT DICOMs on any of them?

I'm currently using the dev_VMAT_merge branch and am having trouble importing a VMAT RT-Plan.

[wahln]

From our side, we haven't bothered with it yet. Maybe @eric11210 has tried something in this direction? I have just tried it myself with an old Raystation VMAT RTPlan and ran into some issues in matRad_importDicomSteeringPhotons. I will check it out for a few mins, maybe the fixes are trivial for starters, otherwise @amitantony and I would be happy to assist with getting this to work if you are also open to contribute some investigative DICOM & coding work.

[wahln]

I have just pushed a fix in 98bafb62e28fd2877e5b8efcaa20573d5ac37448 that solved a basic import problem for me. I can, now, import the plan, but not in the format the VMAT branch expects for futher calculations (basically, I just get an IMRT plan with huge amount of gantry angles etc.). But let me know if this fix allows you to import your RTPlans as well without throwing errors. If not, please let us know what is going wrong.

[chh105]

@Boomxx07 I can't remember if the dicom importer for the dev_VMAT_merge branch was working (it has been a while since I last tried). However, if you are ok with using an older branch like dev_VMAT, importing should be working for CT images and RT structures. There's also a function (linked here) that will import those dicoms for you if you specify the filepath, voxel size, beam width, etc.

[Boomxx07]

Hi both, thank you for your quick replies.

@wahln I still don't seem to be able to import my RTPlans, specifically the issue appears to be in the same area where you put in the fix. The number of isocentre values in pln.propStf.isoCenter is 2 (I have a 2 beam VMAT RT Plan), however, the loop ~line 56 of matRad_importDicomSteeringPhotons is trying to go much higher (as each beem has 178 control points). I think line 82 of matRad_importDicomRTPlan would need to be modified to generate a bigger list of isocentres? What type of RTPlan were you importing with success?

@chh105 I had a look at dev_VMAT, however, I'm trying to import an RTPlan which and not just CT/Struct.

[wahln]

I imported a single-arc VMAT plan, which allowed me to just import all control points as gantry angles with the same isocenter.

First, as you said, I think the problem is that you seem to have two "arcs", right? my fix was only a workaround for single arc. Here we might need to look into matRad_importDicomRTPlan.m as well to better isolate the import of BeamSequence and ControlPointSequence for photons in case of VMAT. However, I don't have multi-arc VMAT DICOM RTPlan right now.

Second, I think the branch does not (yet) have the code infrastructure to support multiple arcs natively. The "easy way" forward would be to import them as to seperate pln & stf objects in matRad for the start, or just put all in one, assigning the correct isocenter in the import.

Last, there should be no substantial difference in the DICOM importers on those branches.

[eric11210]

@Boomxx07 @wahln I did not do any work on the DICOM import when I implemented VMAT in matRad, so unfortunately there is no guarantee that anything will work correctly when trying to import a DICOM RT plan.

[Erhushenshou]

Hi Guys, Upon reading the posts above, is it right that we can do vmat in matrad right now? Is is released?

[wahln]

No it is not released, but you can try out the branch. dev_VMAT_merge.

[chh105]

Hi @wahln @eric11210 , I had a quick question about recalculating dose. Say that I have finished running DAO and my matlab workspace now has all of those relevant outputs (dij, resultGUI.apertureInfo, etc.). If I wanted to compute the contribution of each VMAT control point to the dose distribution, how would I go about doing so?

[eric11210]

I would set all of the weights of each control point in the resultGUI.apertureInfo.apertureVector to 0, except for the one that you're interested in. Do you know the structure of the apertureVector? If not I can give you more information on that.

Next I would update the apertureInfo and calculate the bixel weights: resultGUI.apertureInfo = matRad_daoVec2ApertureInfo(resultGUI.apertureInfo,resultGUI.apertureInfo.apertureVector);

Next update the bixel weights in the resultGUI: resultGUI.w = resultGUI.apertureInfo.bixelWeights;

Finally, recalculate the dose: resultGUI = matRad_calcCubes(resultGUI.w,dij);

Let me know if that works.

[chh105]

@eric11210 thanks so much for the explanation. My only confusion right now is how the apertureVector is structured. For instance, right now I have a plan that has 120 control points and a 9436x1 apertureVector. If I just want to keep the contribution from control point 3, for example, which part of the apertureVector should I zero out

[eric11210]

If you have 120 independent (DAO) control points, then the first 120 elements of the apertureVector correspond to the weights of those control points, in order. The next big chunk correspond to the leaf positions, and at the end are the time intervals between control points.

So if you want to see the contribution from control point 3 only, then you would zero out all of the first 120 elements, except for the third element.

I would verify that this was done correctly by checking the results in the apertureInfo structure, after you've updated it using the line: resultGUI.apertureInfo = matRad_daoVec2ApertureInfo(resultGUI.apertureInfo,resultGUI.apertureInfo.apertureVector);

[chh105]

So far I'm able to run everything except the matrad_calcCubes function without issue. When I run the matRad_calcCubes function, it asks for options.optBixel, and I'm not sure what that refers to. Is it part of some structure like the pln or resultGUI?

[eric11210]

Maybe try this instead of the calcCubes function: d = matRad_backProjection(resultGUI.w,dij,options); resultGUI.physicalDose = reshape(d{1},dij.dimensions);

You can also set optBixel using: options.optBixel = true(dij.totalNumOfBixels,1);

[wahln]

Also please consider that the function calls changed on the _merge version a little bit, as they are integrated into the object-oriented optimization framework now. I don't know which one you are using at the moment. I can update you on the syntax for this end of this week.

[chh105]

Thanks again. I'm currently using the dev_VMAT branch. After further inspection of the calcCubes and backProjection functions, I think that the options structure refers to the optimization options:

options.radMod          = pln.radiationMode;
options.bioOpt          = pln.propOpt.bioOptimization;
options.ID              = [pln.radiationMode '_' pln.propOpt.bioOptimization];
options.FMO             = false; % let optimizer know that this is FMO
options.numOfScenarios  = dij.numOfScenarios;

Also it seems like both backProjection and the calcCubes function produce the same dose distribution. Is there any reason why I should use one over the other in this case?

[eric11210]

No, I would expect both the produce the same dose distribution in this case. I think calcCubes actually calls backProjection, if I remember correctly.

[chh105]

Sure, sounds good. Also as a sanity check, I computed the physicalDose cubes for each control point, as well as the sum of all the dose cubes. The sum seems to be equivalent to the original overall dose distribution, so I think it's working. Is there any other sanity check I can try running?

[eric11210]

That's an excellent idea for a sanity check :)

Another thing to do might be a visual check. Try loading in an image of the dose for each control point, and verify that it looks like a beam coming in from the correct gantry angle, based on your VMAT arc settings.