Compiling on RHEL 7 with MKL


Jump to page 12Next 16Last
Clicked A Few Times
Hi folks,
I am compiling NWChem 6.6 on a RHEL 7 cluster. I was able to build it successfully with internal BLAS but the performance was an issue. I am trying to solve that by compiling with MKL libraries.
I'm running this script:
cd nwchem-6.6/src
make clean
make 64_to_32
export NWCHEM_TOP=/pathto/nwchem-6.6
export USE_MPI=y
export CC=mpiicc
export FC=mpiifort
export CXX=mpiicpc
export NWCHEM_TARGET=LINUX64
export USE_PYTHONCONFIG=y
export PYTHONVERSION=2.7
export PYTHONHOME=/pathto/python/2.7.7/
export BLASOPT="-L/pathto/intel/composer_xe_2015.1.133/mkl/lib/intel64/ -lmkl_intel_ilp64 -lmkl_core -lmkl_sequential -lpthread -lm"
export USE_SCALAPACK=y
export SCALAPACK="-L/pathto/intel/composer_xe_2015.1.133/mkl/lib/intel64/ -lmkl_scalapack_ilp64 -lmkl_intel_ilp64 -lmkl_core -lmkl_sequential -lmkl_blacs_intelmpi_ilp64 -lpthread -lm"
make nwchem_config NWCHEM_MODULES="all python"
make


I get the following output error on the command line:
configure: error: f2c string convention is neither after args nor after string


On config.log there are several other errors that have to do with file conftest.c You can find the config.log file here [1]
I'm using intel compilers and intel MPI. Any ideas will be much appreciated

Forum Vet
Not sure why gfortran fails to link as shown in your config.log. You might have some env. variables causing problems in the link phase.
To better investigate the problem, please execute the following script and post the full log
cat > /tmp/ff.f  <<EOF
       program main
       character(LEN=10) :: first_name
       character(LEN=15) :: last_name
       first_name = "John"
       last_name = "Doe"
       call sub(first_name, last_name)
       end
EOF
gfortran -Wl,--verbose /tmp/ff.f -o ff.x
rm -f /tmp/ff.f /tmp/ff.x


By the way, you are missing two env. variables in your settings

BLAS_SIZE=8
SCALAPACK_SIZE=8

Clicked A Few Times
@Edoapra, thank you for your help.

I loaded mkl and impi before running the script (although it seems to me it was unnecessary). It looks like the issue is with libgcc.so, I checked on my PATH and I only have libgcc.a or libgcc_s.so
Here's the full output:
GNU ld version 2.23.52.0.1-55.el7 20130226
  Supported emulations:
   elf_x86_64
   elf32_x86_64
   elf_i386
   i386linux
   elf_l1om
   elf_k1om
using internal linker script:
==================================================
/* Script for -z combreloc: combine and sort reloc sections */
OUTPUT_FORMAT("elf64-x86-64", "elf64-x86-64",
              "elf64-x86-64")
OUTPUT_ARCH(i386:x86-64)
ENTRY(_start)
SEARCH_DIR("/usr/x86_64-redhat-linux/lib64"); SEARCH_DIR("/usr/local/lib64"); SEARCH_DIR("/lib64"); SEARCH_DIR("/usr/lib64"); SEARCH_DIR("/usr/x86_64-redhat-linux/lib"); SEARCH_DIR("/usr/lib64"); SEARCH_DIR("/usr/local/lib"); SEARCH_DIR("/lib"); SEARCH_DIR("/usr/lib");
SECTIONS
{
  /* Read-only sections, merged into text segment: */
  PROVIDE (__executable_start = SEGMENT_START("text-segment", 0x400000)); . = SEGMENT_START("text-segment", 0x400000) + SIZEOF_HEADERS;
  .interp         : { *(.interp) }
  .note.gnu.build-id : { *(.note.gnu.build-id) }
  .hash           : { *(.hash) }
  .gnu.hash       : { *(.gnu.hash) }
  .dynsym         : { *(.dynsym) }
  .dynstr         : { *(.dynstr) }
  .gnu.version    : { *(.gnu.version) }
  .gnu.version_d  : { *(.gnu.version_d) }
  .gnu.version_r  : { *(.gnu.version_r) }
  .rela.dyn       :
    {
      *(.rela.init)
      *(.rela.text .rela.text.* .rela.gnu.linkonce.t.*)
      *(.rela.fini)
      *(.rela.rodata .rela.rodata.* .rela.gnu.linkonce.r.*)
      *(.rela.data .rela.data.* .rela.gnu.linkonce.d.*)
      *(.rela.tdata .rela.tdata.* .rela.gnu.linkonce.td.*)
      *(.rela.tbss .rela.tbss.* .rela.gnu.linkonce.tb.*)
      *(.rela.ctors)
      *(.rela.dtors)
      *(.rela.got)
      *(.rela.sharable_data .rela.sharable_data.* .rela.gnu.linkonce.shrd.*)
      *(.rela.sharable_bss .rela.sharable_bss.* .rela.gnu.linkonce.shrb.*)
      *(.rela.bss .rela.bss.* .rela.gnu.linkonce.b.*)
      *(.rela.ldata .rela.ldata.* .rela.gnu.linkonce.l.*)
      *(.rela.lbss .rela.lbss.* .rela.gnu.linkonce.lb.*)
      *(.rela.lrodata .rela.lrodata.* .rela.gnu.linkonce.lr.*)
      *(.rela.ifunc)
    }
  .rela.plt       :
    {
      *(.rela.plt)
      PROVIDE_HIDDEN (__rela_iplt_start = .);
      *(.rela.iplt)
      PROVIDE_HIDDEN (__rela_iplt_end = .);
    }
  .init           :
  {
    KEEP (*(SORT_NONE(.init)))
  }
  .plt            : { *(.plt) *(.iplt) }
  .text           :
  {
    *(.text.unlikely .text.*_unlikely)
    *(.text.exit .text.exit.*)
    *(.text.startup .text.startup.*)
    *(.text.hot .text.hot.*)
    *(.text .stub .text.* .gnu.linkonce.t.*)
    /* .gnu.warning sections are handled specially by elf32.em.  */
    *(.gnu.warning)
  }
  .fini           :
  {
    KEEP (*(SORT_NONE(.fini)))
  }
  PROVIDE (__etext = .);
  PROVIDE (_etext = .);
  PROVIDE (etext = .);
  .rodata         : { *(.rodata .rodata.* .gnu.linkonce.r.*) }
  .rodata1        : { *(.rodata1) }
  .eh_frame_hdr : { *(.eh_frame_hdr) }
  .eh_frame       : ONLY_IF_RO { KEEP (*(.eh_frame)) }
  .gcc_except_table   : ONLY_IF_RO { *(.gcc_except_table
  .gcc_except_table.*) }
  /* These sections are generated by the Sun/Oracle C++ compiler.  */
  .exception_ranges   : ONLY_IF_RO { *(.exception_ranges
  .exception_ranges*) }
  /* Adjust the address for the data segment.  We want to adjust up to
     the same address within the page on the next page up.  */
  . = ALIGN (CONSTANT (MAXPAGESIZE)) - ((CONSTANT (MAXPAGESIZE) - .) & (CONSTANT (MAXPAGESIZE) - 1)); . = DATA_SEGMENT_ALIGN (CONSTANT (MAXPAGESIZE), CONSTANT (COMMONPAGESIZE));
  /* Exception handling  */
  .eh_frame       : ONLY_IF_RW { KEEP (*(.eh_frame)) }
  .gcc_except_table   : ONLY_IF_RW { *(.gcc_except_table .gcc_except_table.*) }
  .exception_ranges   : ONLY_IF_RW { *(.exception_ranges .exception_ranges*) }
  /* Thread Local Storage sections  */
  .tdata          : { *(.tdata .tdata.* .gnu.linkonce.td.*) }
  .tbss           : { *(.tbss .tbss.* .gnu.linkonce.tb.*) *(.tcommon) }
  .preinit_array     :
  {
    PROVIDE_HIDDEN (__preinit_array_start = .);
    KEEP (*(.preinit_array))
    PROVIDE_HIDDEN (__preinit_array_end = .);
  }
  .init_array     :
  {
    PROVIDE_HIDDEN (__init_array_start = .);
    KEEP (*(SORT_BY_INIT_PRIORITY(.init_array.*) SORT_BY_INIT_PRIORITY(.ctors.*)))
    KEEP (*(.init_array EXCLUDE_FILE (*crtbegin.o *crtbegin?.o *crtend.o *crtend?.o ) .ctors))
    PROVIDE_HIDDEN (__init_array_end = .);
  }
  .fini_array     :
  {
    PROVIDE_HIDDEN (__fini_array_start = .);
    KEEP (*(SORT_BY_INIT_PRIORITY(.fini_array.*) SORT_BY_INIT_PRIORITY(.dtors.*)))
    KEEP (*(.fini_array EXCLUDE_FILE (*crtbegin.o *crtbegin?.o *crtend.o *crtend?.o ) .dtors))
    PROVIDE_HIDDEN (__fini_array_end = .);
  }
  .ctors          :
  {
    /* gcc uses crtbegin.o to find the start of
       the constructors, so we make sure it is
       first.  Because this is a wildcard, it
       doesn't matter if the user does not
       actually link against crtbegin.o; the
       linker won't look for a file to match a
       wildcard.  The wildcard also means that it
       doesn't matter which directory crtbegin.o
       is in.  */
    KEEP (*crtbegin.o(.ctors))
    KEEP (*crtbegin?.o(.ctors))
    /* We don't want to include the .ctor section from
       the crtend.o file until after the sorted ctors.
       The .ctor section from the crtend file contains the
       end of ctors marker and it must be last */
    KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .ctors))
    KEEP (*(SORT(.ctors.*)))
    KEEP (*(.ctors))
  }
  .dtors          :
  {
    KEEP (*crtbegin.o(.dtors))
    KEEP (*crtbegin?.o(.dtors))
    KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .dtors))
    KEEP (*(SORT(.dtors.*)))
    KEEP (*(.dtors))
  }
  .jcr            : { KEEP (*(.jcr)) }
  .data.rel.ro : { *(.data.rel.ro.local* .gnu.linkonce.d.rel.ro.local.*) *(.data.rel.ro .data.rel.ro.* .gnu.linkonce.d.rel.ro.*) }
  .dynamic        : { *(.dynamic) }
  .got            : { *(.got) *(.igot) }
  . = DATA_SEGMENT_RELRO_END (SIZEOF (.got.plt) >= 24 ? 24 : 0, .);
  .got.plt        : { *(.got.plt)  *(.igot.plt) }
  .data           :
  {
    *(.data .data.* .gnu.linkonce.d.*)
    SORT(CONSTRUCTORS)
  }
  .data1          : { *(.data1) }
  /* Sharable data sections.  */
  .sharable_data   : ALIGN(CONSTANT (MAXPAGESIZE))
  {
    PROVIDE_HIDDEN (__sharable_data_start = .);
    *(.sharable_data .sharable_data.* .gnu.linkonce.shrd.*)
    /* Align here to ensure that the sharable data section ends at the
       page boundary.  */
    . = ALIGN(. != 0 ? CONSTANT (MAXPAGESIZE) : 1);
    PROVIDE_HIDDEN (__sharable_data_end = .);
  }
  _edata = .; PROVIDE (edata = .);
  . = .;
  __bss_start = .;
  .bss            :
  {
   *(.dynbss)
   *(.bss .bss.* .gnu.linkonce.b.*)
   *(COMMON)
   /* Align here to ensure that the .bss section occupies space up to
      _end.  Align after .bss to ensure correct alignment even if the
      .bss section disappears because there are no input sections.
      FIXME: Why do we need it? When there is no .bss section, we don't
      pad the .data section.  */
   . = ALIGN(. != 0 ? 64 / 8 : 1);
  }
  /* Sharable bss sections  */
  .sharable_bss   : ALIGN(CONSTANT (MAXPAGESIZE))
  {
    PROVIDE_HIDDEN (__sharable_bss_start = .);
    *(.dynsharablebss)
    *(.sharable_bss .sharable_bss.* .gnu.linkonce.shrb.*)
    *(SHARABLE_COMMON)
    /* Align here to ensure that the sharable bss section ends at the
       page boundary.  */
    . = ALIGN(. != 0 ? CONSTANT (MAXPAGESIZE) : 1);
    PROVIDE_HIDDEN (__sharable_bss_end = .);
  }
  .lbss   :
  {
    *(.dynlbss)
    *(.lbss .lbss.* .gnu.linkonce.lb.*)
    *(LARGE_COMMON)
  }
  . = ALIGN(64 / 8);
  . = SEGMENT_START("ldata-segment", .);
  .lrodata   ALIGN(CONSTANT (MAXPAGESIZE)) + (. & (CONSTANT (MAXPAGESIZE) - 1)) :
  {
    *(.lrodata .lrodata.* .gnu.linkonce.lr.*)
  }
  .ldata   ALIGN(CONSTANT (MAXPAGESIZE)) + (. & (CONSTANT (MAXPAGESIZE) - 1)) :
  {
    *(.ldata .ldata.* .gnu.linkonce.l.*)
    . = ALIGN(. != 0 ? 64 / 8 : 1);
  }
  . = ALIGN(64 / 8);
  _end = .; PROVIDE (end = .);
  . = DATA_SEGMENT_END (.);
  /* Stabs debugging sections.  */
  .stab          0 : { *(.stab) }
  .stabstr       0 : { *(.stabstr) }
  .stab.excl     0 : { *(.stab.excl) }
  .stab.exclstr  0 : { *(.stab.exclstr) }
  .stab.index    0 : { *(.stab.index) }
  .stab.indexstr 0 : { *(.stab.indexstr) }
  .comment       0 : { *(.comment) }
  /* DWARF debug sections.
     Symbols in the DWARF debugging sections are relative to the beginning
     of the section so we begin them at 0.  */
  /* DWARF 1 */
  .debug          0 : { *(.debug) }
  .line           0 : { *(.line) }
  /* GNU DWARF 1 extensions */
  .debug_srcinfo  0 : { *(.debug_srcinfo) }
  .debug_sfnames  0 : { *(.debug_sfnames) }
  /* DWARF 1.1 and DWARF 2 */
  .debug_aranges  0 : { *(.debug_aranges) }
  .debug_pubnames 0 : { *(.debug_pubnames) }
  /* DWARF 2 */
  .debug_info     0 : { *(.debug_info .gnu.linkonce.wi.*) }
  .debug_abbrev   0 : { *(.debug_abbrev) }
  .debug_line     0 : { *(.debug_line) }
  .debug_frame    0 : { *(.debug_frame) }
  .debug_str      0 : { *(.debug_str) }
  .debug_loc      0 : { *(.debug_loc) }
  .debug_macinfo  0 : { *(.debug_macinfo) }
  /* SGI/MIPS DWARF 2 extensions */
  .debug_weaknames 0 : { *(.debug_weaknames) }
  .debug_funcnames 0 : { *(.debug_funcnames) }
  .debug_typenames 0 : { *(.debug_typenames) }
  .debug_varnames  0 : { *(.debug_varnames) }
  /* DWARF 3 */
  .debug_pubtypes 0 : { *(.debug_pubtypes) }
  .debug_ranges   0 : { *(.debug_ranges) }
  /* DWARF Extension.  */
  .debug_macro    0 : { *(.debug_macro) }
  .gnu.attributes 0 : { KEEP (*(.gnu.attributes)) }
  /DISCARD/ : { *(.note.GNU-stack) *(.gnu_debuglink) *(.gnu.lto_*) *(.gnu_object_only) }
}


==================================================
attempt to open /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/crt1.o succeeded
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/crt1.o
attempt to open /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/crti.o succeeded
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/crti.o
attempt to open /usr/lib/gcc/x86_64-redhat-linux/4.8.5/crtbegin.o succeeded
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/crtbegin.o
attempt to open /tmp/ccFhsDpu.o succeeded
/tmp/ccFhsDpu.o
attempt to open /usr/lib/gcc/x86_64-redhat-linux/4.8.5/libgfortran.so succeeded
-lgfortran (/usr/lib/gcc/x86_64-redhat-linux/4.8.5/libgfortran.so)
attempt to open /usr/lib/gcc/x86_64-redhat-linux/4.8.5/libm.so failed
attempt to open /usr/lib/gcc/x86_64-redhat-linux/4.8.5/libm.a failed
attempt to open /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libm.so succeeded
-lm (/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libm.so)
attempt to open /usr/lib/gcc/x86_64-redhat-linux/4.8.5/libgcc_s.so succeeded
-lgcc_s (/usr/lib/gcc/x86_64-redhat-linux/4.8.5/libgcc_s.so)
attempt to open /usr/lib/gcc/x86_64-redhat-linux/4.8.5/libgcc.so failed
attempt to open /usr/lib/gcc/x86_64-redhat-linux/4.8.5/libgcc.a succeeded
attempt to open /usr/lib/gcc/x86_64-redhat-linux/4.8.5/libquadmath.so succeeded
opened script file /usr/lib/gcc/x86_64-redhat-linux/4.8.5/libquadmath.so
opened script file /usr/lib/gcc/x86_64-redhat-linux/4.8.5/libquadmath.so
attempt to open /usr/lib64/libquadmath.so.0.0.0 succeeded
/usr/lib64/libquadmath.so.0.0.0
attempt to open /usr/lib/gcc/x86_64-redhat-linux/4.8.5/libm.so failed
attempt to open /usr/lib/gcc/x86_64-redhat-linux/4.8.5/libm.a failed
attempt to open /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libm.so succeeded
-lm (/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libm.so)
attempt to open /usr/lib/gcc/x86_64-redhat-linux/4.8.5/libgcc_s.so succeeded
-lgcc_s (/usr/lib/gcc/x86_64-redhat-linux/4.8.5/libgcc_s.so)
attempt to open /usr/lib/gcc/x86_64-redhat-linux/4.8.5/libgcc.so failed
attempt to open /usr/lib/gcc/x86_64-redhat-linux/4.8.5/libgcc.a succeeded
attempt to open /usr/lib/gcc/x86_64-redhat-linux/4.8.5/libc.so failed
attempt to open /usr/lib/gcc/x86_64-redhat-linux/4.8.5/libc.a failed
attempt to open /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libc.so succeeded
opened script file /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libc.so
opened script file /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libc.so
attempt to open /lib64/libc.so.6 succeeded
/lib64/libc.so.6
attempt to open /usr/lib64/libc_nonshared.a succeeded
(/usr/lib64/libc_nonshared.a)elf-init.oS
attempt to open /lib64/ld-linux-x86-64.so.2 succeeded
/lib64/ld-linux-x86-64.so.2
attempt to open /usr/lib/gcc/x86_64-redhat-linux/4.8.5/libgcc_s.so succeeded
-lgcc_s (/usr/lib/gcc/x86_64-redhat-linux/4.8.5/libgcc_s.so)
attempt to open /usr/lib/gcc/x86_64-redhat-linux/4.8.5/libgcc.so failed
attempt to open /usr/lib/gcc/x86_64-redhat-linux/4.8.5/libgcc.a succeeded
attempt to open /usr/lib/gcc/x86_64-redhat-linux/4.8.5/crtend.o succeeded
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/crtend.o
attempt to open /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/crtn.o succeeded
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/crtn.o
ld-linux-x86-64.so.2 needed by /lib64/libc.so.6
found ld-linux-x86-64.so.2 at /lib64/ld-linux-x86-64.so.2
/tmp/ccFhsDpu.o: In function `MAIN__':
ff.f:(.text+0x6b): undefined reference to `sub_'
collect2: error: ld returned 1 exit status 

