-
Notifications
You must be signed in to change notification settings - Fork 15
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
MLP growth function #7
Comments
Computing growth is tiny tiny tiny compared to the computational budget of a reasonable sim, no? |
I would personally opt to use proper solvers instead of emulators wherever you can afford it. But that's my preference 😉 |
No, I agree with you.
I agree that for any main runs one should use proper solvers. They will also hopefully be of reasonable size and volume where the impact of growth function should be negligible, as you say and as can be seen from the last 256^3 panel. But most of the methodology development, I think, will be done for smaller boxes. From the above figure, 32^3 and 64^3 seem to be completely dominated by growth function. Even for 128^3 there are 2-4x gains with small number of time steps. Hence for developers like us, having an easy access to MLP can be massive time gains. Currently I have set it up at the UI level in my local branch to look like this
|
With Epod, we now have MLP emulators for growth function that are quite fast.
Do we want to include them in official pmwd code, and if so, how? Ideally one would like to keep a way of having both, MLP and odeint the way it is currently implemented, with a way of switching back and forth between them.
I have a sample version that I am currently using, I will create a different branch to push it as an example and we can discuss that further.
The text was updated successfully, but these errors were encountered: