Insufficient checks for input parameters related to wall options
Defining walls around a simulation box needs to define atom type names for each wall (wall_atomtype). It's a string and therefore easy to mix up (as I did, mixing a name of atom and a molecule).
Currently there is no special control logic for wall options available and the grompp program generates happily a topol.tpr file, which contains this:
wall_atomtype = -12345 wall_atomtype = -12345
Now, running the mdrun program with the topol.tpr, generated above, a core dump is saved.The situation is described more in detail here:
- as the structure gpp_atomtype_t does not contain an accidentally configured wrong atom type name, the method get_atomtype_type returns NOTSET (-12345) in the file src/kernel/gpp_atomtype.c:76
- without any further control, the structure t_inputrec gets the value
-12345in the file src/kernel/grompp.c:855 (ir->wall_atomtype[i] = get_atomtype_type(opts->wall_atomtype[i],at)). This is the location where I would appreciate at least some warnings about the situation.
- now, in the mdrun code, an array "ntw" is initialized with these values - NOTSET; src/mdlib/wall.c:121
- and finally, touching the array "nbfp" outside the boundaries, the core dump happens at line src/mdlib/wall.c:170 (Cd = nbfp[ntw[w]+2*at];)
#1 Updated by Teemu Murtola over 6 years ago
- Tracker changed from Feature to Bug
- Subject changed from Additional control for input parameters related to wall options to Insufficient checks for input parameters related to wall options
This is clearly a bug, so marked as such instead of a feature request. Also changed the title to match.
#2 Updated by Janne Blomqvist over 5 years ago
Also, when using user-generated potential tables for wall interactions (wall_type = table), then wall_atomtype should not be necessary. Currently it's necessary to set wall_atomtype to some existing atom types, even though AFAICS they are unused when wall_type == table.
#4 Updated by Mark Abraham over 4 years ago
- Status changed from New to Closed
On Janne's point, the tables define the functional form, but they do not encode (e.g.) the LJ parameters, which are still looked up from the atom types (per do_walls() in src/mdlib/wall.c). Happy to be proved wrong by some .tpr files, though ;-)