FFF machine commissioning

[naninano1]

Dear Mark,

I am trying to commission my FFF linac using your repository. After generating the machine data, in validation step, the PDDs have good match on the measured ones for all fields. However, the Profiles are flatter than measured ones, for large fields. Furthermore, I tested several primary fluence curves, and found that dramatic changes in the primary fluence have a small effect on the profile. As you mentioned on a topic, the FFF kernel calculation was not correct. But I am not sure whether this incorrectness was only for your Synergy machine or it is a general and fundamental issue? May it be due to the fact that the calculations use a specific constant value for the penumbra (5mm)? Is there any solution for commissioning FFF machines?

Regards,

[naninano1]

These are the results. As you can see, the difference between measured (Meas) and computed profiles is decreased with increment of depth. for 20x20cm2 field:

for 40x40cm2 field:

For 10x10cm2 and smaller, the difference is very low:

[markbangert]

Hm... it is hard to judge what goes wrong here... And: What exactly happens with the 40x40 field? For this case there are still substantial differences in 20cm depth?!

[naninano1]

So you mean it may not be related to the code's kernel or other parameters? And your mentioned FFF 6MV had a better situation than mine? I personally, entered a correct fluence curve and OF. I also tried different fluence curves of various energies, and different source to collimator distances (SCD), but the impacts were not significant. On the other hand, changing the OF and FWHM had more tangible effects than fluence and SCD.

[naninano1]

Dear @mingersming and @wahln , your comments are also highly appreciated

[markbangert]

I am trying to find consistency in the error behaviour. You stated earlier that differences tend to wash out with increasing depth. This is supported by the graphs you show for the 20x20 field. for the 40x40 field, however, there are still substantial differences in 20cm depth. Is this even worse for shallower depths? And for 10x10 things look pretty good in 5cm depth. How is the situation for 10x10 for deeper depths?

[markbangert]

Generally the FWHM should be considered a machine constant that describes the size of the photon source on the anode. This parameter should have the same effect accross all depths and field sizes (though in varying magnitude). I.e. an increase FWHM should result in larger penumbras and a decrease in FWHM results in smaller lateral penumbras.

[markbangert]

For the large fields it may be the case that we are already running into trouble with the finite size of the scattering kernels. Would you be able to share your basedata with us? If you want you can email to contact@matrad.org.

[naninano1]

I am trying to find consistency in the error behaviour. You stated earlier that differences tend to wash out with increasing depth. This is supported by the graphs you show for the 20x20 field. for the 40x40 field, however, there are still substantial differences in 20cm depth. Is this even worse for shallower depths? And for 10x10 things look pretty good in 5cm depth. How is the situation for 10x10 for deeper depths?

Dear Mark, Thank you very much for your reply. As you can see here, the trend is the same for the 40x40cm2

Also for 10x10cm2:

[markbangert]

Ok. But it seems like you have this problem in particular for large field sizes, right?

naninano1 notifications@github.com schrieb am Fr., 5. März 2021, 20:16:

I am trying to find consistency in the error behaviour. You stated earlier that differences tend to wash out with increasing depth. This is supported by the graphs you show for the 20x20 field. for the 40x40 field, however, there are still substantial differences in 20cm depth. Is this even worse for shallower depths? And for 10x10 things look pretty good in 5cm depth. How is the situation for 10x10 for deeper depths?

Dear Mark, Thank you very much for your reply. As you can see here, the trend is the same for the 40x40cm2

[image: image] https://user-images.githubusercontent.com/77858420/110162188-9f724580-7e03-11eb-869a-b91f767fcfb3.png

[image: image] https://user-images.githubusercontent.com/77858420/110162279-c466b880-7e03-11eb-9fd0-8e5039b6129b.png

[image: image] https://user-images.githubusercontent.com/77858420/110162298-ca5c9980-7e03-11eb-80e9-c88f493e0f3e.png

Also for 10x10cm2: [image: image] https://user-images.githubusercontent.com/77858420/110162591-30e1b780-7e04-11eb-8f5e-9191fff3d4f2.png

[image: image] https://user-images.githubusercontent.com/77858420/110162751-64244680-7e04-11eb-8c5a-d4747636fb53.png

[image: image] https://user-images.githubusercontent.com/77858420/110162771-6ab2be00-7e04-11eb-8d0f-c4820670b0fd.png

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/e0404/photonPencilBeamKernelCalc/issues/6#issuecomment-791625651, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACNPY7NKNBFL3NEPMEZIQIDTCEUXJANCNFSM4YONECKA .

[naninano1]