Forum Vet
This output from the script looks fine. It is not reporting the same error that appeared on config.log.
Whatever happened, you should be able to compile NWChem now (if the conditions remain the same ...)

Clicked A Few Times
@Edoapra, I ran the script with the BLAS and SCALAPACK_SIZE options set and got the same errors as before

Forum Vet
Not sure what's happening, but I would advise you to keep it simple and close to what I normally use
I would do the following

unset CXX
unset CC
export FC=ifort

Clicked A Few Times
I was able to build NWChem with the following script:
cd nwchem-6.6/src
export NWCHEM_TOP=/pathto/nwchem-6.6
export USE_64TO32=y
export USE_MPI=y
export FC=mpiifort
export BLAS_SIZE=8
export SCALAPACK_SIZE=8
export NWCHEM_TARGET=LINUX64
export USE_PYTHONCONFIG=y
export PYTHONVERSION=2.7
export PYTHONHOME=/pathto/python/2.7.7/
export BLASOPT="-L/pathto/mkl/lib/intel64/ -lmkl_intel_ilp64 -lmkl_core -lmkl_sequential -lpthread -lm"
export USE_SCALAPACK=y
export SCALAPACK="-L/pathto/mkl/lib/intel64/ -lmkl_scalapack_ilp64 -lmkl_intel_ilp64 -lmkl_core -lmkl_sequential -lmkl_blacs_intelmpi_ilp64 -lpthread -lm"
make nwchem_config NWCHEM_MODULES="all python"
make clean
make 64_to_32
make FC=mpiifort CC=mpiicc


But when running an example that I know works, I get the following error:
MA fatal error: MA_sizeof: invalid datatype: 128849019889


From what I read on other threads, it's as if I haven't used 64to32. How can I check that step of the compilation was successful? Or is there another reason for the error?

Clicked A Few Times
I was able to build NWChem with the following script:
cd nwchem-6.6/src
export NWCHEM_TOP=/pathto/nwchem-6.6
export USE_64TO32=y
export USE_MPI=y
export FC=mpiifort
export BLAS_SIZE=8
export SCALAPACK_SIZE=8
export NWCHEM_TARGET=LINUX64
export USE_PYTHONCONFIG=y
export PYTHONVERSION=2.7
export PYTHONHOME=/pathto/python/2.7.7/
export BLASOPT="-L/pathto/mkl/lib/intel64/ -lmkl_intel_ilp64 -lmkl_core -lmkl_sequential -lpthread -lm"
export USE_SCALAPACK=y
export SCALAPACK="-L/pathto/mkl/lib/intel64/ -lmkl_scalapack_ilp64 -lmkl_intel_ilp64 -lmkl_core -lmkl_sequential -lmkl_blacs_intelmpi_ilp64 -lpthread -lm"
make nwchem_config NWCHEM_MODULES="all python"
make clean
make 64_to_32
make FC=mpiifort CC=mpiicc


But when running an example that I know works, I get the following error:
MA fatal error: MA_sizeof: invalid datatype: 128849019889


From what I read on other threads, it's as if I haven't used 64to32. How can I check that step of the compilation was successful? Or is there another reason for the error (maybe it should be BLAS_SIZE=4)? Should I still run
make 64_to32

Thank you

Forum Vet
Quote:Afeleut Nov 22nd 7:48 am


But when running an example that I know works, I get the following error:
MA fatal error: MA_sizeof: invalid datatype: 128849019889


From what I read on other threads, it's as if I haven't used 64to32. How can I check that step of the compilation was successful? Or is there another reason for the error (maybe it should be BLAS_SIZE=4)? Should I still run
make 64_to32

Thank you

No, this is more likely to be originated by an incorrect compilation of the tools directory.
I would suggest you the following steps

1) unset FC ; unset CC
2) cd $NWCHEM_TOP/src/tools
3) rm -rf build install
4) make FC=ifort >& make.log
5) cd ..
6) make FC=ifort link

If this gives you the same error as before, please post
1) tools/build/config.log
2) tools/make.log

Clicked A Few Times
Edoapra, followed the steps you mentioned and got the same error.
You can find config.log and make.log on the following folder

https://drive.google.com/open?id=0BxRTbU02E_g-RUtHSGdXbmJDeWc

Thank you

Clicked A Few Times
I also got the same error when compiling with ATLAS instead of MKL, which leads me to believe the issue isn't with the Optimized BLAS libs. I have recompiled the tools directory with ifort and still no luck...

Forum Vet
I believe the problem is in the other directories (other than tools) .. sorry for misleading you!
Since FC=mpifort is not recognized correctly by the NWChem makefile structure, the rest of the code was compiled incorrectly.
Please do a make clean, and the make FC=ifort

Clicked A Few Times
Hi Edoapra,
recompiling the src directory with make FC=ifort worked with both ATLAS and MKL. Thank you.
The performance was much less than desirable though, do you have any ideas of how I could try to improve that since I can't compile with mpiifort?
Thank you

Forum Vet
I am at a loss to understand your last question ... Could you please send me the output of
1) mpiifort -V
2) ifort -V

Clicked A Few Times
1) $ mpiifort -V
Intel(R) Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 15.0.1.133 Build 20141023
Copyright (C) 1985-2014 Intel Corporation. All rights reserved.

2)$ ifort -V
Intel(R) Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 15.0.1.133 Build 20141023
Copyright (C) 1985-2014 Intel Corporation. All rights reserved.

I also tried with OpenMPI and no luck

Forum Vet
I don't see any difference on the compilers between mpiifort and ifort ... do you?


Forum >> NWChem's corner >> Compiling NWChem
Jump to page 12Next 16Last