Running qdyn6 without a fep files gives the error that the [atoms] section is missing from the fep file. It should say that it doesn't have a fep file at all.

Hi guys,

I recently decided to switch from Q5 to version 6 and compiled it using intel 17.0 and intel mpi 2017. Everything works fine except that Qdyn6 gets stuck whenever it reaches the printed "Nonbonded pair list generation" section. This happens whenever solvent polarisation restraints are turned on.

Any idea if there is something to fix somewhere in the code? I compiled it exactly the same way as David did, on the same supercomputer cluster. But I am probably using a version that has been slightly updated on GitHub. I will let you know if I figure that out. PS: I tired that on several systems that worked well with Q5.

Cheers!

Pierre

Using qprep6 on triolith to average a dcd into a pdb. Log file gives error ">>>>> ERROR: invalid coordinate array size." and a long fortran error beginning:

"*** glibc detected *** /home/x_davbl/qsource/Q6/bin/Qprep6: double free or corruption (!prev): 0x00000000023077f0 ***"

It does produce an output pdb, but I can't say if it's correct or not.
qprep6_error.zip

I'm working on translating some forcefield amino acid parameters to Q's format, but I have a question about one of the parameters used in the [torsions] section of the .prm file. According to the Qmanual, the 8th column is the "number of paths", which seems to be defined as:

is the number of ways that a two-atom torsion can be defined, i:e: the product of the number of atoms bonded to the two middle atoms. It is used to distribute the force over all the atoms involved.

However, this doesn't seem to match the values. I would understand it if all the carbon-carbon bonds would be defaulted to 9 but that doesn't seem to be the case as you can see here: https://github.com/qusers/Q6/blob/master/ff/amber14sb/qamber14.prm#L759-L762

Further, I can see that whenever wildcard atom flags are present, these values seem to be able to go higher than 1.0. However, for impropers where you have the 4 atom types defined, this variable always seem to default to 1.0, as seen here:

https://github.com/qusers/Q6/blob/master/ff/amber14sb/qamber14.prm#L856-L861

I was looking at the other forcefield definitions to understand this, but for OPLS2015 it seems to be always left as 1.0, as seen here:

https://github.com/qusers/Q6/blob/master/ff/oplsaam2015/qoplsaa.prm#L749-L767

I then tried looking at the Fortran code to see how was this #paths variable used but I couldn't find it. Is this some sort of deprecated parameter? And is it fine if I would define a Amber-based forcefield using this #paths parameter as 1.0 for all the torsions defined?

Description of problem

Q6 crashes when provided with the following input files
files.zip.

Said input file is an EVP/FEP calculation, based on a multiring sugar system.

Steps to reproduce

run "Qdyn6 eq1.inp" on a standard Q6 installation. The Q instillation can be replicated with the following singularity container.
quontainer.txt

Known information

According to Valgrind debugging the crash is due to an illegal access on bondene.f90:530 when accessing an array defined at qatom.f90:465. Given that this array is defined as being sized as nqat across and is being accessed as nqbonds it is highly likely that the program fails when nqat > nqbonds which occurs in multiringed systems.

Qdyn6 compiled with optimizations doesn't fail on T==NaN and terminates normally.
Not urgent, but could be annoying.

I tried only with gcc4.8.4 but it seems like it's more general:
https://stackoverflow.com/questions/15944614/is-it-possible-to-make-isnan-work-in-gfortran-o3-ffast-math

A test case (timestep of 10fs): asd.zip

in two different systems, late installations of Q6 (since September 2023 at least) are creating memory problems (segmentation fault). The problem has been tracked with the debug compilation and we have identified that it is the LRF calculation which produces the errors. Before going into more detail, is that an identified issue by the developers?

Hi,

I noticed another related issue and asked David about it. It turns out that he had the same problem.

When using Q6 to solvate my system (runs for a small compound in water), it adds waters around the sphere edge (a bit beyond too). This was already the case with Q5 but did not cause any problem. However, I end up with Shake failure issues with Qdyn6, unless I clean up all waters outside the sphere edge and change the "solvent radii" accordingly in the topology (or just increasing the "solvent radii" value seems to fix it in most cases). Maybe this could help fix another bug.

Cheers!

Pierre

Hej,

Food for thought.

At the moment and since the beginning we've been using a default Coulomb constant which deviates from the experimental value of 332.06371 kcal/mol Å e^-2

It might be good to think about changing the default value.
Some interesting reading as to why it might be a good change in the link below.

http://dx.doi.org/10.1007/s10822-016-9977-1

Long time listener, first time complainer:

The readme.txt for Q6 doesn't include instructions for intel or impi.

I made a topology in qprep using a library that had charge groups containing two H43's and no H42's, e.g. when making charge groups, I accidentally labelled H42 as H43 while also naming H43 as H43. Qprep made that topology with no errors. One should, of course, be more careful. Still, it might be useful if qprep noticed the charge groups made no sense.

Hej @ all!

Just a food for thought, should we release a new version of Q6 with the few bug fixes we had around May or June this year?
Should just be a bump to the minor version number, to make sure the bug fixes are used by people?

Happy for your feedback!

I compiled Q on Rackham (intel) and with mpi it shows error unknown option -Nmpi. But even with that it finish. When I submit job it finish imidietly with this kind of error:[r101:2335] *** An error occurred in MPI_Allreduce
[r101:2335] *** reported by process [1808072705,0]
[r101:2335] *** on communicator MPI_COMM_WORLD
[r101:2335] *** MPI_ERR_OP: invalid reduce operation
[r101:2335] *** MPI_ERRORS_ARE_FATAL (processes in this communicator will now abort,
[r101:2335] ***    and potentially your MPI job)

I tried different versions of intel and with intelmpi or openmpi. Everytime crash with similar error. When I run the same job on different cluster and local with Qdyn6 it works without problem.

Any idea how to solve it?