What to do with the note : The following floating-point exceptions are signalling: IEEE_DENORMAL?

Hello!
This may be a real beginner issue, but I haven’t find the solution in this forum so far.

So here’s my problem :

I’m using a batch/queuing system (slurm) to run haddock2.4. Everything is fine when I call haddock2.4 to create the runX directory and the run.cns file. Once I confirmed that the run.cns files and directories name look ok and modified the queue parameters for :

{===>} queue_1=“sbatch”;
{===>} cns_exe_1="/project/chlandry/prg/haddock/2.4-2022-01/cns_solve_1.3/intel-x86_64bit-linux/bin/cns";
{===>} cpunumber_1= 8;

.I try to call haddock2.4 for the second time from the runX directory to start the docking. And I get this :

Starting HADDOCK on: 2022-05-21 14:09:46

HADDOCK version: 2.4 - January release
Python version: 2.7.18 (default, Mar 04 2021, 23:25:57) [GCC]
parsing run.cns file
parsing run.param in /project/chlandry/users/palem147/haddock/run1/data
reading parameters from the file /project/chlandry/users/palem147/haddock/run1/data/run.param
setting some variables:
N_COMP set to: 2
RUN_NUMBER set to: 1
HADDOCK_DIR set to: /project/chlandry/prg/haddock/2.4-2022-01/haddock2.4-2022-01
PROT_SEGID_2 set to: B
PROT_SEGID_1 set to: A
PDB_FILE1 set to: ./sho1_alone.pdb
PDB_FILE2 set to: ./AF_pbs2.pdb
PROJECT_DIR set to: .
N_COMP 2
RUN_NUMBER 1
HADDOCK_DIR /project/chlandry/prg/haddock/2.4-2022-01/haddock2.4-2022-01
PROT_SEGID_2 B
PROT_SEGID_1 A
PDB_FILE1 ./sho1_alone.pdb
PDB_FILE2 ./AF_pbs2.pdb
PROJECT_DIR .
looking for existing files
There is a problem with the CNS executable defined in run.cns:

Note: The following floating-point exceptions are signalling: IEEE_DENORMAL

=> HADDOCK stopped
##############################################################################

So it seems there is a denormal numbers problem in the run.cns file even though I didn’t modify the file(because I just want to run haddock before changing any parameters). In the forums I consulted, most told that it was not a real issue and that it can be solved easily, but I am not an administrator of the server I use, so I can’t modify or update software on it (or maybe I just don’t know what I’m looking for). So I was wondering if there was an option to haddock2.4 to avoid this issue.
(I also modified the UseLongFileNames.py file to have useLongJobFileNames = 1)

Thank you!

This is a CNS executable problem

How was CNS compiled?

Can you start it manually, e.g. simply from the command line:

/project/chlandry/prg/haddock/2.4-2022-01/cns_solve_1.3/intel-x86_64bit-linux/bin/cns

Was it compiled with the code provided with haddock2.4 (check the cns1.3 directory in the haddock2.4 dir)

Thank you for the prompt answer!
The installation was done by the administrator of the server so I’m not sure how cns was compiled, but apparently I can’t run cns manually. The error I get is:

%SETFPEPS increase value of MXFPEPS2 and recompile
%SETFPEPS error encountered: Could not determine machine epsilon
(CNS is in mode: SET ABORT=NORMal END)
WARNING: program encountered a fatal error.
However, in interactive mode, program execution
will continue. Proceed at your own risk.
Program will stop immediately.
============================================================
Maximum dynamic memory allocation: 0 bytes
Maximum dynamic memory overhead: 0 bytes
Program started at: on
Program stopped at: 15:18:31 on 21-May-2022
CPU time used: 0.0180 seconds
============================================================
Note: The following floating-point exceptions are signalling: IEEE_DENORMAL

I just looked into this forum (CNS errors before/after recompilation - #23 by garima.tanwar) to try and solve the compilation of cns. I followed the instructions to compile cns again but I get the same error.

I have finally found the answer I was looking for a bit deeper in the forum,
thanks for the answer!

May-be post the solution here for others who might read this thread :slight_smile:

1 Like