Local LINUX: Compilation flags, it0 restart behavior

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: failed

Restarting 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

Hi Kevin

Glad to see you still find time to get your hands dirty :wink:

Compiling CNS is always a challenge. I did compile recently on CentOS7 using gcc/gfortran 9.2. Here are the compiler flags I used:

# fortran options
F77 = gfortran
F77STD = -fdefault-integer-8 -w
F77OPT = -O3 $(CNS_MALIGN_I86) -funroll-loops -ffast-math -march=native -mtune=native -static
F77FLAGS = $(F77STD) $(F77OPT) $(EXT_F77FLAGS) $(F77BUG)

# C options
CC = gcc
CPP = g++
CCFLAGS = -O -DINTEGER='long int' -DCNS_ARCH_TYPE_$(CNS_ARCH_TYPE) $(EXT_CCFLAGS)

# link options
LD =gfortran
LDFLAGS = -w $(EXT_LDFLAGS)

As for the crashes you are seeing, what are your settings in Haddock/Main/MHaddock.py ?
You seem to be running locally on your system.
I would recommend:

jobconcat["0"] = 1
jobconcat["1"] = 1
jobconcat["2"] = 1

#define the job behavior (using local /tmp or not)
# - for grid submission set to false
# - for local runs, if the network is a bottleneck better set it to true
tmpout=False

Hi Alexandre:

Glad to get the chance to get my hands dirty – and thanks for getting your hands dirty with the quick and informative reply! In response:

1). compiler flags Trying the flags you suggested and some variants, and it looks like the -fallow-argument-mismatch flag is absolutely required for gfortran 10.x as part of a warning → error change they instituted from prior versions ( Gfortran type mismatch error flag | Scientific Computing | SciVision ). Adding that flag seems to give working code, will run with it as-is.

2). crashes Correct that I’m running this locally, and with the Haddock/Main/MHaddock.py settings as you listed. FWIW, the machine that’s exhibiting this behavior is a 48 core Linux VM; a standard 8 core workstation seems to be absolutely fine with the tests and not showing this problem. It’s a hassle but not unstoppable = glad to try any tweaks to work around it as you or others might suggest, but at least we can get some work done in the meantime.

Hi Kevin

Just installed the 10.2 compilers - thanks for the flag info!

For the crashes, you could check if running 40 jobs in // instead of 48 makes things better.
For the total run time it won’t make a huge difference.

How much memory to you have on that system?

Cheers
Alexandre