New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CLI projector utilites with cache use excessive memory for block geometries #1365
Comments
yes, this is the same as for |
Obviously, you can pass a parameter file now that does this, as mentioned on the list. |
They use the same projector methodology so yes.
Would this mean that, for example, parallelproj forward/back projectors would have the option to
Yes but having an optional parameter file requirement to run the CLI utilities isn't very user friendly. |
yes. If they have no cache, it won't make a difference. Otherwise it seems impossible to do this at the highest level of the hierarchy. Having the "check on I'm using a matrix" in several places in the code is surely inferior. Especially if people want to run this from Python as well.
What do you mean? You prefer to make the parameter file required? |
No, sorry, the parameter file should remain optional. However, the current status means the projector utilities are unusable with standard BlocksOnCylinder geometries without a machine with exceptional memory capacity. That is, unless you provide an optional parameter file that turns the caching off. I agree that disabling the caching by default is a better solution. |
Running the CLI command:
uses the default configuration of
BackProjectorByBin
(e.g.BackProjectorByBinUsingProjMatrixByBin
).This data being projected is non-TOF and short axial FOV (nothing excessive for standard PET scanners in STIR) using the block geometry. The ProjData file is ~200MB on disk. The geometry does disable symmetries:
I find that back projecting half the data uses 20GB+ memory (htop report), which is then killed by my system before completion.
Modifying:
STIR/src/utilities/back_project.cxx
Lines 95 to 96 in 1f5b06f
to
removes this large memory usage. It appears the LOR cache storage is too large for blocks (due to the lack of symmetries?)
Does the
back_project
(and likewiseforward_project
) have any use for cache? If not, can it be disabled by default, as above? OR does it have a use when more symmetries are added?The primary issue is for standard non-TOF scanners (using blocks), this utility is generally unusable in its default configuration.
The text was updated successfully, but these errors were encountered: