As part of #361, the FBP memory estimation was improved to more accurately represent what memory allocations the FBP method does. However, there is still some memory being allocated that is not yet known where in the method it is happening.
and this allows 80GB data to be put through the method in httomo without issue.
However, from observations of using cupy's LineProfileHook is was determined that it's most likely not the case that the 1D RFFT is creating more than one array. Therefore, more investigation is needed to determine what is causing the extra memory allocated.
As part of #361, the FBP memory estimation was improved to more accurately represent what memory allocations the FBP method does. However, there is still some memory being allocated that is not yet known where in the method it is happening.
For now, a multiplier of 2 of the output of the 1D RFFT has been added to bump the memory estimation: https://github.com/DiamondLightSource/httomo/blob/0b5f020175b23388da9bea5940b1e246c6e80be0/httomo/methods_database/packages/external/httomolibgpu/supporting_funcs/recon/algorithm.py#L103-L112
and this allows 80GB data to be put through the method in httomo without issue.
However, from observations of using cupy's
LineProfileHookis was determined that it's most likely not the case that the 1D RFFT is creating more than one array. Therefore, more investigation is needed to determine what is causing the extra memory allocated.