If Acuros XB<\/span> marked the entry of deterministic transport into the Eclipse<\/span>ecosystem, the pair CC\/MC<\/span> of RayStation<\/span> shows another possible maturity: maintaining a very strong analytical engine as a clinical basis and reserving Monte Carlo<\/span> for contexts where more explicit physics really pays off.<\/p>\n The local regulatory text is very clear right from the start: RayStation has two photon dose engines: collapsed cone (CC) and Monte Carlo (MC).<\/span> This already eliminates a common confusion. The system does not treat Monte Carlo<\/span> as the only serious form of calculation nor collapsed cone<\/span> as residual inheritance. The two engines are part of the clinical architecture of the product.<\/p>\n The official<\/span> white paper from RaySearch<\/span> helps you understand the role of CC<\/span>. In it, the clinical photon engine is described as based on classical principles of collapsed cone convolution superposition<\/span>. The same document summarizes the calculation chain in four steps:<\/p>\n This description is valuable because it shows that CC<\/span> of RayStation<\/span> is not a \u201clightweight\u201d algorithm in the trivial sense. It is a robust clinical engine, anchored in the collapsed cone<\/span>tradition, with multi-source modeling and Monte Carlo kernels. This explains why it remains so relevant even on a system that also offers Monte Carlo<\/span>.<\/p>\n fluence base Perhaps the most interesting aspect of the RayStation<\/span> architecture is this: the manufacturer claims that the Monte Carlo<\/span> photon engine uses the same fluence computation in the head as the collapsed cone<\/span>.<\/p>\n engine. This greatly changes the way of interpreting divergences between the two. In many TPS, the temptation is to assume that any major difference between engines arises from a completely different chain from the source. In RayStation<\/span>, at least conceptually, the creep modeling part of LINAC remains aligned. What changes decisively is the physics of deposition in the patient.<\/p>\n This architecture has two useful consequences:<\/p>\n This does not eliminate the role of beam model<\/span>, of course. But it helps to focus the discussion on what the clinician really wants to know: how much of the observed difference arises from the way the dose is calculated within the patient.<\/p>\n The collapsed cone<\/span> was born to solve a classic problem: how to keep the physical heart of the convolution\/superposition without paying the full cost of a full voxel-by-voxel superposition. Instead of transporting energy in all possible directions at prohibitive cost, the method collapses energy into a finite set of directions, efficiently preserving the total energy.<\/p>\n In RayStation<\/span>, this philosophy appears coupled to a multi-source model of fluency. In official<\/span>, the primary source is represented as a spatial elliptical Gaussian; the secondary, as circular Gaussian; and there are still two sources of contaminating electrons. The collimation is modeled in its physical positions, with description of offsets, leaf tips and tongue-and-groove.<\/p>\n This architecture explains an important part of the engine’s clinical performance. CC<\/span> doesn’t just depend on the kernel. It depends on:<\/p>\n In other words, CC<\/span> of RayStation<\/span> is far from being a simplified algorithm in the pejorative sense. It is a high-level clinical engine, built to solve most routines with good fidelity and controlled computational cost.<\/p>\n This is where the local stuff comes in especially strong. The IFU<\/span> of RayStation v2025 SP1<\/span> is not just an algorithmic description; it goes into validation in great detail.<\/p>\n According to the documentation, validation of the collapsed cone photon dose engine<\/span> included:<\/p>\n Acceptance criteria are described in terms of gamma<\/span>, point dose difference and confidence levels. The document states that the overall accuracy was considered acceptable and that the algorithmic limitations identified are addressed in warnings and in the system’s technical reference.<\/p>\n This excerpt is important for two reasons.<\/p>\n The first is that it repositions CC<\/span> as a clinically serious engine, not as a mere preliminary calculation.<\/p>\n The second is that it shows a correct methodological attitude: validation is presented by scope, by technique and by type of measurement. This is exactly the opposite of the commercial simplification that turns every algorithm into a universal promise.<\/p>\n The same document states that collapsed cone<\/span> of RayStation<\/span> was compared to independent and well-established TPS, including:<\/p>\n The text also says that, within the acceptance criteria used, the engine calculations could be considered equivalent to the clinical systems with which they were compared.<\/p>\n This point deserves careful reading. It does not mean that all TPS are \u201cthe same\u201d. It means that, within the validation scope used, RayStation CC<\/span> achieved agreement compatible with clinical practice compared to already consolidated commercial systems.<\/p>\n This is very different from saying there is no difference between engines. There is. But the useful comparison must always be situated in:<\/p>\n A virtue of IFU<\/span> local is to make it clear that algorithm coverage is not the same thing as uniform validation coverage. RayStation<\/span> describes in great detail the machines and techniques covered:<\/p>\n Important limitations also appear:<\/p>\n This type of information should guide any serious use of the system. The correct question is never \u201cdoes the engine support VMAT?\u201d, but \u201cwhich VMAT, on which machine, with which beam model, within which validation scope?\u201d.<\/p>\n The IFU<\/span> location is also clear when describing the Monte Carlo<\/span> photon engine. The most interesting conceptual point is this: the photon Monte Carlo dose engine uses the same fluence computation in the LINAC head as the collapsed cone dose engine<\/span>.<\/p>\n This sentence is decisive because it shows where the engines separate. The head and creep description are not necessarily the main divider. The big divider is how to calculate the deposition within the patient.<\/p>\n The Monte Carlo<\/span> of RayStation<\/span> was validated, according to the document, with:<\/p>\n Furthermore, the text states that the calculation MC<\/span> in patient was cross-checked<\/span> with EGSnrc<\/span> in varied geometries, materials such as water, lung, bone, aluminum and titanium, fields of 0.4 x 0.4 cm\u00b2<\/span> to 40 x 40 cm\u00b2<\/span> and even with and without magnetic field.<\/p>\n This is the point where RayStation<\/span> shows a strong philosophy: it is not enough to say that there is Monte Carlo<\/span>; it is necessary to show what he was confronted with and in what context.<\/p>\n Another merit of the documentation is that it does not treat Monte Carlo<\/span> as universally available or universally validated for any machine. The local text is explicit:<\/p>\n This type of phrase should be remembered more in discussions about \u201cmore advanced\u201d engines. An algorithm can be physically stronger and still have more limited practical coverage in part of the technology park. For the service, this means one simple thing: there is no automatic replacement of CC<\/span> with MC<\/span> just because the second one looks more sophisticated.<\/p>\n There is always a previous question:<\/p>\n is this engine validated, in this version, for this machine and for this technique?<\/span><\/p>\n Without this question, the comparison between engines becomes an abstraction.<\/p>\n The coexistence of the two engines makes sense because they answer slightly different questions.<\/p>\n This division should not be read as a rigid rule, but as clinical reasoning. The common mistake is to transform MC<\/span> into an automatic symbol of superiority, when the real problem is often in beam model, in the material mapping, in the grid or in the chosen technique.<\/p>\n Perhaps the most clinically underrated part of the entire document is the warning about engine comparison.<\/p>\n The RayStation<\/span> explicitly warns that doses computed with different engines should be combined or compared with caution when the dose convention differs and the plan is sensitive to high atomic number materials.<\/p>\n The local text states:<\/p>\n This observation is worth its weight in gold because it shows how coexistence between engines requires methodological maturity. It is not enough to compare two DVH curves if they do not represent exactly the same physical convention.<\/p>\n Perhaps the main editorial lesson here is this: RayStation<\/span> makes it clear, in an almost pedagogical way, that modern radiotherapy is not just about \u201cchoosing the most sophisticated algorithm\u201d. It depends on aligning:<\/p>\n By keeping CC<\/span> and MC<\/span> side by side, the system assumes a clinical truth that is sometimes hidden in simplistic speeches: different engines have different roles, and the maturity of a service appears precisely in the way it decides when each one should be used.<\/p>\n When a service has CC<\/span> and MC<\/span> in the same TPS, the best strategy is not to elect a universal winner. The best strategy is to establish an explicit usage policy. Something like:<\/p>\n Without this policy, the coexistence of engines becomes apparent freedom and practical confusion. With this policy, the institution transforms algorithmic variety into real clinical capacity.<\/p>\n This is the main point of RayStation<\/span> as a commercial example. The value of the system is not in offering two engines for the user to choose an ideological champion. The value is in offering two physically different answers, each with its own force field, its cost and its validation limit.<\/p>\n Mature service does not use this coexistence to produce showcase comparisons. Use it to make better decisions.<\/p>\n","protected":false},"excerpt":{"rendered":" RayStation shows, in a mature way, why a commercial TPS may need both a strong clinical engine and Monte Carlo in the same ecosystem.<\/p>\n","protected":false},"author":0,"featured_media":17151,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"ngg_post_thumbnail":0,"fifu_image_url":"","fifu_image_alt":"","footnotes":""},"categories":[98,60],"tags":[],"class_list":{"0":"post-17207","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-radioterapia","8":"category-software"},"aioseo_notices":[],"rt_seo":{"title":"RayStation for Photons: Collapsed Cone and Monte Carlo Si...","description":"See how RayStation positions its photon engines, validates collapsed cone and Monte Carlo, and what that means for real clinical use.","canonical":"https:\/\/rtmedical.com.br\/raystation-photons-collapsed-cone-monte-carlo\/","og_image":"https:\/\/rtmedical.com.br\/wp-content\/uploads\/2026\/04\/raystation-v2025-cover-scaled.png","robots":"index,follow","schema_type":"Article","include_in_llms":true,"llms_label":"Guia t\u00e9cnico","llms_summary":"RayStation shows, in a mature way, why a commercial TPS may need both a strong clinical engine and Monte Carlo in the same ecosystem.","faq_items":[],"video":[],"gtin":"","mpn":"","brand":"","aggregate_rating":[]},"_links":{"self":[{"href":"https:\/\/rtmedical.com.br\/en\/wp-json\/wp\/v2\/posts\/17207\/"}],"collection":[{"href":"https:\/\/rtmedical.com.br\/en\/wp-json\/wp\/v2\/posts\/"}],"about":[{"href":"https:\/\/rtmedical.com.br\/en\/wp-json\/wp\/v2\/types\/post\/"}],"replies":[{"embeddable":true,"href":"https:\/\/rtmedical.com.br\/en\/wp-json\/wp\/v2\/comments\/?post=17207"}],"version-history":[{"count":3,"href":"https:\/\/rtmedical.com.br\/en\/wp-json\/wp\/v2\/posts\/17207\/revisions\/"}],"predecessor-version":[{"id":17272,"href":"https:\/\/rtmedical.com.br\/en\/wp-json\/wp\/v2\/posts\/17207\/revisions\/17272\/"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/rtmedical.com.br\/en\/wp-json\/wp\/v2\/media\/17151\/"}],"wp:attachment":[{"href":"https:\/\/rtmedical.com.br\/en\/wp-json\/wp\/v2\/media\/?parent=17207"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/rtmedical.com.br\/en\/wp-json\/wp\/v2\/categories\/?post=17207"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/rtmedical.com.br\/en\/wp-json\/wp\/v2\/tags\/?post=17207"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}![\"Cover](\"https:\/\/rtmedical.com.br\/wp-content\/uploads\/2026\/04\/raystation-v2025-cover-scaled.png\")
<\/figure>\nIn this Article<\/h2>\n
\n
What RayStation himself says<\/h2>\n
\n
The importance of the two engines sharing the same<\/h2>\n
\n
What does it mean to use collapsed cone in RayStation<\/h2>\n
\n
How RaySearch Validates collapsed cone<\/h2>\n
\n
Comparison of CC with others TPS<\/h2>\n
\n
\n
Scope of machine and technique: where IFU is more honest than propaganda<\/h2>\n
\n
\n
What about Monte Carlo from RayStation?<\/h2>\n
\n
Where the IFU itself imposes limits on enthusiasm for MC<\/h2>\n
\n
Where CC and MC coexist in an intelligent way<\/h2>\n
The CC<\/span> tends to be the natural choice when:<\/h3>\n
\n
The MC<\/span> tends to gain ground when:<\/h3>\n
\n
IFU’s most important warning: dose convention compatibility<\/h2>\n
\n
What the CC\/MC pair teaches about TPS commercials<\/h2>\n
\n
What does a mature service do with this coexistence<\/h2>\n
\n