Compiling on RHEL 7 with MKL

From NWChem

Viewed 1551 times, With a total of 21 Posts

Jump to: navigation, search

Forum >> NWChem's corner >> Compiling NWChem

Jump to page 12Next 16Last

Afeleut Member
Profile
Send PM

Clicked A Few Times

Threads 1
Posts 12

6:55:07 AM PST - Thu, Nov 17th 2016

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

Edoapra Forum:Admin, Forum:Mod, bureaucrat, sysop
Profile
Send PM

Forum Vet

Threads 7
Posts 1336

12:17:54 PM PST - Thu, Nov 17th 2016
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
Edited On 12:20:41 PM PST - Thu, Nov 17th 2016 by Edoapra

Afeleut Member
Profile
Send PM

Clicked A Few Times

Threads 1
Posts 12

9:41:03 AM PST - Fri, Nov 18th 2016

@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

Edited On 9:57:46 AM PST - Fri, Nov 18th 2016 by Afeleut

Edoapra Forum:Admin, Forum:Mod, bureaucrat, sysop
Profile
Send PM

Forum Vet

Threads 7
Posts 1336

10:52:22 AM PST - Fri, Nov 18th 2016
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 ...)

Afeleut Member
Profile
Send PM

Clicked A Few Times

Threads 1
Posts 12

11:36:38 AM PST - Fri, Nov 18th 2016
@Edoapra, I ran the script with the BLAS and SCALAPACK_SIZE options set and got the same errors as before

Edoapra Forum:Admin, Forum:Mod, bureaucrat, sysop
Profile
Send PM

Forum Vet

Threads 7
Posts 1336

12:00:22 PM PST - Fri, Nov 18th 2016
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

Afeleut Member
Profile
Send PM

Clicked A Few Times

Threads 1
Posts 12

8:47:59 AM PST - Tue, Nov 22nd 2016

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?

Edited On 9:02:13 AM PST - Tue, Nov 22nd 2016 by Afeleut

Afeleut Member
Profile
Send PM

Clicked A Few Times

Threads 1
Posts 12

8:48:13 AM PST - Tue, Nov 22nd 2016

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

Edited On 9:03:31 AM PST - Tue, Nov 22nd 2016 by Afeleut

Edoapra Forum:Admin, Forum:Mod, bureaucrat, sysop
Profile
Send PM

Forum Vet

Threads 7
Posts 1336

2:05:49 PM PST - Tue, Nov 22nd 2016
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

Afeleut Member
Profile
Send PM

Clicked A Few Times

Threads 1
Posts 12

8:37:50 AM PST - Thu, Nov 24th 2016
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

Afeleut Member
Profile
Send PM

Clicked A Few Times

Threads 1
Posts 12

8:52:41 AM PST - Wed, Nov 30th 2016
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...

Edoapra Forum:Admin, Forum:Mod, bureaucrat, sysop
Profile
Send PM

Forum Vet

Threads 7
Posts 1336

4:27:20 PM PST - Wed, Nov 30th 2016
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

Afeleut Member
Profile
Send PM

Clicked A Few Times

Threads 1
Posts 12

10:15:53 AM PST - Fri, Dec 2nd 2016
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

Edoapra Forum:Admin, Forum:Mod, bureaucrat, sysop
Profile
Send PM

Forum Vet

Threads 7
Posts 1336

10:56:28 AM PST - Fri, Dec 2nd 2016
I am at a loss to understand your last question ... Could you please send me the output of 1) mpiifort -V 2) ifort -V

Afeleut Member
Profile
Send PM

Clicked A Few Times

Threads 1
Posts 12

12:00:52 PM PST - Fri, Dec 2nd 2016
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
Edited On 12:31:25 PM PST - Fri, Dec 2nd 2016 by Afeleut

Edoapra Forum:Admin, Forum:Mod, bureaucrat, sysop
Profile
Send PM

Forum Vet

Threads 7
Posts 1336

1:42:24 PM PST - Fri, Dec 2nd 2016
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

Who's here now Members 0 Guests 1 Bots/Crawler 0

AWC's: 2.5.10 MediaWiki - Stand Alone Forum Extension
Forum theme style by: AWC

Search

Navigation

SEARCH

TOOLBOX

LANGUAGES

Forum Menu

Compiling on RHEL 7 with MKL

From NWChem

Toolbox