Ux/units #2233
Ux/units #2233
Conversation
|
Note to reviewer: Spack is broken on stable for some reason out of my control; Develop works fine, though. |
|
Note about performance: This is only at the outer most 'shell' of our API. Everything below is So, it comes down to constructing a class per such API call, some math ops, and a check. The most |
- inline variables - use precise_units - add units to add_ion - more checks for cable_cell_params - remove spurious TODO
Co-authored-by: boeschf <[email protected]>
There was a problem hiding this comment.
So this is the second round. Expect the Python stuff in round 3. A couple general remarks:
- what type is the expression
1*U::msconverted to? It should bequantitybut I'm unsure - the reformatting of many files makes the review tedious. we should start thinking about an automated way (clang-format, git pre-commit hooks, CI checks etc) in order to minimize changes
| using engine_type = std::mt19937_64; | ||
| using seed_type = std::remove_cv_t<decltype(engine_type::default_seed)>; | ||
|
|
||
| constexpr static auto default_seed = engine_type::default_seed; |
There was a problem hiding this comment.
| constexpr static auto default_seed = engine_type::default_seed; | |
| inline constexpr auto default_seed = engine_type::default_seed; |
There was a problem hiding this comment.
what about adding a function which generates a random seed value, possibly using std::random_device?
There was a problem hiding this comment.
Hm. I am unsure whether I like that. The next step here should be to eradicate std::random and use r123 everywhere. Then seeding should be a function of cell gid and the relevant item's index. For example one would seed an event_generator with gid*100 + lid where lid is the running count of the generator in the list. We might consider giving users a convenience function/helper thing there to partially automate this.
In general, I refrain from this for reasons of reproducibility, since all kinds of ordering or reentrancy (word!) come into play. Thus, even now, I'd suggest using the gid + some offset as a seed in recipes.
Yes, it's a simple way to get a
Agreed, ten times over. I am also on record about not really caring about the actual style, just about consistency and automation. |
|
cscs-ci run daint-gpu |
The core issue here is to add units to the user facing API. I decided on using the LLNL/units
library, which offers conversion and checking at runtime. Runtime is a requirement -- as much
as I love static guarantees --, but keeping the interface uniform between Python and C++ is a
must.
While setting this up, I noticed the severe lack of IDE/LSP support for Arbor, so I added typing
stubs using https://github.com/sizmailov/pybind11-stubgen. The conjunction of typing and units
exposed misuse of pybind11 in several places, so next I had to massage the ordering of bindings,
adjust the specification of default arguments, and add the odd missing binding.
The schedule/event generator interface was tightened up, hiding the
*_implstructs and exposingonly the type erased
scheduleobject. That in turn required de-generification of the Poissonschedule. Now, Mersenne twister is the only choice and I will remove that later on for the CBRNG
we are already using elsewhere.
Currently, units are used for:
Adding units to mechanism interfaces is interesting but requires more work and thought, so
I'll defer that to a later point in time. We'd need to adjust modcc to expose and check units
and devise a scheme to handle missing units.
Generic TODOs; some might spin off into separate issues.
rename py::iclamp OR cpp::i_clamp for consistencycovered by Consistency in Naming #2239Use CBRNG for Poisson schedulecovered by Use CBRNG for Schedules #2243Closes #1983
Closes #2032