Differences

This shows you the differences between two versions of the page.

--- planning:userguide:tutorials:finding_optimal_plan [2016/08/24 14:54] – [Running the Optimizer] kerhart
+++ planning:userguide:tutorials:finding_optimal_plan [2021/07/29 18:28] (current) – external edit 127.0.0.1
@@ Line 1: / Line 1: @@
-====== Astroid Optimization ======
+====== Astroid Optimization (PBS) ======
-WIth IMRT plans the variety of possible dose distributions is quite large. Typically if a physician does not like an IMRT plan they will request a plan to be re-run. This requires the planner to input new constraints and objectives and a new plan to be run from the beginning of the optimization process. This is a time consuming process. Astroid eliminates this cycle using a Multi Criteria Optimization (MCO) approach that allows planners and physicians to visualize the tradeoff of target volume coverage vs reduced dose to the OAR's in real time. MCO treatment planning is based on a set of Pareto optimized plans, where a plan is considered Pareto optimal if it satisfies all the constraints and none of the objectives can be improved without worsening at least one of the other objectives. So instead of creating just one plan, Astroid creates a set of optimal plans that satisfies the treatment plan constraints and puts an interactive exploration of dosimetric objectives at the planners and physicians fingertips via a unique, highly intuitive, Pareto surface navigation slider bar system.
+With intensity modulated PBS treatment plans the variety of possible dose distributions is quite large. Typically if a physician does not like a plan they will request it to be re-run. This requires the planner to input new constraints and objectives and a new plan to be run from the beginning of the optimization process. This is a time consuming process. Astroid eliminates this cycle using a Multi-Criteria Optimization (MCO) approach that allows planners and physicians to visualize the trade-offs of target volume coverage vs reduced dose to the OAR's in real time. MCO treatment planning is based on a set of Pareto optimized plans, where a plan is considered Pareto optimal if it satisfies all the constraints and none of the objectives can be improved without worsening at least one of the other objectives. So instead of creating just one plan, Astroid creates a set of optimal plans that satisfies the treatment plan constraints and puts an interactive exploration of the objectives at the planners and physicians fingertips via a unique, highly intuitive, solution navigation slider bar system.
-//Constraints// play an important role in the optimization process, as they bound the solution space and ensure your navigation process is focused only on plans that meet your non-negotiable, highest priority dosimetric needs. It should be noted that if the //constraints// are too tight, there may be no feasible plans. However, if the //constraints// are too loose, too many solutions will exist and the navigation will be too broad to provide adequate resolution over the truly clinically useful plans. Therefore care should be taken to ensure appropriate constraints are set, which is facilitated using the Astroid //feasibility// check feature. So while constraints supply hard limits, //objectives// are the negotiable goals, they do not have a hard level that must be obtained, but "pushing" them harder does result in benefit to the patient. The number and type of //objectives// chosen should be such that all the relevant trade offs can be demonstrated and explored.
+//Constraints// play an important role in the optimization process, as they bound the solution space and ensure your navigation process is focused only on plans that meet your non-negotiable, highest priority dosimetric needs. It should be noted that if the //constraints// are too tight, there may be no feasible plans. However, if the //constraints// are too loose, too many solutions will exist and the navigation will be too broad to provide adequate resolution over the truly clinically useful plans. Therefore care should be taken to ensure appropriate constraints are set, which is facilitated using the Astroid //Feasibility// check feature. So while constraints supply hard limits, //objectives// are the negotiable goals, they do not have a hard level that must be obtained, but "pushing" them harder does result in benefit to the patient. The number and type of //objectives// chosen should be such that all the relevant trade-offs can be demonstrated and explored.
+===== Optimizer Algorithm Selection =====
+The user is able to select the MCO optimization algorithm from a list defined in the site configuration settings. The default option is the first algorithm in this site level list of pluggable_functions designated with the mco_optimizer key.
+As of Planning 2.3.2 the available optimizers are Art3+O and Nymph. Both optimizers use the same constraints and objectives. However Nymph does not use a separate feasibility stage and has it built in to the optimization step.
+{{ :planning:userguide:tutorials:mco_selection.png?400 |}}
+===== PBS Fraction Groups =====
+{{page>planning:userguide:tutorials:fraction_group&noheader}}
+===== Optimization Constraints =====
+==== About Constraints ====
+//Constraints// can be specified at various levels (//Plan, Fraction Group, Target/Beam Set//) with Astroid and they will affect different groups of beams depending on their level. //Constraints// at the //Plan// level are applied to the total dose resulting from all beams. //Constraints// at the //Fraction Group// level are applied to the total dose resulting from only the beams in the current Fraction Group. //Constraints// at the //Target/Beam Set// level are split evenly and applied individually to each Beam Set. In other words, the //Constraint// dose is divided by the number of //Beam Sets// in the //Target//, and this dose is then applied as a constraint to each Beam Set, so that either SFUD and IMPT can be achieved (see [[planning:userguide:tutorials:fraction_group|Fraction Groups]]). The section below will provide a walk through of the different levels and how constraints are applied at each one.
+It should be noted that all constraints are considered "hard limits"- values that __must be__ achieved. //Constraints// drive the feasibility calculation- whether the plan is achievable and should be used to ensure certain minimal clinical parameters are met.
+The following constraint types are available. Note certain constraints are available only for //Target// type structures.
+     * **Min**: The minimum dose the structure must receive
+     * **Max**: The maximum dose the structure may receive
+     * **Min Mean**: The minimum mean dose a structure must receive
+      * This will drive the dose up across the structure
+     * **Max Mean**: The maximum mean dose a structure may receive
+      * This will limit the mean dose across the structure
+     * **Overdose**: The maximum sum of the overdose that a structure may receive (//not available for ART3+O optimizer//)
+      * This will limit the total volume-weighted overdose (dose above a given threshold) that a structure receives, driving down hot spots
+     * **Underdose**: The maximum sum of the underdose that a structure may receive (//not available for ART3+O optimizer//)
+      * This will limit the total volume weighted underdose (dose below a given threshold) that a structures, driving up cold spots
+     * **Hot Spot Vol**: The maximum mean dose to the hottest portion of a structure (//not available for ART3+O optimizer//)
+      * This will keep the mean dose to the hottest portion of a structure below the given limit; portion is set as a % vol and the limit is the max mean dose allowed to that portion of the structure
+     * **Cold Spot Vol**: The minimum mean dose to the coldest portion of a structure (//not available for ART3+O optimizer//)
+      * This will keep the mean dose to the coldest portion of a structure above the given limit; portion is set as a % vol and the limit is the min mean allowed to that portion of the structure
+The user can choose to apply one or multiple of these constraints to any number of structures.
+==== Working with Constraints ====
+=== Working with Fraction Group and Target/Beam Set Constraints ===
+//Constraints// at the //Fraction Group// level are applied to the total dose resulting from only those beams in the current //Fraction Group//. //Constraints// at the //Target / Beam Set// level are equally split among the Beam Sets within the Target and are applied to the total dose resulting from the beams in each of the Beam Sets. The following steps are a brief walkthrough for creating a max constraint of 79.2 Gy(RBE) to the PTV for the whole Fraction Group, and then creating two SFO beams that each provide a minimum dose of 39.6 Gy(RBE). Note that this configuration with the max constraint at the Fraction Group Level is different than if we had put both the min and max at the Target / Beam Set level. In the case shown, it is only the total dose from the two beams that is constrained to be below 73 Gy(RBE). Had both constraints been placed at the Target Level, then each beam would instead be constrained to a max of 36.5 Gy(RBE).
+  - Select the //Fraction Group// if it has been created or create a new one by clicking //Create New Fraction Group//
+  - Choose the prescription, number of fractions to be treated with this Fraction Group
+  - Choose the type of treatment (SFO, IMPT, Advanced) and target {{ :planning:userguide:tutorials:fx_group_start.png?300 |}}
+  - Choose the //Beams// to be treated
+  - Choose the //Target// to be treated
+    - Assign the dose constraints to the //Target//
+    - The assigned constraint doses at this level will be divided evenly among the //Beams// to the //Target//, which allows for quick creation of SFO treatments {{ :planning:userguide:tutorials:fx_group_beams_and_target.png?300 |}}
+=== Working with Plan Constraints ===
+//Constraints// at the //Plan// level are applied to the total dose across all beams.
+  - Open the //Constraints// sub block contained in the //Constraints/Feasibility// block and choose the //Edit// button.
+  - Choose from the drop down the structure or structures to which constraints should be added
+  - Define what constraint(s) should be applied to each structure by choosing the constraint and entering the dose
+  - Follow this and enter the constraints for all applicable structures. {{ :planning:userguide:tutorials:constraints_2.png?300 |}}
+  - When finished click the //OK// button.
+  - Once all the Constraints have been set the user can either start the Feasibility by choosing //Calculate// or move on to defining the Objectives
 ===== Feasibility and Constraints =====
-After the //constraints// have been entered, the user may start the //Feasibility// calculation by clicking //calculate// in the //Feasibility// block. The //Feasibility// calculation is based solely on the //constraints// and it should be used to ensure there is a feasible plan possible. The //Feasibility// calculation may be an iterative processes in order to get appropriate constraints established for a particular plan. In other words, the user may need to enter a //constraint//, check the feasibility, then progressively drop the //constraint// and check the //feasibility// until the plan is no longer feasible. It is recommended practice to start by obtaining a feasible plan utilizing only target //constraints// then add OAR //constraints// as desired.  Remember, using a narrow range of //constraints// can improve the optimizer performance and improve the resolution of the Pareto surface navigation.
+After the //Constraints// have been entered, the user may start the //Feasibility// calculation by clicking //calculate// in the //Feasibility// block. The //Feasibility// calculation is based solely on the //constraints// and, it should be used to ensure that it is possible to meet the specified constraints. The //Feasibility// calculation may be an iterative processes in order to get appropriate constraints established for a particular plan. In other words, the user may need to enter one or more constraints, check the feasibility, then progressively tighten the constraints and re-check the feasibility until the plan is no longer feasible, then back-off to the last feasible values. It is recommended practice to start by obtaining a feasible plan utilizing only target //Constraints// then add OAR //Constraints// as desired. Remember, using a narrow range of constraints can improve the optimizer performance and improve the resolution of the solution navigation.
-The user also needs to be aware of the impact of //constraints// being set on //Fraction Group// level versus the //Plan// level. For example, it is possible to have a //constraint// set in the //Plan// level so that the whole dose to an OAR is given on one day and none on the other day. This could happen when there are two //Fraction Groups// and the OAR dose is not split between the two by using Fraction Group level constraints.
+The user also needs to be aware of the impact of //Constraints// being set at the //Fraction Group// level versus the //Plan// level. For example, it is possible to have a //Constraint// set in the //Plan// level so that the whole dose to an OAR is given on one day and none on the other day. This could happen when there are two //Fraction Groups// and the OAR dose is not split between the two by using Fraction Group level constraints.
+===== Optimization Objectives =====
+//Objectives// communicate to the optimizer the goals that are important to strive for in your plan. //Objectives// are set at the //Plan// level under //Plan Constraints/Objectives// and they apply to the total, combined dose from all beams. //Objectives// are not given any relative importance at this point (i.e. their order within the list is not meaningful). The //Objectives// drive the solution of the Multi Criteria Optimization (MCO) and for each //Objective//, a corresponding //Navigation Slider// will be presented to allow for exploration of trade-offs in the case of competing objectives (for more information about the MCO process and how objective importance/weighting is handled in Astroid refer to [[planning:userguide:tutorials:finding_optimal_plan|this article]]).
+The following objective selections are available in Astroid:
+    * **min_max**: Minimize the maximum dose within a structure (drive dose down)
+    * **max_min**: Maximize the minimum dose within a structure (drive dose up)
+<WRAP 1000px center><WRAP left>[{{ :planning:userguide:tutorials:objectives_min_max.png?390 | min_max: Minimize the Max Dose }}]</WRAP><WRAP right>[{{ :planning:userguide:tutorials:objectives_max_min.png?390 | max_min: Maximize the Min Dose}}]</WRAP></WRAP><WRAP clear></WRAP>
+    * **min_mean**: Minimize the mean dose within a structure (drive dose down)
+    * **max_mean**: Maximize the mean dose across the structure (drive dose up)
+    * **min_overdose**: Minimize the high dose within a structure
+      * Dose will be driven down only until the specified limit is reached (this is often more relevant that min_max, since it may not be beneficial to continue minimizing beyond a certain dose level)
+    * **min_underdose**: Minimize the low dose within a structure
+      * Dose will be driven up only until the specified limit is reached (this is often more relevant that max_min, since it may not be beneficial to continue maximizing beyond a certain dose level)
+<WRAP 920px center><WRAP left>[{{ :planning:userguide:tutorials:objectives_min_over.png?390 | min_overdose: Minimize the high dose}}]</WRAP><WRAP right>[{{ :planning:userguide:tutorials:objectives_min_under.png?390 | min_underdose: Minimize the low dose}}]</WRAP></WRAP><WRAP clear></WRAP>
+    * **min_hot_spot**: Minimize the mean dose to the hottest portion of a structure (//not available for ART3+O optimizer//)
+      * The mean dose to the hottest portion of a structure will be driven down (i.e. the tail dose on the DVH); portion is set as a % vol of the structure
+    * **min_cold_spot**: Maximize the mean dose to the coldest portion of a structure (//not available for ART3+O optimizer//)
+      * The mean dose to the coldest portion of a structure will be driven up (i.e. the shoulder dose on the DVH); portion is set as a % vol of the structure
+==== Working with Objectives ====
+  - Open the //Objectives/Optimizer// sub-block contained in the //Optimization// block
+  - Choose a structure to which you wish to apply objectives
+  - Check the boxes to activate the desired objectives for the structure and then set the dose level if applicable
+<WRAP center>{{ :planning:userguide:tutorials:optimization_plan_objectives.png?200 |}}</WRAP>
+Once all the //Objectives// have been set, the user is ready to run the MCO solver, which is performed in the //Objectives/Optimizer// block.
@@ Line 19: / Line 109: @@
 ===== Running the Optimizer =====
-The //Objectives//, as stated before are the negotiable goals where they may be no hard limit, but there is benefit to improving them. Astroid allows //Objectives// on both Targets and OAR's. //Objectives// can be placed on structures to either increase or decrease dose. The //Objectives// are the sole driving force guiding the MCO and it is important to recall from the discussion above that Astroid will only navigate to plans that are "optimal" in at least one objective (meaning again that this objective cannot be improved without another objective getting worse. Unlike //Constraints//, //Objectives// should be added all at once and there is no need to place them in any particular order (order is irrelevant). Additional information about //Objectives// can be found [[planning:userguide:tutorials:optimization_objectives|here]]. Since the MCO is finding a large set of optimal solutions the optimization can be a lengthy process. The following factors have the largest impact on the optimization run time:
+The //Objectives//, as stated before are the negotiable goals where there may be no hard limit, but there is benefit to improving them. Astroid allows //Objectives// on both Targets and OAR's. //Objectives// can be placed on structures to either increase or decrease dose. The //Objectives// are the sole driving force guiding the MCO and it is important to recall from the discussion above that Astroid will only navigate to plans that are "optimal" in at least one objective (meaning again that this objective cannot be improved without another objective getting worse). Unlike //Constraints//, //Objectives// should be added all at once and there is no need to place them in any particular order (order is irrelevant). Additional information about //Objectives// can be found [[planning:userguide:tutorials:optimization_objectives|here]]. Since the MCO is finding a large set of optimal solutions the optimization can be a lengthy process. The following factors have the largest impact on the optimization run time:
-  * The number of points in the calculation grid (linear impact)
+  * The number of points in the calculation grid
-  * The total number of spots from all beams (linear impact)
+  * The total number of spots from all beams
-  * The number of objectives (quadratic impact)
+The number of calculation points and number of spots will have a direct impact on the calculation times meaning that increases in these values will also increase the MCO calculation time. The number of objectives does not always increase the overall run time of the calculation however, thanks to the parallelization that be achieved using the Astroid cloud services, though the number of objectives does impact the usable capacity of calculations that can run on the Astroid cloud. The speed and number of running calculations will depend on the availability and load on the Astroid cloud calculation servers. Each objective of the MCO calculation is computed on a separate thread of a calculation server, therefore understanding the usage of these servers can help users make decisions regarding resource usage for a given set of objectives. The Astroid MCO calculations are designed to use servers in CPU increments of 16 and the MCO calculations are posted to calculation servers as follows:
-The number of calculation points and number spots will have a direct 1:1 (linear) impact on the calculation times; in other words, doubling one of these items will (roughly) double the MCO calculation time. The number of objectives scales quadratically, meaning that doubling the number of objectives creates a four-fold increase (2<sup>2</sup> = 4) in the number of MCO calculations that are required. For objectives, this does not always increase the overall wait time on the calculation however, thanks to the parallelization that be achieved using the Astroid cloud services backend. So for small numbers of objectives 1-3, you may not notice much (if any) increase in wait time by increasing up to 3-5 objectives (but this does depend on the availability and load on the Astroid cloud calculation servers).
+  * 1-16 objectives: a single 16 core calculation will be issued, with an objective being run on each core
+  * 16-32 objectives: a single 32 core calculation will be issued, with an objective being run on each core
+  * >32 objectives: a single 32 core calculation will be issued, and the server will be responsible for balancing the load to achieve full CPU utilization
+Understanding this pattern is important, as it can be seen that using less than 16 objectives generally will have minimal impact on MCO run-time and no impact on resource usage. Using between 17-32 objectives will use additional resources, but generally not impact run-time, but using >32 objectives will increase the MCO run-time without using additional resources.
 Once all the desired //Objectives// are entered the MCO calculation is started just by clicking the //calculate// option in the //Navigation// block. It should be noted that the //Feasibility// will be re-checked if any of the //Constraints// have changed since the feasibility was last run. The MCO calculations will run in the cloud and the user can simply leave the Astroid application running and move on to other things while the calculations process. Please note that at this time the Astroid App should be left open in this state to ensure the calculations run to completion, however, users may open additional instances of Astroid and work on other plans while these calculations proceed (no performance issues should be encountered when using multiple instances since the "heavy" calculations are off-loaded to the cloud calculation servers).
@@ Line 29: / Line 124: @@
-FIXME Discuss how to check progress (put in later when progress widget done)
+During the calculation process the user may check to see the status of the calculations. The example below shows a Feasibility calculation that is 4% complete. As calculations finish the user will notice this number increasing. {{ :planning:userguide:tutorials:fob_feasibility_show_details.png?300 |}}
+By clicking on //Show Details// a detailed list of what calculations have been finished and which are running will be displayed. In the example below the dij's are completed and the Feasibility is currently running. In the detailed view if the user chooses //show completed subcalculations// they will be able to obtain the identification number of each calculation. {{ :planning:userguide:tutorials:fop_calc_process.png?300 |}}
 ===== Dose Normalization and Display =====
-The user has many options for how the dose is displayed as well as the structures. The options for controlling the display of the dose are on the right hand side of the display under //Dose Options//. At any point in time the user may choose to turn on as few or as many structures as they would like to few. This is done by clicking on the individiual structure in the //Structure Control// block.
+The user has many options for how the dose is displayed in Astroid. The options for controlling the display of the dose are on the right hand side of the display under //Dose Options//. The //Dose Options// provide controls over the DVH type (relative or absolute volume), the colors and scaling of the display dose, the type of dose display shown (colorwash, isolines, or isobands), as well as the scope of dose to display (full plan, single fraction group, or individual beam dose).
-== Dose Volume Histogram (DVH) Dose ==
+==== Dose Volume Histogram (DVH) ====
-The planner has the option of viewing the dose for the DVH in relative dose (dose per percentage of the volume) or in absolute dose (dose per cc of the structure) by clicking the //Absolute Dose// option under DVH. The user may also hover over any area of the DVH curve to obtain the dose and percentage of a given structure.
+=== Relative and Absolute DVH ===
-{{ :planning:userguide:tutorials:dvh_relative.png?200 |}}
-{{ :planning:userguide:tutorials:dvh_relative.png?200 |}}
-== Dose Normalization ==
+The planner has the option of viewing the dose for the DVH in relative volume (dose per percentage of the volume) or in absolute volume (dose per cc of the structure) using the //Absolute DVH// option. The user may also hover over any area of the DVH curve to obtain the dose and percentage of a given structure or click on one or more lines to start tracking the cursor value for the lines.
+<WRAP center box>
+{{:planning:userguide:tutorials:dvhabsolute.png?385|}} {{:planning:userguide:tutorials:realtive2.png?480|}} </WRAP>
-As in the DVH the user has multiple otions for displaying the dose. The dose can be displayed in either relative (percentage) or absolute. This can be chosen by using the drop down menu under //Levels//. If the user chooses to view dose in relative mode they must then enter the 100% line dose- usually the prescription dose. The percentage isodose lines that the user wants to see must then be entered. If the user chooses to view the dose in absolute they user needs to choose absolute from the drop down and then enter the dose lines that they want to see.
+=== Dual Dose DVH ===
-The user also can choose to view the isodose as either isobands, isolines, colorwash or combinations of these. The user may use the sliders to set the opacity for each of these. They may also choose the line width and whether it is solid, dashed or dotted for isolines.{{ :planning:userguide:tutorials:dose.png?200 |}}
+The planner has the option of viewing the original MCO dose and the currently navigated MCO dose in the DVH graph. By selecting the //Show Secondary Doses// option under the Dose Options, the DVH graph will display the following doses:
+  * **Dotted Line:** Original un-navigated dose.
+  * **Solid Line:** Current navigated dose based on the position of the MCO sliders.
+With the //Show Secondary Doses// option disabled, only the current navigated dose will be displayed within the DVH graph.
+{{ :planning:userguide:tutorials:dvh_dual_dose.png?385 |}}
+==== Dose Display Normalization ====
+As in the DVH the user has multiple options for displaying the dose. The user may change the percentage isodose line and its corresponding Gy they would like displayed. This is done by entering the appropriate numbers in the boxes under //Levels//. The user may turn on and off specific levels by clicking on the //X// to the left of the line.
+The user also can choose to view the dose as either isobands, isolines, color wash or combinations of these. The user may use the sliders to set the opacity for each of these as well. They may choose the line width and whether it is solid, dashed or dotted for isolines.
+{{ :planning:userguide:tutorials:dose_options.png?300 |}}
+In the case of a plan with multiple //Fraction Groups// the user may choose to view the dose:
+  - In a composite dose- //Full Plan//- which will take into account all //Fractions groups//
+  - For a particular //Fraction Group// or
+  - For an individual beam
+To pick one of the above the user must choose from the dropdown list under //Scope//. The //Scope// automatically defaults to //Full Plan//. {{ :planning:userguide:tutorials:dose_scope.png?300 |}}
+Note: When in a sliced image display containing dose, slice scrolling positions will be based on the smallest voxel size of the calculation grid. For any sliced image displays that do not show dose, scrolling positions will be based on the CT image slice thicknesses directly.
+==== Isobands ====
+Isobands are an interpolation of dose from isodose line to isodose line. Isobands take a range of interpolated dose and fills it in with color.
+{{ :planning:userguide:tutorials:fop_isobands.png?300 |}}
+==== Isoline ====
+Isolines display either the absolute or relative dose in the form of closed lines of constant dose value (i.e. these are lines that pass through the points of equal dose).
+{{ :planning:userguide:tutorials:fop_isolines.png?300 |}}
+==== Color Wash ====
+Color Wash shows the raw dose across the given range of values, blending colors according to the dose levels.
+{{ :planning:userguide:tutorials:fop_color_wash.png?300 |}}
+==== Combination ====
+The user does have the ability to combine multiple representations. Below shows a combination of Isobands and Isolines.
+{{ :planning:userguide:tutorials:fop_combo.png?300 |}}
 =====Navigating the Solutions =====
-Once the plan has been calculated the //Navigation// block will become active. This block contains all the active structures and their objectives. Under each objective is a slider bar. This slider bar allows the user to adjust an objective and to see how the change will effect DVH and other objectives.
+Once the plan has been calculated the //Navigation// block will become active. This block contains entries for all the active objectives and under each objective is a slider bar. This slider bar allows the user to adjust the importance of an objective and to see, in real time, how the change will affect the dose to the patient.
-On each slider there are two vertical bars. The thin blue bar denotes the dose the objective is at. The thick white bar is the dose limit the solution can go to. The objective will not go past this point. It can never get worse than this. The blue and white numbers to the upper right of each slider correlate to the dose the blue and white and white vertical bars are at. The numbers at the end of each slider bar denote the range that the user has to work in. This is the bar the user should grab to slide. Thick white bars that are on opposite ends of the slider means that the objectives are competing very little with each other. An example of this is in the diagram below. The CTVPO+3mm min max is competing very little with the CTVPO+3mm max mean. This means the user can make large adjustments to each of these without effecting the other. If both white slider bars are on the same side and an adjustment is made it will have a great impact on the other structures. The thick grey horizontal bar it the range or window that the user has to adjust the vertical bars. The user will notice as they drag the white bar to the left the window the user has to work in reduces. All of this allows the user to know the limits they have to work in. All of these adjustments are able to be done without running a new plan as would needed to be done in traditional treatment planning systems. This allows the user to look at many different solutions in a short amount of time.
-If the user does not like the adjustments they have made to the structure objective slider they may hit the //Reset// button in the bottom left corner to reset all the objectives to their original state. It the user does like the adjustment that was made they may choose the //Save// button in the bottom right hand corner. This will save the objectives at their current position. The //Cancel// button will close the //Navigation// block in its current state.
+The Navigation Sliders should provide an intuitive process for finding the optimal plan, but by gaining a complete understanding of the Navigation Sliders users will be better equipped to quickly reach their plan goals. It should also be noted that sliders for minimize objectives will slide to the left and sliders for maximize objectives will slide to the right. On each slider there are two vertical bars. The thick white bar is the user controlled slider handle and it represents the worst value of an objective that the user wants to allow. Simply stated, the objective will not go past this limit. The thin blue bar denotes the actual current value of the objective. Astroid calculates this value by balancing the solution over the available ranges of each objective. It should now be clear that moving a slider does **not** directly set an objective, but rather it places limits on the allowable range of an objective. It is this feature that makes navigating the solution space very clear and effective.
-{{ :planning:userguide:tutorials:navigation_1.png?200 |}}
+{{ :planning:userguide:tutorials:fop_navigation.png?300 |}}
+The blue and white numbers to the upper right of each slider correlate to the objective value for the current plan and the objective limit based on the slider position, respectively. So in the image above, it can be seen that the top slider has been set such that allowable maximum dose to the CTVbreast_L is 10.46 Gy(RBE), but the current value is 10.33 Gy(RBE). The numbers at the end of each slider bar denote the overall range for the objective value (i.e worst and best possible values). The main slider horizontal bar is also separated into two sections. The thicker, lighter grey horizontal bar is the range or window that the objective is currently limited to stay within (it is limited due to the positioning of all sliders by the user). The user will notice as they drag the slider handle (white bar) on one objective, this light grey area will change on some of the other sliders. This allows the user to know the limits they have to work in and the impacts (trade-offs) that one objective is having on the others. Sliders should be adjusted such that all physician goals are achieved and the best balance of target coverage and normal tissue doses are realized for the unique patient at hand.
+All of these adjustments are able to be done without running a new plan as would needed to be done in traditional treatment planning systems. This allows the user to look at many different solutions in a short amount of time.
+If the user likes the adjustments that were made to the sliders they may click the //Save// button in the bottom right hand corner. This will save the objectives at their current position. If the user does not like the adjustments they have made to the sliders, they may hit the //Reset// button to reset all the objective sliders to their last saved state. The //Cancel// button will close the //Navigation// block in its current state.