Q parses only the first 80 characters of the fep-file-path (and crashes with non-sense error).

E.g. the following input will crash Q with no "atom-section found":
fep /path/to/wherever/i/store/my/genious/fepfile/because/it/stays/the/same/for/all/my/runs/fep.fep

Q tries the following "file" and is crashing with "[atom]"-section not found in fepfile:
/path/to/wherever/i/store/my/genious/fepfile/because/it/stays/the/same/for/all/

Workaround:
copy the file into local directory or use a soft-/hardlink ...

Qdyn5p, version 5.06 crashed when using the Intel Fortran compiler at version 15.. while optimizations (-O3) are turned on. The crash happens in the torsion subroutine code near the entry point and is not found for either version 12.1.4 or 14.0.2 of the compiler, or when optimizations are disabled with -O0.

If other compiler dependent crashes are found, please add them to this issue

Currently there are a number of hard coded limits in both the qatom and the qprep module. Those concern the maximum number of atoms in the FEP file and the maximum number of atoms in a residue. Even though those limits are violated, Q will happily build a topology and try to run it with no chance of succeeding.
This should be changed to either

• fail the topology building / run initialisation with warning to the user
  or
• replacing of hard coded limits by dynamic memory allocation

This issue is just for me as a reminder to fix this.

When using the qcalc nonbond monitor with a FEP file containing no vdW data for qatoms, it will crash while trying to access the vdW data arrays.
Expected is the use of the default vdW values from the topology.
(Same issue could be present for charges, not checked yet).

Proposed fix: Setting the arrays explicitly to the topology values on FEP file loading before vdW data from the file is checked in.

Qprep does not complain with the following pdb file, but it will read the first HOH different from the other ones. Apparently its counted as solute and not as solvent molecule and exploding.

--snip--
PRO
HOH
SUB
HOH
HOH
HOH
.
--snap--

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?

A test of a binary build with prec = singleprecision fails the validation tests (both serial and parallel) with hot atoms in the outermost layer of the water sphere, right before causing a shake failure.
Up to this point the tests proceed as expected, with energy values inside the variation of builds with prec = doubleprecision. I have started to look into this and found some more cases of not using the defined precision, but I have not been able to find the root cause of the bug yet.

Begin forwarded message:

From: Matthew Mills [email protected]
Subject: Q Problem
Date: 30 Jun 2015 07:59:07 CEST
To: Christoffer Lind [email protected]

Hi Christoffer,

I have been using the Q program a bit more recently, and today found what seems to be a bug.
I was working on a toy system of 6 atoms, and wanted to set 8 of the interaction pairs as soft pairs using the [soft_pairs] section of the FEP file. I got a segfault whenever I set over 6 soft pairs.

Looking in the qatom.f90 file, there are two lines (912 and 913 in current github version):

allocate(iqexpnb(nqat))
allocate(jqexpnb(nqat))

which contain the indices of the interacting atoms i and j. Given that in a system of N atoms with no bonds, the max number of soft pairs would be N(N-1) / 2, I think this allocation is incorrect as it limits the number of soft pairs to N which is not right unless I am missing something important.
I changed it to

allocate(iqexpnb(nqat_(nqat-1)/2))
allocate(jqexpnb(nqat_(nqat-1)/2))

and it works fine (no segfault). Better would be changing it to allocate the arrays using the actual number of soft pairs in the input file, but given the typically small number of Q-atoms in a system it would not save much RAM.

I couldn't find a good way to get this to the Q-users attention so I thought I would try talking to you. Let me know if there is somewhere better to discuss this.

Thanks!
Matt Mills

Here's a copy and paste of a user case.

I haven't checked with the latest push to master from Paul. Any clue if this will work with the latest version. The issue is in qdyn generation of .en files, I guess.

Dear Johan
I hope you are doing well!
We have encountered a problem with Q. Could you please refer us to someone who can possibly help?

The problem is the following:

