Asymmetries in Beam Profiles Calculated with AAA13

A very old bug in the AAA algorithm of Eclipse still waits to be fixed1. We ask ourselves: "When is Varian going to solve this problem?"

Background

In the configuration process of the Eclipse dose calculation models, the user has to import beam data which had been measured in a large water phantom. Lateral profiles (either inplane or crossplane) are part of this data. For Eclipse, they are typically measured in five depths (dmax, 50, 100, 200 and 300 mm).

It is up to the user whether he/she applies some postprocessing to the measured scans before they are formatted for Eclipse. Depending on the quality of the scan, it could make sense to smooth the curves. It is also possible to symmetrize them, if, for instance, the linac does not output a perfectly symmetric beam at the time of beam data aquisition. However, Eclipse itself symmetrizes the beam profiles during preprocessing, before it uses the data to generate the beam model. Therefore, it should make no difference for the final beam model, if symmetrized or "raw" profiles were imported into Eclipse.

All postprocessing done by the user before beam data import must be done with caution, to avoid unwanted artefacts like penumbra broadening etc. In any case, it is much better to measure as perfectly as possible, than to apply heavy postprocessing to data measured with suboptimal quality under suboptimal conditions.

Measured and Calculated Profiles

Our profiles were measured in the crossplane direction using a pinpoint chamber (with the exception of the diagonal profile). We imported symmetrized beam profiles into Eclipse Beam Configuration, calculated the AAA13026 beam model, and analyzed it in Eclipse Beam Analysis Workspace.

We got this as result:

Beam Analysis Workspace, AAA13. 10MV, 15x15 cm field, dmax depth(Fig 1: AAA13026, 10MV, 15x15 cm field, dmax depth. Calculation grid size = 0.2 cm.)

At first sight, the Calculated - Measured Profile Difference shows that there is some asymmetry, of up to 1% (lower graph). A zoom into the plateau region of the profiles themselves,

Beam Analysis Workspace, AAA13. 10MV, 15x15 cm field, dmax depth
(Fig 2: Same curves, zoom into plateau region.)

reveals a 0.71% difference in height of the calculated (cyan) profile peaks. The measured curve (red) is perfectly symmetric.

At larger depths and same field size, the effect is less pronounced (see scans in 50 mm and 100 mm), but still visible.

Calculated profiles are not always higher on the same side. For the same 0.20 cm grid size, the neighbouring field (12 x 12 cm) has the higher peak on the other side. See also the profiles of the 20x20 cm field, and of the 40x40 cm field, both in dmax.

The effect is not only visible in Beam Analysis, but also in the 3D dose calculation of a real patient plan:

External Beam Planning, AAA13. 10MV, 15x15 cm field, dmax depth
(Fig 3: AAA13026, 10MV, 15x15 cm field, dmax depth. Calculation grid size = 0.2 cm.)

In the above screenshot, one can also see that the dose is asymmetric in both the inplane and the crossplane direction.

In the Eclipse Treatment Planning Customer Release Note of Version 13.0.33 (P1003987-007, February 2014), the effect is at least mentioned. In section Known Issues / Beam Configuration2 it says:

"If beam data has been aquired with a pinpoint chamber, a slight difference could be noticed between the measured and calculated beam profiles. After computing the beam data in Beam Configuration, the data reviewed in Beam Analysis can exhibit computed profiles that are asymmetric. The difference in the asymmetry is about 0.5%. You can improve the difference by manually adjusting the calculation grid."

We are not happy with this paragraph, for the following two reasons:

1.) The reference to a certain type of detector - the pinpoint chamber - is given without further explanation. We found that the asymmmetry is also there if beam data have been measured with other types of detectors, either larger than pinpoint or smaller than pinpoint. See for instance the following calculation with AAA11031 which used the TrueBeam Representative Beam Data for Eclipse:

External Beam Planning, AAA11, Varian Golden Beam Data. 10MV, 15x15 cm field, dmax depth
(Fig 4: AAA11031, Varian beam data, 10MV, 15x15 cm field, dmax depth. Calculation grid size = 0.2 cm.)

The TrueBeam Representative Beam Data for Eclipse can be downloaded from my.varian.com. The curves were measured with a large volume IBA Dosimetry CC13 chamber (0.13cc), definitely not a "pinpoint" chamber. See the respective description of how the data were acquired.

2.) Let's look at calculation grid size in more detail. This can be done either in Beam Analysis Workspace or in External Beam Planning, as already demonstrated. We calculated our 15x15 cm field with grid sizes 0.25 cm, 0.2 cm, 0.15 cm and 0.1 cm.

Discussion

Varian calls this asymmetry in the calculated profiles a Design Deficiency (see CP-REQ: [8101340607]). It was present in all Eclipse versions, except for 8.9 and 10.0 (yes: it was there in versions 8.6 and older, then it got fixed, and then it came back!).

We call this a bug, and think it should be fixed as soon as possible, once and for all. Such asymmetric calculations are unacceptable.

The effect is so large, that even the profile icon in the lower left corner of Beam Configuration looks asymmetric! Obviously this is a shrunken graphics of the measured profile.

The design deficiency only applies to AAA. Acuros XB calculates perfectly symmetric profiles.

Notes

1We reported this problem to Varian helpdesk for the first time on July 25, 2007 (AAA version was 8.1.14), and attached screenshots from Eclipse 8.1 workspaces Beam Analysis and External Beam Planning. The case was logged under #~VAZG22568~#. One answer was: "According to product management, the issue should be fixed in a service pack scheduled to be released later this year." They were talking of the year 2007.

2The issue is listed in section "Beam Configuration", but it should rather be listed under "External Beam Planning".

Update, Sep 2015: In AAA 13.6.23 (right), the problem seems to be solved:

AAA13026(left) and AAA13623(right)

 

back to Medical Physics home

Valid XHTML 1.0 Strict