-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathTODO
90 lines (53 loc) · 2.36 KB
/
TODO
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
* KIM v2
** Remove obsolete neighbor modes [DONE]
** Port to cmake [DONE, nice and easy]
** adapt core.?pp [mostly done]
*** implement dE/dr checks
*** implement writing parameters out
** check if other files need changes [DONE]
** the switch_boxes() and change_box() methods of Compute must check if
the KIM model supports the species and perhaps update the species
name <-> code mappings! [DONE]
** document DSL [started]
** adapt run_tests.py for DSL changes (no neighbor mode any more) [DONE]
** run tests
*** changing parameters buggy [DONE]
*** some crashes [DONE]
*** dE/dr checks missing
* TESTS
** the bash scripts should probably go into the C++ code???
how to expose a maximum number of tests to the KIM project pipeline?
how to have one command to test *everything* locally?
*** for the "everything" test: output if certain features are not
supported by the model
** additional test: "amorphous" system (perhaps poisson disk sampling
with some minimum distance)
** a better summary of tests (show only failure?)
** iterate tests also over all combinations of supported features
(force on/off, energy on/off) where it makes sense
** more lattice constants and so on
** test lattice optimization and so on
*** dE/dV = p, and p = virial/V (roughly, signs may be wrong)
given that, couldn't we use the virial as a gradient for box size
optimization? test!
** test changing parameters (hard to say how to verify something here)
* A simple scripting language to drive the program.
* Benchmark replacing map with unordered_map!
* Neighborlists using ghost atoms are somewhat implemented
** neighbor lists need "skin" [This is possible already but Compute
just sets a zero skin. This must be user-definable because the
optimal skin dpends on what should be done with the
box. E.g. lattice MC doesn't need skin at all.]
* Way to optimize box volume and shape in addition to positions
** Simple scaling of abs(a), abs(b) and abs(c) is already possible.
*** although it seems buggy for non-orthorhombix boxes.
* All in all the following properties should be calculated for
different lattices:
** cohesive energy
** lattice constant(s) and atomic positions
** bulk modulus with and without atomic relaxation
** stiffness tensor with and without atomic relaxation
** surface properties
*** relaxation, stress, energy
* Monte-Carlo
* ...