{"action":"closed","issue":{"url":"https://api.github.com/repos/OpenGATE/Gate/issues/73","repository_url":"https://api.github.com/repos/OpenGATE/Gate","labels_url":"https://api.github.com/repos/OpenGATE/Gate/issues/73/labels{/name}","comments_url":"https://api.github.com/repos/OpenGATE/Gate/issues/73/comments","events_url":"https://api.github.com/repos/OpenGATE/Gate/issues/73/events","html_url":"https://github.com/OpenGATE/Gate/issues/73","id":157964181,"number":73,"title":"TPS pencil beam source","user":{"login":"djboersma","id":7421237,"avatar_url":"https://avatars.githubusercontent.com/u/7421237?v=3","gravatar_id":"","url":"https://api.github.com/users/djboersma","html_url":"https://github.com/djboersma","followers_url":"https://api.github.com/users/djboersma/followers","following_url":"https://api.github.com/users/djboersma/following{/other_user}","gists_url":"https://api.github.com/users/djboersma/gists{/gist_id}","starred_url":"https://api.github.com/users/djboersma/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/djboersma/subscriptions","organizations_url":"https://api.github.com/users/djboersma/orgs","repos_url":"https://api.github.com/users/djboersma/repos","events_url":"https://api.github.com/users/djboersma/events{/privacy}","received_events_url":"https://api.github.com/users/djboersma/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":4,"created_at":"2016-06-01T17:33:09Z","updated_at":"2016-10-04T07:17:45Z","closed_at":"2016-10-04T07:17:45Z","body":"Another summer project: update `GateSourceTPSPencilBeam`.\r\n\r\n(1) pencil beam initialization\r\n\r\nRight now **all** pencil beams in a given plan are initialized at the start of the simulation as `GateSourcePencilBeam` objects. GSPB is not a simple struct, so for big treatment plans with many thousands of spots this takes a lot of RAM. In my current treatment case it's about 2GiB, Hermann told me that in he also saw Gate using 8 GiB due to `GateSourceTPSPencilBeam`. That is unpractical, for instance for simulating many (versions of) plans on a cluster. It would be better to have just a single GSPB object at any point in time. This would also model the reality much closer, where we treat with just a single pencil beam that has the same properties (it does not jump from proton to carbon, or from one set of source properties to another). \r\n\r\n(2) spot specification text file parsing\r\n\r\nThis is a different problem related to the same code: the text file parsing code is not very robust. The number of comment lines is hard-coded and if the user accidentally inserts or removes comment lines then the rest of the file yields bogus results or is ignored altogether, WITHOUT reporting any errors. This is in particular a problem for users who generate their spot file from non-DICOM input (because for dicom there is the `clitkDicomRTPlan2Gate` utility in `vv`). Minor mistakes can lead to a waste of a lot of time.\r\n\r\nI would like to:\r\n(a) allow arbitrary numbers of comment lines\r\n(b) let each line start with a keyword, which may help to catch mistakes\r\n\r\nWish (a) is easy to implement: just replace all the `for (i=0; i<Nlines; i++) getline(buf);` expressions (where `Nline` is some hardcoded number) with a `GateReadLine` function which reads lines of text and returns the first non-empty non-comment line.\r\n\r\nWish (b) is also easy.\r\n\r\nOf course there LOTs of other solutions (xml, dicom) but I like my solution because it is much less invasive while still addressing the problems I raise. The old format can still be supported (backwards compatibility), the new format can for instance be triggered by an obligatory keyword in the first comment line of the file (so that first comment line should of course *not* be skipped). And the `clitkDicomRTPlan2Gate` utility in `vv` could be updated to enable the new format (but as long as we keep the TPS code backwards compatible, that's not urgent).\r\n\r\n(3) Convergence/divergence\r\n\r\nMinor issue: a pencil beam can be convergent in X but divergent in Y and vice versa. At Skandion we see this at the lowest energy, `Ekin=60MeV`. For a single pencil beam source one can configure this, but in the TPS pencil beam source it's currently restricted to completely divergent or completely convergent. It would be nice to flexibilize this."}}
{"actor":{"display_login":"dsarrut"}}