We ran MD simulations in batches of 10,000,000 steps. When we tried to analyze the results in the .en files using Qfep5 we got a segmentation fault (core dumped).
However, when we do the same analysis for md runs of 1,000,000 steps and less we have no problem. I guess this is because the program only properly writes steps with 7 digits and beyond that puts "*******" with which Qpef can't
deal. In there a workaround (other than having to re-run the simulations)?
Thanks and regards,

Hanoch

Hanoch Senderowitz
Associate Professor
Department of Chemistry
Bar-Ilan University
Ramat-Gan 52900
Israel
Phone: 972-3-7384588
e-mail: [email protected]

Calculated angle energies of qangles are too high. Energies for non qatoms look reasonable.

`========================= List of defined calculations ========================
1 angle, qangle energy between atoms 1981, 1984, 1985
2 angle, qangle energy between atoms 1986, 4872, 4875
3 angle, angle energy between atoms 4878, 4875, 4872

----------------------------- Calculation results ----------------------------

file frame 1:angle(�) 2:angle(�) 3:angle(�) V_angle
fep_050_0.000.dcd,frames=every 10
/User...50_0.000.dcd 10 118.26 165.12 106.15 92.64 115.56 0.70`

example_files.zip

Currently, the only way to seed the random number generator for Q is by the user providing the seed for it. It would be good if a seed from the system random number pool could also be chosen, and later printed to the log file, if the input seed is e.g. negative.

I'll add this to the Q6 version, because I already have something like this in place for the QCP random number generator.

It appears that when stating the random_seed in the input file it requires a specific position of random_seed to give the seed that one has stated.
e.g.
steps 5000
random_seed 92
stepsize 0.1
initial_temperature 1
bath_coupling 1
temperature 10
shake_solvent off
shake_solute off
lrf on
separate_scaling on
Gives you the random seed 92.
However
steps 5000
stepsize 0.1
random_seed 92
initial_temperature 1
bath_coupling 1
temperature 10
shake_solvent off
shake_solute off
lrf on
separate_scaling on
returns random seed 1.
Not assigning a random_seed at all, returns random_seed 1 as well.

Hi all,

A user in our group got the following odd error on running a replicate in a fep step.

"It looks like orte_init failed for some reason; your parallel process is
likely to abort.  There are many reasons that a parallel process can
fail during orte_init; some of which are due to configuration or
environment problems.  This failure appears to be an internal failure;
here's some additional information (which may only be relevant to an
Open MPI developer):

  orte_session_dir failed
  --> Returned value Error (-1) instead of ORTE_SUCCESS"

I'm guessing the error is coming from hardware, a faulty node or mpirun options.
Just wondering if anyone has seen this error too.

Cheers,

M.

When running f0f004.inp, Qdyn5p will end with a Shake Error after a couple minutes.
When running with qdyn5, (serial version), there is no shake error.

I am not sure is this is a bug, or if this is very unlucky, of even if this is exptected.

Files and more information can be found in:
https://www.dropbox.com/sh/5oboetmc2mz2yyp/AADIVOCtw6WH3vigghBg4M4xa?dl=0
password: Bug9

If a string:string parameter appears before a string:int/real/real8 in a section of a Q input file, the parser never reaches the latter one, because it fails completely when trying to convert a string to int/real/real8.
See the commit in development/miha
If someone can run the tests with the modified version, I'd appreciate it.

Reported by Johan Åqvist.
When running a three state FEP where one did not explicitly declare a value for the third lambda value in:

[lambdas]
1.00 0.00

But one did specify in the .fep file that it is in fact a three state FEP:

[Fep]
states 3

A first step in the process will seemingly work fine and assign the third lambda value to zero, but then the next step will loose it's parallelization. The process keeps on running fine, but the parallelization is lost. Needless to say this is only an issue when running qdynp.
For now this bug report is incomplete. Working on a reproducible example error.

Qfep does not proprely with more than about may be 500 files.

Qprep5 lacks an automatic GAP/TER detection between chains.

Q handles two amino acids in a sequence always as connected, even if the respective CA/N and C/O are well more than bond-distance away. This yields very confusing torsions that cant be overseen but misinterpreted as, e.g. bad fep parameters.

