dedalus
dedalus copied to clipboard
DedalusProject
Allow non-simulation processes to handle e.g. IO
Original report (archived issue) by Geoffrey Vasil (Bitbucket: gvasil).
Joe Werne (who really knows a lot about what he's doing) does something equivalent to the following with IO:
We're going to want the data in different formats, orderings, FFT spaces, reductions etc.
When it's an IO time step, it's a good idea to have the compute cores dump out their data in the format they happen to have it in at the time. After that, a smaller number of dedicated analysis cores clean up and package the data into the format requested by the user.
I.e., Given the user's requested data product, the analysis cores ask for raw data from the compute cores at a point in the compute loop that corresponds closest to the needed type. The compute cores dump out as fast as possible, and move on. If we want the compute cores to limit the overall efficiency, then the number of analysis cores will scale in some proportion to the frequency of output, and complexity of reduction.
At worst, the compute cores create a backlog for the analysis cores. In this case, at the end of a simulation, the compute cores can switch to analysis and help clear the backlog.
Original comment by Keaton Burns (Bitbucket: kburns).
And if you're within a few minutes of a hard wall-clock limit, then stop computing and all cores switch to saving everything nicely.
Original comment by Keaton Burns (Bitbucket: kburns).
- Edited issue description* changed state from "new" to "on hold"
Original comment by Keaton Burns (Bitbucket: kburns).
- changed title from "IO general idea" to "Allow non-simulation processes to handle e.g. IO"
We generally haven't seen IO being a computational bottleneck, even with the new "gather"-based file handlers where global IO is handled by a single root core. Closing this for now.