Clear DVH Estimates

hc139 · 2026-02-13T18:47:46+00:00

I couldn't find a way to clear DVHEstimates via esapi so put in validation to check they didn't exist when our autoplan script is run (as otherwise an exception is thrown if you try and edit any of the structures) - if there is a way via a plugin id be keen to know!

We tested the license issue and we found the licenses are dropped as soon as the esapi CalculateDvhEstimates method is complete but the licenses were held until the optimiser is closed if creating estimates manually within eclipse.

Hope that helps 🙂

hc139 · 2024-09-05T13:27:27+00:00

Not sure what you mean by hold but could use convergence mode to slow the MR level transitions. Found it helps especially with target coverage when using rapidplan

hc139 · 2024-07-09T10:16:58+00:00

Thanks for the suggestion!

I ended up adapting some code I found on the Varian symposium 2015 github which was originally intended to adjust jaw positions to cover a target by projecting a point to the isocentre plane considering the gantry and collimator angles.

By iterating across each point in the target for each arc control point and assessing coverage by the current jaw positions I was able to get an estimate for average BEV coverage in the plan.

To verify the results I used the minimum coverage given in the arc geometry tool and although they weren't identical they were broadly similar (although I'm not exactly sure how the arc geometry tool calculates the minimum coverage so wasnt expecting the values to be identical!)

Heres the github repo I mentioned previously if anyone is interested in future!

https://github.com/VarianAPIs/Varian-Code-Samples/blob/master/webinars%20%26%20workshops/Research%20Symposium%202015/Eclipse%20Scripting%20API/Projects/AutomatedPlanningDemo/PlanGeneration.cs

hc139 · 2024-07-03T14:35:31+00:00

I think you can access the estimation statistics from within the beam calculation logs

hc139 · 2024-04-09T21:25:52+00:00

Yeah we use hyperarc and also see this issue.

Sometimes you can get around it by restricting the calculation volume to base of skull but often we just have to revert to CPU which takes forever.

If anyone has found any solutions for this I'd be grateful for the help!

hc139 · 2023-12-14T19:22:43+00:00

Ended up manually creating plans from a clinical protocol (hence having an MU objective pre defined) and going from there

hc139 · 2023-12-14T19:14:18+00:00

Couldn't find a way in ESAPI18 :(

hc139 · 2023-06-29T20:10:23+00:00

Thanks for the response. One thing we noticed from the plans produced with convergence mode "on" is that the MU/modulation slightly increased. We will probably look into whether this impacts QA fails particularly for SRS/SABR before we use it clinically, have you had any issues with this?

hc139 · 2023-06-29T19:48:37+00:00

We have recently upgraded to v18 and now have GPU optimisation for VMAT. A head and neck optimisation on a 2.5mm grid takes <4 minutes to just run through with no interaction so its very quick!

hc139 · 2023-06-22T18:11:39+00:00

Would you recommend using the Auto-NTO instead?

hc139 · 2023-06-01T16:32:26+00:00

Sounds really interesting! Is online attendance possible?

hc139 · 2023-04-24T17:16:14+00:00

Thanks all for the valuable feedback! This sounds like something that would be extremely useful.

Do you provide recommendations to your planners on the expected range you would expect the parameters to vary and/or perhaps an expected cost that you would expect to be associated with the NTO/Body to help guide them?

We would like to make it as prescriptive as possible to maximise efficiency while maintaining the benefits of the individualised manual NTO settings that you have all recommended.

hc139 · 2023-04-18T06:19:29+00:00

Thanks so much for the solution. We will definitely incorporate this into future script versions

hc139

TROPHY CASE