MercuryMonth April 2018
- Thomas Weinhart
- J. M. F. Tsang
- Irana Denissen
| What | Who | Priority | Comments |
|---|---|---|---|
| Make new alpha/beta | Anthony? | ||
| Check all \todo's and \bug's | Thomas and Ant? | ||
| Review JIRA jobs | All | ||
| Complete new coarse graining tool (including more doc's) | Thomas | ||
| Complete binary restart files (i.e. include protolib) | Ant and Thomas | ||
| Contact laws for sintering (?) | Yousef? | ||
| MercuryPromo Video | Thomas, all. | ||
| Test suite for parallel | Needs Anthony to setup the cmake infrastructure for MPITesting Marnix can then lead the transfer of knowledge to the new students about the parallel code (what tests are needed) | ||
| Shifting Maser boundary (for hoppers) | Jonny | ||
| Frozen particle base generation | Jonny | Automatic generation of frozen-particle rough bases, with the ability to specify random seed, topographical lengthscales, and amount of randomness/latticeness. Irana: is it an idea to have a separate ParticleHandler for fixed particles? For a) probably better performance and b) easy check if there is a rough bottom and c) easier changes in the rough bottom. | |
| Speed optimisation for fixed particles | When doing long-chute simulations, the fixed particles cause a hefty slow-down compared to having no fixed particles (flat bottom). Even having just a rough bottom and no flow particles already takes a non-trivial amount of time to calculate. | ||
Non-spherical particles: interactions with walls
| Deepak and Irana? | ||
| Non-spherical particles: template on particle type | Deepak and Irana? | ||
| Non-spherical particles: add & test Jacobian, Hessian etc. for non-ellipsoids | Deepak and Irana? | ||
| Speed testing | vtune is intel software to measure peak performance; Wouter/Edwin vd Saar has access to it. | ||
| Parallel code: read from serial restart file | It would be cool if we can merge any N restart-files to M restart-files, where N != M | ||
Parallel code: user manual for what should be done before calling solve,what in setupInitialConditions, etc. | |||
| Speed up compilation times | low | make fullTest now takes ages, especially with the USER directory turned on. This is annoying, and there are some tips and tricks on the internet to speed up compilation times. JMFT: Just 'make' (not 'make fullTest') on cygwin takes a very long time (over an hour). | |
| Update existing example driver codes | For example everything in the FlowRulePaper-folder needs to be updated. | ||
| Improve documentation and tutorials | low | There are a number of features each used by only one or two people in the USER directory in specific applications. It would be nice to document them so that other people can use them as well. | |
| Catching SIGINT and force-writing .restart files | Sometimes a process is interrupted in the middle of writing a .restart file. This means you have an incomplete .restart file and it is not possible to restart the simulation. It would be better to force the writing of a .restart file (maybe call it .restart.interrupt) using an unbuffered stream when a process is interrupted. But I'm not sure how to do that without breaking portability to Windows. | ||
| Change how RNG::randomise() sets the random seed | The random seed is currently set to be time(nullptr). This means if you start two simulations at the same time then they will use the same random seed. This is annoying if you want to do a bunch of different runs as a batch job. Could there be a better way of setting a random seed, e.g. using /dev/random on Unix systems? | ||
| Generalise BaseParticle::info_ field | Jonny | The last column in a .data file is used to store miscellaneous, user-defined information about each particle — by default, the particle's species. BaseParticle::info_ is currently stored as a Mdouble but it would be useful if this could be generalised to arbitrary data (probably excluding spaces), without breaking compatibility with existing .data files. | |
| Shorten tests | Some tests take too long; a shorter simulation time or smaller system should be considered. Definitely too long (>10s, or >1s unit test): SilbertPeriodicSelfTest, On the long side (>5s): |