Generally the FWHM should be considered a machine constant that describes the size of the photon source on the anode. This parameter should have the same effect accross all depths and field sizes (though in varying magnitude). I.e. an increase FWHM should result in larger penumbras and a decrease in FWHM results in smaller lateral penumbras.

You are correct. But in here the FWHM is smaller than expected. In addition, as I mentioned previously, the effect of the fluence map is neglectable. I compared the effect of two different fluences maps (FM) on profiles:

[naninano1]

Ok. But it seems like you have this problem in particular for large field sizes, right? naninano1 notifications@github.com schrieb am Fr., 5. März 2021, 20:16: … I am trying to find consistency in the error behaviour. You stated earlier that differences tend to wash out with increasing depth. This is supported by the graphs you show for the 20x20 field. for the 40x40 field, however, there are still substantial differences in 20cm depth. Is this even worse for shallower depths? And for 10x10 things look pretty good in 5cm depth. How is the situation for 10x10 for deeper depths? Dear Mark, Thank you very much for your reply. As you can see here, the trend is the same for the 40x40cm2 [image: image] https://user-images.githubusercontent.com/77858420/110162188-9f724580-7e03-11eb-869a-b91f767fcfb3.png [image: image] https://user-images.githubusercontent.com/77858420/110162279-c466b880-7e03-11eb-9fd0-8e5039b6129b.png [image: image] https://user-images.githubusercontent.com/77858420/110162298-ca5c9980-7e03-11eb-80e9-c88f493e0f3e.png Also for 10x10cm2: [image: image] https://user-images.githubusercontent.com/77858420/110162591-30e1b780-7e04-11eb-8f5e-9191fff3d4f2.png [image: image] https://user-images.githubusercontent.com/77858420/110162751-64244680-7e04-11eb-8c5a-d4747636fb53.png [image: image] https://user-images.githubusercontent.com/77858420/110162771-6ab2be00-7e04-11eb-8d0f-c4820670b0fd.png — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#6 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACNPY7NKNBFL3NEPMEZIQIDTCEUXJANCNFSM4YONECKA .

Yes, as I mentioned before, the results for 10x10 and smaller are acceptabl.

[mingersming]

@naninano1: If I recall right, I have seen the same behavior.

Alright, maybe it's time that we dig deeper in the base data generation for an FFF machine? @markbangert do you feel like to extract kernel data from the pdc++ code for some further checkings. ;)

[wahln]

I have a very stupid question, probably, but I just wanted to make sure... @naninano1 you create the comparison curves from within matRad, right? Do you query matRad to use the primary fluence used for base data generation and stored within the machine file? Since the last version, this can be queried explicity by pln.propDoseCalc.useCustomPrimaryPhotonFluence = true; (before the value needed to be changed manually in calcPhotonDose). For the IMRT dose influence calculation, this is by default false (for backwards compatibility with older versions), since it is more efficient and straightforward to to correct in post-processing; for individual, non-uniform large fields that would not hold anymore.

[naninano1]

Dear Niklas, it was a very clever comment! I don't think I have done your mentioned adjustment. So I hope it solve the issue. Although, I don't have access to my system until a couple of days. When I have I will share the results.

[naninano1]

Dear @wahln , I put your mentioned command inside the calcPhotonDose. Now I can see the effect of my fluence curve very well. Now I can see FFF-like profile. Thank you very much. In contrast, the FWHM value is ineffective now. This means the FWHM changes don't have any impact on the profile curve. Without the mentioned command it works.

if kernelCutoff < lateralCutoff
    matRad_cfg.dispWarning('Kernel Cut-Off ''%f mm'' cannot be smaller than geometric lateral cutoff ''%f mm''. Using ''%f mm''!',kernelCutoff,lateralCutoff,lateralCutoff);
    kernelCutoff = lateralCutoff;
end
pln.propDoseCalc.useCustomPrimaryPhotonFluence = true;
% toggle custom primary fluence on/off. if 0 we assume a homogeneous
% primary fluence, if 1 we use measured radially symmetric data
if ~isfield(pln,'propDoseCalc') || ~isfield(pln.propDoseCalc,'useCustomPrimaryPhotonFluence')
    useCustomPrimFluenceBool = matRad_cfg.propDoseCalc.defaultUseCustomPrimaryPhotonFluence;
else
    useCustomPrimFluenceBool = pln.propDoseCalc.useCustomPrimaryPhotonFluence;
end

Also, I forgot to mention that the comparison curves are made within Excel. Although the raw data is extracted from the matRad.

The grey line is the computed curve: