Skip to content
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

Possible reintoduction of subcycles to reduce memory usage #1099

Open
kslong opened this issue Sep 8, 2024 · 4 comments
Open

Possible reintoduction of subcycles to reduce memory usage #1099

kslong opened this issue Sep 8, 2024 · 4 comments

Comments

@kslong
Copy link
Collaborator

kslong commented Sep 8, 2024

I am running a single cell model with a large number 1e9 photons on mulitple cores. Each core is taking 5.9GB, which seems excessive.

I think think the issue is that we seem to allocate memory for all 10*9 photons, even though with 24 cores, we should need to less than 5e7.

setup.c:656:  photmain = p = (PhotPtr) calloc (sizeof (p_dummy), NPHOT);

@Edward-RSE @jhmatthews - Am I right about this, and is it something we should fix.

As an aside, at one point in the past, python had subcycles for generating photons, where for example we generated 1e6 photons in each subcycle to get to a total of 1e7 photons before calculating the ionization. We got away from that as memory became cheaper, but that's an approach we could go back to if necessary.

@kslong kslong changed the title Possible overallocation of space for photons Possible reintoduction of subcycles to reduce memory usage Sep 10, 2024
@kslong
Copy link
Collaborator Author

kslong commented Sep 10, 2024

@jhmatthews is correct. The photons are shared among the threads, because NPHOT is adjusted. We therefore might want to consider re-implementing subcycles in situations where the memory is dominated by the photon bundles.

@jhmatthews
Copy link
Collaborator

I was also surprised by the memory usage but it does seem like it really does get into Gigabytes once you have >1e7 photons per thread, and I had not been noticing this particularly. So yes, probably in the longer term it would be sensible to have subcycles, and think about whether there is any info in the structure that isn't needed/used.

@jhmatthews
Copy link
Collaborator

(if we can live with this for now I'd suggest we wait til after code release for this though)

@kslong
Copy link
Collaborator Author

kslong commented Sep 11, 2024

Agreed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants