Hi all:
Going through a local HADDOCK2.4 installation and testing on a Linux box (Fedora Core 33, gfortran/gcc 10.2.1, intel-x86_64bit-linux arch); most of this has been smooth but two issues have arisen:
1. compilation flags: compiling cns solve 1.3 without or with the HADDOCK extensions using the default flags or adding -static as suggested here gave type mismatch errors in about 50% of the *.f files before ultimately failing to compile, e.g.
xtarget.f:2406:72:
2406 | & HEAP(DERIV))
| 1
Error: Type mismatch in argument ‘deriv’ at (1); passed INTEGER(8) to REAL(8)
I’ve been able to suppress this and get a complete build by adding a -fallow-argument-mismatch flag to the gfortran options and things seem to work. Any thoughts on this?
2. odd behavior restarting failed it0 jobs in tests: in trying the protein-protein and protein-DNA test or example scripts, I saw a small number of crashed structures in it0 (~1-2%). HADDOCK would identify these as crashed at the end of it0, but would only restart one of those jobs before handing, e.g.
calculating structure 743 queue command: /bin/csh protein-protein_run1_it0_refine_743.job
Structure 743: running
Structure 755: failed
Structure 889: failed
Structure 755: failed
Structure 889: failedRestarting failed structures…
Structure 755: failed
Structure 889: failed
(hang here until interrupted, then…)
Traceback (most recent call last):
File “/usr/local/haddock2.4-2021-01/Haddock/RunHaddock.py”, line 645, in
run[‘haddock_dir’], run)
File “/usr/local/haddock2.4-2021-01/Haddock/Main/MHaddock.py”, line 640, in ForAllIterations
time.sleep(5)
Quitting HADDOCK and restarting would properly clear the top failed structure off the queue, then hang again = with multiple quits and restarts, I could get through the failed it0’s and proceed properly through the rest of the refinement without issue. Any chance this is related to the workaround from 1), or are there options on automating this?
Otherwise easy to get going out of the box – thanks as always!
Kevin