Replies: 1 comment 1 reply
-
Thanks for your thoughts @dcuccia! It is much appreciated that you continue to ponder ways to improve the software. I will cogitate over your ideas. |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Just a kernel of a thought, and maybe a placeholder conversation for future directions discussions, but one direction the Monte Carlo tools I think could move would be to have the execution and scaffolding/interface definitions more decoupled from the specific tissue, source, and detector implementations.
A basic example would be to break out the sources into a Vts.MonteCarlo.Sources library. This shows by example, how others should model, and include/use, their own custom sources - they don't just have to "live" with the ones provided by the core team. And importantly, they don't have to recompile the whole Vts, adding their new source - instead, they just reference the Vts.dll Nuget package and they're on their way.
An upside is that Vts gets smaller (size, and complexity), churn goes down, and it becomes less opinionated over time, making the core framework more flexible/agile.
The flexibility of the Vts has been on my mind over the years, and is the reason I've leaned into unit tests and examples that show how to use custom sources, etc, but IMO the decoupling above would be really nice from an API boundary perspective, and perhaps encourage growth/sharing of new implementations. For example, very easy for a researcher to push a spherical source, head-shaped tissue, or hexagonal fiber detector to their own GitHub, writing an example that uses the Nuget package, and the code works without recompiling Vts.
IMO, if we like and would want to encourage this workflow, we could lean into the approach and lead by example, putting our own sources/detectors/tissue definitions outside the Vts proper (only ITissue, IDetector, ISource would stay in Vts proper).
A corollary downside to this decoupling, however, is that the observability of these definitions would live off in some complied Nuget library, and (perhaps) the obviousness of how to use custom sources goes down, ironically. I was reminded by this blog post, however, that we can use Nuget to ship source code, too.
https://andrewlock.net/creating-source-only-nuget-packages/
Someone referencing Vts.MonteCarlo.Sources Nuget could "inherit" all source definitions, and even "see" those definitions in their own project structure. They could navigate to them, and copy-paste templates into their own class implementations to be modified for their purposes, all out of the box, without having to go hunting for how to do it properly. Vts MC stays steady, unless we add actual new simulation capabilities, meanwhile sources, detectors, tissues, even input validation checks can grow organically, outside of the core. Devil's in the details, but maybe this gets us the best of both worlds, in the long run. Just a thought.
Beta Was this translation helpful? Give feedback.
All reactions