qusers / q6 Goto Github PK

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!

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

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.

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?

Long time listener, first time complainer:

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

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

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.

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?

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

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

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