find gromacs data dir in docker container

[jmbuhr]

looks like getting the gromacs data dir https://github.com/hits-mbm-dev/kimmdy/blob/7352700f4928d3b26c0de406f56135002cd19066/src/kimmdy/utils.py#L9-L19 is not working in the docker container for the tests. On my machine I end up with /usr/share/gromacs/, which is where gromacs is usually installed via apt, but in the container it ends up as /usr/local/share/gromacs/, in which it then doesn't find the forcefield directory top.

Does the share/gromacs directory need to be explicitly copied in your docker image @KRiedmiller ?

WARNING  root:parsing.py:137 top include amber99.ff/forcefield.itp could not be resolved. Line was dropped.

[KRiedmiller]

The gmx executable is indeed in /usr/local/bin. I guess on your machine, it only works because it implicitly resolves symlinks?
gmx first calls the gmx-chooser since there are 4 different gmx versions installed. All gromacs versions are below /gromacs/, so e.g. /gromacs/AVX2_256_ts/share/gromacs/ Why is this needed when there is a ff provided? Or is this a test for when its missing?
The test should all still run or?

[KRiedmiller]

I thought the test use the forcefield we provide?
If this functionality is needed, the most universal approach would be to call gmx, and search in the output for Data prefix: /gromacs/AVX2_256_ts

[jmbuhr]

No, symlinks are explicitly resolved in line 17. I also have a test with the urea example from the gromacs website, which uses a builtin forcefield.

[jmbuhr]

ok, yes. if gromacs can work with a topology, kimmdy should be able to as well, so we need this data dir resolving to be as robust. I'll switch to asking gmx directy for the data dir.