Just a short note concerning the recent openmp problem ...
There is a new one-api version published now which does not contain that
bug anymore (online repositories). Compilation runs fine without setting
that extra flag now.
Version 2024.2.0
DateJune 18, 2024
Best regards,
Mi
I have the same problem with the oneapi online repositories using zypper
(does not find the openmp libs). However, the offline installer using
the installation script still works fine:
basekit:
https://www.intel.com/content/www/us/en/developer/tools/oneapi/base-toolkit-download.html?operating
The SRC_plot error was already solved by Jan Doumont in a previous thread:
/Dear Peter,
/ /
Interestingly, I get the same error when using IFORT with the newest
oneapi...
/ /
ifort -O -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML -traceback
-assume buffered_io -I/opt/intel/oneapi/mkl/2024
ions.
Best regards,
Michael
Am 13.05.2024 um 10:00 schrieb Michael Fechtelkord via Wien:
Hello all,
as far as I can see it, a job with 8 cores may be faster, but uses
double of the space on scratch (8 partial nmr vectors with size
depending on the kmesh per direction eg. nmr_mqx instead o
cores for lapw1,
as each k-point has 2 cores.
On Mon, May 13, 2024 at 4:00 PM Michael Fechtelkord via Wien
wrote:
Hello all,
as far as I can see it, a job with 8 cores may be faster, but uses
double of the space on scratch (8 partial nmr vectors with size
depending on the
even with only 64 GB RAM and 1000k
points.
Best regards,
Michael
Am 12.05.2024 um 18:02 schrieb Michael Fechtelkord via Wien:
It shows EXECUTING: /usr/local/WIEN2k/nmr_mpi -case MS_2M1_Al2
-mode current -green -scratch /scratch/WIEN2k/ -noco
in all cases and in htop the
eigenvectors of all eigenvalues, ...
PPS: -quota 8 (or 24) might help and still utilizing all cores, but
I'm not sure if it would save enough memory in the current steps.
Am 12.05.2024 um 10:09 schrieb Michael Fechtelkord via Wien:
Hello all, hello Peter,
That is what is really runni
Michael Fechtelkord via Wien:
Hello Peter,
I just use "x_nmr_lapw -p" and the rest is initiated by the nmr
script. The Line "/usr/local/WIEN2k/nmr_mpi -case MS_2M1_Al2 -mode
current -green -scratch /scratch/WIEN2k/ -noco " is just part
of the whole procedure and
current should run only k-parallel, not in mpi ??
PS: The repetition of
nmr_integ:localhost is useless.
nmr mode integ runs only once (not k-parallel, sumpara has already
summed up the currents)
But one can use nmr_integ:localhost:8
Best regards
Am 11.05.2024 um 16:19 schrieb Michael Fec
Fechtelkord via Wien:
Dear all,
the following problem occurs to me using the NMR part of WIEN2k
(23.2) on a opensuse LEAP 15.5 Intel platform. WIEN2k was compiled
using one-api 2024.1 ifort and gcc 13.2.1. I am using ELPA
2024.03.01, Libxc 6.22, fftw 3.3.10 and MPICH 4.2.1 and the one-api
2024.1
Dear all,
the following problem occurs to me using the NMR part of WIEN2k (23.2)
on a opensuse LEAP 15.5 Intel platform. WIEN2k was compiled using
one-api 2024.1 ifort and gcc 13.2.1. I am using ELPA 2024.03.01, Libxc
6.22, fftw 3.3.10 and MPICH 4.2.1 and the one-api 2024.1 MKL libraries.
Th
Fechtelkord via Wien:
Dear All,
I have a short question concerning the NMR Chemical Shift
calculations. I am calculating Chemical Shifts on Lepidolites, e.g.
Trilithionite which is K(Li1.5Al1.5)[Si3AlO10]F2 . To reduce the
calculation time and reduce the number of NMR-LOs I am asking myself
if
Hello all,
I tried also to use ifx .. it works for elpa, mpich, fftw and libxc, but
the compilation of WIEN2k has too many errors. With the classic compiler
ifort the compilation works fine and also the workaround for SRC_wplot
does resolve the compilation error.
Elpa recommends flags for c
Dear All,
I have a short question concerning the NMR Chemical Shift calculations.
I am calculating Chemical Shifts on Lepidolites, e.g. Trilithionite
which is K(Li1.5Al1.5)[Si3AlO10]F2 . To reduce the calculation time and
reduce the number of NMR-LOs I am asking myself if it is possible to
f
Dear colleagues,
I just compiled WIEN2K with the newest Intel one-api Version 2024.0 and
got the following compiler error for modules.f in SRC_wplot:
ifort -O -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML -traceback
-assume buffered_io -I/opt/intel/oneapi/mkl/2024.0/include
-DHAVE_PTR_
Dear Prof. Blaha,
I recompiled lapw1 with LOMAX = 4 but then the scf cycle fails. The real
problem was the used cut off energy of -11 Ry in init_lapw. That
introduces also too much orbitals in x_nmr -mode in1 and a qtl-b errors
in the first two loops. After using the default value of -6 Ry fo
Dear Prof. Blaha,
thanks for the fast reply. I will try that later. Currently calculations
are running. I wanted to calculate the 19F chemical shift for TlF3 just
as a model compound for experimental / computational shift correlations.
So it is not that important for my work.
Thanks again
with the case.in1 file or something with
your lapw1 version.
Regards
Am 12.11.2023 um 12:36 schrieb Michael Fechtelkord via Wien:
Hello Prof. Blaha,
thanks for the reply .. I did run x_nmr -mode in1. I checked the
case.in1_nmr file and did not find anything suspicious.
I can send the fi
Hello Prof. Blaha,
thanks for the reply .. I did run x_nmr -mode in1. I checked the
case.in1_nmr file and did not find anything suspicious.
I can send the file by direct e-mail if you like. I do not want to make
the messages for the mailing list unnecessary long.
Best regards,
Michael Fe
Hello all,
I got a Fortran error during the lapw 1 / lapw2 subroutines in the
x_nmr_lapw script. The structures are simple (two atoms, most cubic
Fm-3m) but contain heavy metal atoms like Hg or Tl. I am interested in
the theoretical 19F Chemical shift to compare to the experimental.
The scf
20 matches
Mail list logo