Observed behaviour:
unexplainable explosions in subsequent dyn/fep runs.

Expected behaviour:
Error & Crash during topology generation.

Expected and desired behaviour:
Warning in log and automatic insertion of a gap, if distance between atoms more than X (e.g. 5A)

Example PDB file to reproduce the issue (copy and paste):
(note: uncomment the #TER ASP 1 line, to see expected behaviour).
ATOM 1 N ASP X 1 43.722 92.117 12.054 0.00 0.00
ATOM 2 H ASP X 1 43.795 93.018 11.542 0.00 0.00
ATOM 3 CA ASP X 1 44.564 91.005 11.604 0.00 0.00
ATOM 4 HA ASP X 1 45.566 90.851 11.967 0.00 0.00
ATOM 5 CB ASP X 1 43.775 89.738 11.855 0.00 0.00
ATOM 6 HB2 ASP X 1 42.813 89.848 11.396 0.00 0.00
ATOM 7 HB3 ASP X 1 43.477 89.615 12.946 0.00 0.00
ATOM 8 CG ASP X 1 44.274 88.367 11.401 0.00 0.00
ATOM 9 OD1 ASP X 1 45.643 88.365 11.540 0.00 0.00
ATOM 10 OD2 ASP X 1 43.816 88.098 10.119 0.00 0.00
ATOM 11 C ASP X 1 44.878 91.037 10.097 0.00 0.00
ATOM 12 O ASP X 1 43.976 91.263 9.218 0.00 0.00

TER ASP 1

ATOM 13 N HID X 2 40.996 86.714 20.227 0.00 0.00
ATOM 14 H HID X 2 40.120 86.252 20.293 0.00 0.00
ATOM 15 CA HID X 2 41.266 87.364 18.926 0.00 0.00
ATOM 16 HA HID X 2 41.553 88.359 18.995 0.00 0.00
ATOM 17 CB HID X 2 42.412 86.694 18.201 0.00 0.00
ATOM 18 HB2 HID X 2 43.255 86.565 18.892 0.00 0.00
ATOM 19 HB3 HID X 2 42.071 85.677 17.961 0.00 0.00
ATOM 20 CG HID X 2 43.019 87.321 16.952 0.00 0.00
ATOM 21 ND1 HID X 2 44.036 88.345 16.936 0.00 0.00
ATOM 22 HD1 HID X 2 44.318 88.854 17.791 0.00 0.00
ATOM 23 CE1 HID X 2 44.340 88.464 15.620 0.00 0.00
ATOM 24 HE1 HID X 2 45.036 89.229 15.265 0.00 0.00
ATOM 25 NE2 HID X 2 43.599 87.689 14.853 0.00 0.00
ATOM 26 CD2 HID X 2 42.763 87.005 15.623 0.00 0.00
ATOM 27 HD2 HID X 2 41.984 86.429 15.168 0.00 0.00
ATOM 28 C HID X 2 39.958 87.499 18.042 0.00 0.00
ATOM 29 O HID X 2 39.741 86.839 17.044 0.00 0.00
TER HID 2

The order of the appearance of energy files in the qfep input can change the results if they are scrambled enough (normal inversion has no effect).
Desired behaviour is no dependence on the file order.

Hi,
Just a heads up.
On newer version of intel-fortran, at least since Composer XE 2013 SP1 the -i-static compiler option is deprecated.

Instead of
-i-static
one should use
-static-intel

Now, that is if one wants to be explicit, which, is usually a healthy policy in my opinion. But, it is NOT necessary as the default is now -static-intel.
If one wanted different one should explicitly say -Bdynamic

Hej,
I have recently seen the milestones for the development and was wondering why you want to kill the optimisation for the tools?

Thanks for answering

Paul

The torsion function may ignore the last atom of any torsion, if it is not defined in the parameter file. This can cause wrong torsion assignments if parameters are missing for molecules.

Proposed fix: Fail the topology generation on any missing parameters.