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

startup / instantiation speed #108

Open
dnelson86 opened this issue Nov 11, 2018 · 3 comments
Open

startup / instantiation speed #108

dnelson86 opened this issue Nov 11, 2018 · 3 comments

Comments

@dnelson86
Copy link

Hello,

I'd like to embed fsps into a framework which requires that instances be brought up and down rapidly. In particular, I'd like to get

import fsps
pop = fsps.StellarPopulation()

down to ~1 second or so (currently, for me, this takes more like 10 seconds or even longer). What are the major bottlenecks here?

@bd-j
Copy link
Collaborator

bd-j commented Nov 13, 2018

I haven't profiled it, but I think the hard work is being done in fsps/src/sps_setup.f90 which reads all the isochrone tables and the stellar spectral libraries and the nebular continuum tables, and then interpolates the stellar libraries to the isochrone metallicities. I suspect it's the interpolation that is taking a long time. If you have a narrow metallicity range it should be possible to read in a restricted range of isochrones and stellar spectra, and do fewer interpolations. But again, I haven't profiled sps_setup; for our use cases several second startup times aren't a problem.

Additionally, generating SSPs on the first call to get_spectrum is time consuming. For the MIST isochrones this can take quite some time; cleverly reducing the number of points in the isochrone tables might help, if this is part of your use case. cc'ing @cconroy20

@saethlin
Copy link

I've looked into this. The interpolation is a contributor, but only about half of all startup time. You won't get to 1 second by dealing with the interpolation; one could build FSPS with -Ofast and add !$OMP PARALLEL DO around the interpolation loops, but you'll need to add -fopenmp to the build flags for FSPS itself and also add -fopenmp -lgomp to python-fsps. This isn't a huge challenge but I'm skittish to submit PRs because if FSPS takes the patch first it'll break the python-fsps installation.

The harder obstacle is that calling the StellarPopulation initializer without arguments loads all the FSPS data, which is nearly half a gig of text files. IMO the proper fix is to have these loaded from some kind of binary format, be that huge Fortran array literals (compile time gets pretty silly) or a binary format that can be memcpy'd or mmap'd in at startup. Unfortunately such an operation is well beyond my primitive Fortran skills.

@bd-j
Copy link
Collaborator

bd-j commented Nov 6, 2019

Thanks for looking into this.

Only one of the set of isochrones text files will be read in at a time, but for the default MIST isochrones this is still ~140MB. The much larger file sizes versus say Padova is largely due to extra isochrone sampling on the TP-AGB evolutionary phase that probably doesn't make much a difference for output SEDs. So the number of isochrone points could be reduced, or the isochrone data could be turned into binary files like the spectral libraries. Hopefully we can get to this (really its an FSPS issue) sometime soon.

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

3 participants