Abstract simulation class prototypes as excuse to get coffee #753
Conversation
|
Hello @namurphy! Thanks for updating your pull request. Congratulations! There are no PEP8 issues in this pull request. 😸 Comment last updated at 2020-04-02 18:38:32 UTC |
namurphy
force-pushed
the
abstract-simulation
branch
from
37e357d
to
e8424c9
Compare
|
Hey, is everything all right? |
Codecov Report
@@ Coverage Diff @@
## master #753 +/- ##
=========================================
- Coverage 96.26% 96.17% -0.1%
=========================================
Files 55 56 +1
Lines 4957 4988 +31
=========================================
+ Hits 4772 4797 +25
- Misses 185 191 +6
Continue to review full report at Codecov.
|
I accidentally based this off of a different branch so I had to rebase, and then made a few other mistakes. I'm getting an error I don't understand though: 😕 |
|
I meant the coffee stuff, it sounded very much like a "no I have absolutely not been kidnapped, thank you" kind of situation! Run tox locally and see if it works? I don't see any obvious reasons why it would stop yet. |
Oh! Yep, I'm alright. A friend introduced me to coffee last year which I had never really drunk before, and I'm just now able to order plain coffee at a coffee shop while sounding like I know what I'm doing (but not any of those fancy coffee drinks which I still have trouble with).
I'll try this...thanks! |
|
Okay, good! Things seem to be working better now. The problem was related to me having created the branch based on an obsolete version of plasmapy/master on my laptop. I absentmindedly forgot to do a |
|
Before I forget...one of my (non-coffee related) goals is for us to have a set of prototype abstract interfaces for different aspects of numerical simulations put together by our 0.4.0 release. Once those are ready, we will be able to ask for feedback from the broader plasma simulation community in order to iterate on the interfaces in subsequent releases. We can also open up the conversation about creating open metadata standards (e.g., openPMD) for the different aspects of simulations. To quote myself from the Houston Community Planning Process meeting last month...
|
plasmapy/simulation/abstractions.py
Outdated
| def time_advance(self) -> NoReturn: | ||
| """Perform one step of the time advance.""" | ||
|
|
||
| pass |
There was a problem hiding this comment.
Putting these in as abstractmethods means they're required, and any simulation we end up implementing must have this sort of logic:
while time < self.end_time():
self.time_step()
self.time_advance()For a simulation of, say, 1e10 steps, that's a lot of Python function calls and a lot of time we'd be spending just calling these two functions, whatever they are. Then we cannot wrap this in Numba:
@numba.njit
def run(...):
while time < end_time:
time_step(...)
time_advance(...)which, for some simulations, could be a massive time saver.
I'm aware that I changed the interface pretty seriously; this may be something we can avoid with JITclass, but I still haven't started figuring that out except for "it's not as good as it could be right now". Though this part seems new and promising:
All methods of a jitclass are compiled into nopython functions. The data of a jitclass instance is allocated on the heap as a C-compatible structure so that any compiled functions can have direct access to the underlying data, bypassing the interpreter.
So maybe it's viable, doing it that way! I don't know just yet. Further research necessary.
There was a problem hiding this comment.
Yeah, those are good points. There is also the use case that someone may wish to have the simulate or run method call a Fortran or C code and essentially do nothing in Python.
I'm wondering if we would want to have a hierarchy of abstract base classes of varying specificity. The most generic one could have the initialize, simulate, and finalize abstract methods and nothing else. A more specific one could have time_step, time_advance, and so on. Having them be functions in order to facilitate JIT compiling is an interesting thought, which is reminding me of Julia's approach. I'll have to look into numba.jitclass too.
In any case, everything I put down so far is in the brainstorm phase, as we'll need to have a few discussions to figure out what should go in there. I'm also wondering if some of the things we want to include should be in a metadata schema rather than an abstract base class. Hm...
There was a problem hiding this comment.
I did look into jitclass a bit and I think it's going to work with this kind of approach. I'll upload the notebook later and I can show you at the telecon
What we could do, though, is to limit the ABC part to a more user facing part of the interface. It's not necessary to allow single time steps to be run externally, though it'd be nice for debugging, I guess; but initial conditions, running the loop, data save and load and possibly restart from saved data (probably some more, too) would be pretty consistently necessary for simulations.
There was a problem hiding this comment.
I did look into jitclass a bit and I think it's going to work with this kind of approach. I'll upload the notebook later and I can show you at the telecon
What we could do, though, is to limit the ABC part to a more user facing part of the interface. It's not necessary to allow single time steps to be run externally, though it'd be nice for debugging, I guess; but initial conditions, running the loop, data save and load and possibly restart from saved data (probably some more, too) would be pretty consistently necessary for simulations.
There was a problem hiding this comment.
I've also been wondering about how the different ABCs will fit together. I've been thinking for a while about how we need one each for initial conditions, boundary conditions, and the computational domain. We also need one to allow us to work with simulation results.
There are probably also going to be some components that users may not end up needing...like a data save and load may not be necessary for a short simulation that only gets interpreted interactively.
So many things to think about! 🙀
|
Following @StanczakDominik's comments above, I decided to tentatively remove abstract methods like |
namurphy
added
plasmapy.simulation
The stated purpose of this pull request is to create prototype abstract interfaces for broad classes of plasma simulations. The actual purpose is to give me an excuse to get a coffee and vegan banana muffin.
The idea is to enable us to "program to an interface, not an implementation," whilst being sufficiently caffeinated. If a variety of plasma simulation packages program to a standard simulation interface, then it would make it much more straightforward to switch between different simulation and analysis techniques.
What is here just now is just a start. We'll need to think about this more carefully, especially what information should be included/required and what we should name each of these abstract methods and attributes. The names should avoid ambiguity. Right now I'm wondering if
end_timecould be interpreted as the actual end time of the simulation, or as the end time that the user inputs to tell the simulation when to stop. We probably also want to keep the parts related specifically to the numerical method separate from the parts related specifically to the physical problem setup (which should be independent of numerical method).This pull request is brought to you by cup of coffee number 55 ± 5 (1σ) that I've had in my life.
Cross-references: #603, #662, #665, #714, PlasmaPy/PlasmaPy-PLEPs#24