Yu,
In addition to the usersguide [1] describing use of "run_lapw -p" along
with an appropriately set up .machines file, don't forget about the
WIEN2k-notes of the University of Texas [2], the workshop video on
Parallelization [3], and mailing list archive for previous posts on the
topic of
Probably you need to mention how you handled the core leakage issue
during initialization (init_lapw) of WIEN2k 19.2 since if that was not
addressed it might lead to the QTL error later during the scf:
username@computername:~/wiendata/Li2NiPO4F_check$ ls
Li2NiPO4F_check.struct
lowing message in w2web page.
Commandline: : grep WARNING *.outputst
Program input is: ""
Execute another command line:
Type of execution:
Also, in case.outputst there is no warning message displayed.
with regards,
On Sun, 12 Jul 2020 at 21:30, Gav
ALTERNATIVELY: specify charge localization (between 0.97 and 1.0) to
select core state
STOP LSTART ENDS
1.4u 0.0s 0:01.45 100.0% 0+0k 0+11872io 0pf+0w
& during 1st iteration, it is showing the ghost band error
with regards,
On Sun, 12 Jul 2020 at 19:49, Gavin Abo <mailto:gs...@crimson.ua.
mend I set DISPLAY?
Thank you
*From:* Wien on behalf of
Gavin Abo
*Sent:* Saturday, June 13, 2020 4:55 PM
*To:* wien@zeus.theochem.tuwien.ac.at
*Subject:* Re: [Wien] Xcrysden issues with w2web
Maybe there is still a problem
The WIEN2k 19.1 usersguide [1] on page 67 under section 5.1.4 has:
-dm -> calculate the density matrix (when -so is set, but -orb
is not)
That seems to indicate that the -dm needs -so to work (e.g., runsp_lapw
-dm -so). If you use "runsp_lapw -dm -orb", the program will probably
I'm not sure that I have the proper answers but given below is what I'm
currently thinking they might be.
I am trying to extract irreducible representation of eigenvalues. I
have obtained the case.outputirso and case.irrepso files. But I am not
sure if I understood these files correctly. The Ci
not able to model AFM order. what to do?
Looking forward to hearing from you.
with regards,
On Wed, 24 Jun 2020 at 08:01, Gavin Abo <mailto:gs...@crimson.ua.edu>> wrote:
If a struct file fails during initialization (init_lapw), it is
very likely that it will fail and not wo
--?0?2?0?2--
*??:*?0?2"Gavin Abo";
*:*?0?22020??6??8??(??) 8:18
*??:*?0?2"wien";
*:*?0?2Re: [Wien] Wien Installation
In terms of OpenBLAS-0.3.9 libraries, in my OpenBLAS-0.3.9/lib, there
are several files as the below: libopen
In addition to the comments by the others, you might also check for the
monoclinic if using beta as not equal 90 (where you have beta=90.881
below) for optimization is okay or not by referring the following link:
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg12124.html
On
Below it looks like the compiler shows you exactly what is wrong:
/usr/bin/ld: cannot find -llibscalapack.a
Most likely either the
SCALAPACK_LIBNAME: libscalapack.a
needs changed to use the dynamic scalapack library
SCALAPACK_LIBNAME: scalapack
to have -lscalapack or you might have to try
nner, as I am running on Ubuntu. Is
there a place where I need to set DISPLAY?
*From:* Wien on behalf of
Gavin Abo
*Sent:* Saturday, June 6, 2020 11:05 AM
*To:* wien@zeus.theochem.tuwien.ac.at
*Subject:* Re: [Wien] Xcrys
tpars.F of SRC_lapw0.
*From:* Wien on behalf of
Gavin Abo
*Sent:* Saturday, June 13, 2020 11:02 PM
*To:* wien@zeus.theochem.tuwien.ac.at
*Subject:* [Wien] libxc 5.0.0
The libxc website [1] has a new version 5.0.0, bu
If a struct file fails during initialization (init_lapw), it is very
likely that it will fail and not work during the scf. Your failed error
during the scf seems to be proof of that as during init_lapw your struct
file seems to fail right away during the nn step with errors "Mult not
equal.
Are the lattice constants okay?
The webpage https://materialsproject.org/materials/mp-352/ has:
a = 5.142 Å, b = 5.195 Å, c = 5.326 Å (or a = 9.716976 bohr, b =
9.817131 bohr, c = 10.064685 bohr)
In your struct file below, I see:
a = 0.523454 bohr, b = 0.648176 bohr, c = 0.633059 bohr
Most likely you just need to kill and restart w2web.
Refer to:
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg11246.html
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg01987.html
On 6/6/2020 11:49 AM, Johnathon Street wrote:
I unable to view crystal with
BoltzTraP2 is a separate program and it reads in files (*.scf, *.struct,
*.energy*) from WIEN2k 19.2. Thus, you do not need to add it to WIEN2k.
If you are using one of the latest Linux distributions that ships with
Python 3, it is usually installed as given on the BoltzTraP2 website [1]
In terms of OpenBLAS-0.3.9 libraries, in my OpenBLAS-0.3.9/lib, there
are several files as the below: libopenblas_nehalemp-r0.3.9.a,
libopenblas_nehalemp-r0.3.9.so, libopenblas.so, libopenblas.so.0,
libopenblas.a. Are they as same as yours?
I have the following, but you have the same one named
By volume on the w2web page, are you referring to the estimated actual
optimized volume (or lattice constants) given by the Equation of State
fit(s) such as by Birch-Murnaghan seen in the post at [1]? As you have
probably read in the post [2] or noticed, the case.struct files from "x
optimize"
Prof. Blaha,
When you have a chance, can you please fix the WIEN2k_19.2.tar in the
download area of the website? It seems that some change happened
recently to it because the SRC_lapw1.tar.gz that used to be there when
it was extracted from the downloaded file in the past is not there when
The libxc website [1] has a new version 5.0.0, but it doesn't compile
with WIEN2k (version 19.2). I have linked in libxc 4.3.4 from [2]
instead. Does anyone have a patch for using the version 5.0.0?
[1] https://www.tddft.org/programs/libxc/download/
[2]
1. In a terminal, change into your WIEN2k directory: cd $WIENROOT
2. Run: ./siteconfig
3. Select Compiling Options: O
4. Check your R_LIBS line
Your SRC_aim-compile.msg looks like it probably used:
/usr/lib64/libpthread.so
What works for me for R_LIBS is: -L/home/username/OpenBLAS-0.3.9
The write_inwf_lapw script was buggy in versions, such as WIEN2k 17.1
[1], that came before WIEN2k 19.1 as shown on the WIEN2k updates page
[2] by:
*VERSION_19.1: 17.6.2019*
*write_inwf_lapw**:* update for spinpolarization
It is recommended to use WIEN2k 19.2. You may also want to apply the
If your case.struct file has one Mn atom corresponding to one
inequivalent atomic position that has multiple equivalent atomic
positions where you want to split the equivalent atomic positions into
inequivalent ones, then you need to use the "set at least for one
atom-name a special label" at
View case.struct of the supercell in StructGen of w2web. If the
supercell has a space group, it will show what it is. If it has no
space group, it should instead have a general lattice highlighted such
as "P".
The WIEN2k 19.1 usersguide [1] states on page 110 under section "6.2
SGROUP":
Also, if you prefer to use Python, you can make a wrapper around WIEN2k
terminal commands. For example, "init_lapw -b" could be used in an
init_lapw.py file as shown in [1] by referencing [2].
[1] Temporary link:
You might want to have a look at Spaghetti-prima.py and JPlot on the
WIEN2k unsupported webpage:
http://susi.theochem.tuwien.ac.at/reg_user/unsupported/
Python based BoltzTraP2 plots bandstructure from WIEN2k:
https://gitlab.com/sousaw/BoltzTraP2/-/wikis/tutorial
BoltzTraP2 can be used as a
Let's assume there are two sheets of graphene: sheet 1 and sheet 2. If
sheet 1 is place at a fixed position but sheet 2 is placed directly
above it in the z direction and then rotated around the z axis with an
angle Theta. Perhaps this is one definition of a twisted angle (Theta).
In other
From looking at the post at
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg20597.html
it looks like the steps are:
run_lapw
x qtl -telnes (or x lapw2 -qtl)
x telnes3
According to section "8.24.3 Practical considerations" in the WIEN2k
19.1/19.2 usersguide on page 201 [
If you have a look at [1], it can be seen that different cluster systems
have different commands for job submission.
I did not see it clearly shown in your post how the job was submitted,
for example did you maybe use something similar to that at [2]:
$ sbatch MyJobScript.sh
*What command
I'm not sure about the physics of the following WIEN2k 19.2 parallel
calculation (with all patches at [1] applied), but mechanically the "x
qtl -p -telnes" seems to have run without error.
I typically have SCRATCH in my .bashrc set to "./" but used another
location
If you can provide additional information, maybe someone can be of
further assistance.
For example ...
Is this happening with WIEN2k 19.2, as one of the items in the
"Nettiquette" list for the mailing list at [1] is "I am running wien
version xxx"?
[1]
If your using WIEN2k_19.2, then only follow [3] (do not follow [1]).
Maybe you are not using your WIEN2k_19.2 installation directory but are
still using your older WIEN2k version installation directory.
For example, in an older WIEN2k version, you might see write_inwf_lapw
is version 1.0.0
For searching the mailing list archive, refer to the webpage:
http://susi.theochem.tuwien.ac.at/reg_user/mailing_list/
You can find previous posts on that topic. For example:
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg13078.html
Did you run userconfig_lapw [1] once to setup the WIENROOT variable in
.bashrc (or .cshrc)?
[1]
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg19445.html
On 1/15/2021 8:04 AM, Subhasis Panda wrote:
Dear Users and experts,
We have installed Wien2k_19.1 in a HPC (Processor:
On slide 19 of
http://susi.theochem.tuwien.ac.at/events/ws2017/notes/Laskowski_optic-xas.pdf
it has "broadening for Drude terms choose gamma for each case".
The above statement may be advising to do an extensive literature survey
for the specific structure under calculation.
Slide 20 has
It looks like the error is most likely because you gave the program one
core value (E_core1 of -175.4856 on line 5) when it must have two.
As seen under section "8.11.3 Input" on page 170 of the WIEN2k 19.1/19.2
usersguide [1], the joint program also must have as input an E_core2
value in
In addition, check other past posts in the WIEN2k mailing list archive
and other WIEN2k outputs to that of the error files, such as the
dayfile, as they might provide additional hints on what is causing the
error. For example, one of the posts that might help with parallel
calculation
If you are using gfortran and gcc and it helps, some of the keystrokes I
captured are shown below from when I installed WIEN2k 21.1. These are
just steps I follow as a guide for getting started and for a
configuration that gets WIEN2k on my system up and running quickly.
After that, I
I cannot remember for sure, but I think WIEN2k might need you to use
14_P21/a spacegroup setting in StructGen. It looks like your struct
file in StructGen has 14_P21/c.
Have you perhaps went to:
https://materialsproject.org/materials/mp-7944/#
Click CIF next to Final Structure and click on
As far as I recall, "x optimize" creates a range of struct files that
you specify when running that program for searching for the optimized
structure parameters. The scf calculations are completed on each one.
The energy and lattice parameter results generated from that are then
fitted using
If it is just the hyb_mgga_x_js18 functional that you see failing in
libxc-5.1.2/testsuite/xc-run_testsuite.log, it probably can be ignored
as long as you are not using the hyb_mgga_x_js18 functional. The
testsuite is also failing for me with libxc-5.1.2 and libxc-5.1.3.
I have submitted a
For example, in the cif file below you see the lattice parameters (in
the hexagonal setting) and spacegroup:
_cell_length_a 3.35
_cell_length_b 3.35
_cell_length_c 16.53
_cell_angle_alpha 90
_cell_angle_beta
This is just to let those that use libxc know that when libxc 5.1.4 is
released in the near future it will have the "make check" bug fixed:
https://gitlab.com/libxc/libxc/-/issues/318#note_565312189
On 4/24/2021 9:19 AM, Gavin wrote:
If it is just the hyb_mgga_x_js18 functional that you see
Under "Compile time errors (if any) were" during Compile/Recompile of
dstart with siteconfig, is it blank showing a successful build or does
it show an error with dstart and have you checked the
$WIENROOT/SRC_dstart/compile.msg?
username@computername:~/Desktop$ ls -l $WIENROOT/dstart
ls:
Three additional comments:
1) If you are running the slurm.job script as Non-Interactive [1,2],
you might need a "source /etc/profile.d/ummodules.csh" line like that at
[3].
[1] https://slurm.schedmd.com/faq.html#sbatch_srun
[2]
The 2i5 is that in reference to line 4 seen on page 214 of the WIEN2k
21.1 usersguide [1] (which looks like it has not changed from that of
WIEN2k 19.2 for that)?
In x_lapw under case tetra, it looks like case.int is unit 5.
In SRC_tetra/tetra.f, it looks like it is reading free form on line
You might also check what OMP_NUM_THREADS is set to on your system in
.bashrc or .cshrc?
For example, on my Ubuntu system, I do:
username@computername:~/Desktop$ grep OMP_NUM_THREADS ~/.bashrc
export OMP_NUM_THREADS=1
As you can see I'm using a different value than the default that would
I have encountered the "gmax in case.inhf larger than gmax in case.in2"
before. Though, in my case, it was for case.in2c in cycle 1 of the scf
that the error occurred instead of case.in2.
In my case, it happened during a sloppy NiO calculation because gmax was
12 in NiO.in2c but I had put
Below, you mention you are using Intel 2018.5.274.
Don't know if it helps or not, but what is the file size of the
case.vector_1 for the failed case (+10) compared to the working ones
(-10, -5, 0, 5)?
There is this Intel post:
c.at/msg20445.html
[7]
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg05279.html
On 4/5/2021 2:36 PM, Microsoft.com team wrote:
Dear Prof. Gavin Abo
Thanks a lot for your kind help.
However, I removed all files from the case directory and started with
structure file with
I'm not an expert on hf calculations, but the WIEN2k 19.1 (19.2) UG [1]
has on page 53 under Spin-orbit coupling has:
run(sp)lapw -hf -so...
I'm not seeing your command with the combined "-hf -so" options like in
the UG and post at [2].
[1]
Not sure if helps or not, but your steps look different than what F.
Tran wrote at:
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg18937.html
On 2/27/2021 6:17 AM, pboulet wrote:
Dear all,
I am trying to perform an optic calculation with hybrid (HSE)
functional. The problem
The WIEN2k 19.1 (or 19.2) UG [1] on page 55 under "Starting a
calculation from another k-mesh" has:
/Do the calculation with the first k-mesh and ”save” it when it is
finished (do not execute clean_lapw since case.vectorhf should be present)./
From that, after your scf calculation of step 1
I don't think that is a Ubuntu bug. It seemed to be intended behavior
for many Linux distributions as some programs don't safely run in
non-interactive mode as explained better in the reference [5] in the
post at:
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg18685.html
On
Probably, nobody in this mailing list can help you with that. That is
because the WIEN2k users that developed and hosted the
add_boltz2_to_w2web package for doing that changed its availability from
public to private.
A long time ago, I think a WIEN2k user mentioned to me in a private
It might also be worth mentioning that you may need to look into the
details of the structure that you are calculating.
By that, I'm referring to how optimization of atomic coordinates does
not work on structures were there are no atoms in a free atomic position
and all atoms in the structure
hink what
nobody else has thought", Albert Szent-Györgyi
www.numis.northwestern.edu <http://www.numis.northwestern.edu>
On Wed, Aug 25, 2021, 07:32 Gavin Abo <mailto:gabo13...@gmail.com>> wrote:
See VESTA's website [1] on how it exports cif [2] and opens a
.struct f
See VESTA's website [1] on how it exports cif [2] and opens a .struct file.
CrystalMaker also has a "Import Data From: WIEN2k Structure" and "Export
Data To: CIF" according to its website [3].
[1] https://jp-minerals.org/vesta/en/
[2] https://youtu.be/lxMbH71JvHA
[3]
The .vsp from a non-spin polarized calculation (run_lapw) doesn't seem
right. It probably should be reading .vspup (or .vspdn) based on
uplapw2.error for a spin polarized calculation.
As described at [1], mixing those can cause issues. You might try
moving all files from the NaYbO1
Are you perhaps referring to the gather_energy.pl in the
BoltzTraP.tar.bz2 file downloadable at [1] as well as the patch
available for it at [2]?
[1]
/2021 9:51 AM, Mohaddeseh Abbasnejad wrote:
Dear Gavin Abo,
Thanks for your help.
I had installed BoltzTraP2 using the pip command.
Now, I installed the code directly and I also modified the
"gather_energy.pl <http://gather_energy.pl>" file using a patch for that.
Ho
In your "NaYbO2 (2).struct" file, I see:
ATOM -2: X=0.3000 Y=0.3000 Z=0.3000
ATOM -15: X=0.7000 Y=0.7000 Z=0.7000
Are those supposed to be 1/3 and 2/3, respectively? If so, maybe it
could lead to ghostbands like that seen the post at:
If I recall correctly, WIEN2k 19.1 had a bug that effected R lattices
(thus your R-3m might be effected by it).
The fix might have been the
SRC_lapw1: coors.f
seen under VERSION_21: 10.4.2021 on the updates page:
http://susi.theochem.tuwien.ac.at/reg_user/updates/
If you are using gfortran
Correction below as some text was missing.
If I recall correctly, WIEN2k 19.1 had a bug that effected R lattices
(thus your R-3m might be effected by it).
The fix might have been the
SRC_lapw1: coors.f
seen under VERSION_21: 10.4.2021 on the updates page:
You might want to check what value you used for -ecut as I noticed a
WARNING from lstart of WIEN2k 21.1 if the default value of -6.0 is used:
username@computername:~/Desktop/test/LFP_opt$ ls
LFP_opt.struct
username@computername:~/Desktop/test/LFP_opt$ init_lapw -b -ecut -6.0
...
next is lstart
It sounds as if you prefer to use "init_so" in the terminal, but then
like to do the bandstucture calculation in w2web.
As Gerhard hinted at by his question "Did you start the scf cycle from
"run SCF" and marked the box with spinorbit ?".
In w2web, you could click "run SCF" in the left
You might need the oneAPI Base Toolkit since at [1], I see:
*Intel® oneAPI Base Toolkit*
General Compute
Intel® oneAPI Collective Communications Library
Intel® oneAPI Data Analytics Library
Intel® oneAPI Deep Neural Networks Library
Intel® oneAPI DPC++/C++ Compiler
Intel®
Will you help me now how to locate the "libmpi_usempif08.so.40"
The libmpi_usempif08.so.40 seems to be a Open MPI file based on the
webpage at:
https://superuser.com/questions/1500931/error-in-linking-libmpi-so
It looks like Shared Memory Open MPI might have got linked in when you
compiled
Maybe the following list of references and words taken from them can help:
http://susi.theochem.tuwien.ac.at/reg_user/mailing_list/
- What command(s) was used for the calculation (e.g., init_lapw,
run_lapw ..., runsp_lapw [-p] [-so] [-hf] ..., save_lapw)?
Dr. Chakrabarti,
Looking at your "LCrT_GGA_opt_CrAFM_vol1.00.struct" in a text
editor, I see you have a P lattice:
P LATTICE,NONEQUIV.ATOMS: 56
Which if the P lattice structure is not reduced by sgroup, it is
probably computational demanding.
In your email below, I see:
lapw1 -up
Can you also edit the Makefile (and Makefile.orig) for SRC_aim in WIEN2k
21.1 so that it compiles with gfortran? It may be enough to change the
two instances of lower case .f90 under the .F.o to upper case .F90. I
have not tried compiling with those changes with ifort but those changes
likely
of: ( : % [ . = =>
WIEN2k after May 2020 (the case.mommat2 file is not a fixed format)
---^
compilation aborted for read_mommat_pij.f90 (code 1)
make: *** [read_mommat_pij.o] Error 1
Regards
Bhamu
On Mon, Dec 6, 2021 at 12:53 AM Gavin Abo wrote:
According to the README.md at
Thanks for your help. It's working fine now.
but why this message is printing
The following is being printed as an informational message that shows
that the lapw1 calculation on the first node is Done followed by tcsh
commands the lapw1para_lapw script used for the
: .000228485000 CTEST: .0042395
STOP LAPW0 END
STOP LAPW1 END
STOP LAPW2 END
STOP CORE END
STOP MIXER END
ec cc and fc_conv 1 1 1
> stop
On 12/26/2021 11:16 AM, Gavin Abo wrote:
Can you provide more information to try to reproduce the error?
I'm using the patches at [1] with WIE
Can you provide more information to try to reproduce the error?
I'm using the patches at [1] with WIEN2k gfortran compiled [2] but I
must have something different in my calculation setup because it
completes successfully in cycle 7 on my system:
username@computername:~/wiendata/test$ cat
In the .bashrc file you posted, I see:
# If not running interactively, don't do anything
case $- in
*i*) ;;
*) return;;
esac
Have you check if that is returning before WIENROOT is set which could
lead to the "lapw1c: command not found".
If that this the case, the post at the
_$lockfile[$p] ) >& .stdout1_$loop; if ( -f .stdout1_$loop
) bashtime2csh.pl_lapw .stdout1_$loop > .temp1_$loop; grep \%
.temp1_$loop >> .time1_$loop; grep -v \% .temp1_$loop | perl -e
"print stderr " )
In display output.
On Tue,
There is the following, but maybe it will not help since it is just a
list of links to previous posts already given in the mailing list.
At [1], it advises to use "at least one iteration".
In your post at [2] if I have interpreted it correctly, you have a 3D
structure (cubic spinel supercell
I'm using Ubuntu 20.04 LTS also but with a patched WIEN2k 21.1 that was
compiled with gfortran and OpenBLAS. The WIEN2k 21.1 bug fixes
(patches) I got from the past posts in the mailing list. A list of the
url links to those posts are in the README file at [1].
I also recently encountered
I follow that your lattice parameters a=18.508 Bohr, b=39.835 Bohr,
c=40.199 Bohr, α=119.701 degrees, β=103.309 degrees, and γ=90.0 degrees
using the equation at [1] give you
Volume_triclinic = 18.508 Bohr*39.835 Bohr*40.199
Bohr*sqrt(1-cos(119.701 degrees *(π radians/180
There is the relation [1]:
λ = hc/E
Then with that:
λ = limit_{E→0} [hc/E] = ∞
I seem to be missing what you defined epsilon_0 and epsilon_oo as.
There is ε0 defined as the dielectric constant at low frequency and ε∞
the dielectric constant at high frequency like in equation (18) of [2],
According to the README.md at [1], read_mommat_pij.f90 has to be
modified for WIEN2k 19.1. Did you do that? If you didn't do that it
might explain why your dEij(n,k) and dEij(m,k) values are both zero.
In the mstar.f90 source code (from lines 422 and 423) [2], you can see
that dE needs to
wrote:
I use intel compilers because they are faster than gfortran. Is this
what you see or you find then to be with same speed?
Saludos
Pablo
*De:* Wien en nombre de
Gavin Abo
*Enviado:* viernes, 16 de julio de 2021 09:06
that).
[1]
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg21134.html
[2] https://www.scivision.dev/intel-oneapi-fortran-install/
On 7/16/2021 8:00 PM, delamora wrote:
Thank you Gavin Abo and Laurence Marks.
It seems that I can download it from Mexico.
Now; I want it for the WIEN2k
The Intel compilers (e.g., C++ and Fortran) currently seem to be free
for everyone with oneAPI without Priority Support from Intel as seen at:
https://software.intel.com/content/www/us/en/develop/articles/free-intel-software-developer-tools.html
If you need the Priority Support from Intel,
If you are referring to classical BoltzTraP (e.g., version 1.2.5), I
have not seen any support recently for that and past support was very
limited.
If you are referring to BoltzTraP2 that the developers replaced the
classical BoltzTraP with, that is supported over in BoltzTraP Google
group.
Most likely to solve that, you would have to look in the compile.msg
files as the program is showing.
If there was an issue with patching the files, then you would have to go
back to the WIEN2k tar package to extract the original file and then it
could be patched again.
The error messages
If you go to [1], find for example "Documentation for the 5.1 release
(PDF); optimization flags", click on optimization flags, then click on
"3.10 Options That Control Optimization". Then, it should take you to [2].
Under -O2, there is "Please note the warning under -fgcse about invoking
-O2
.
--
Is this ok?
--------
*De:* Wien en nombre de
Gavin Abo
*Enviado:* miércoles, 23 de febrero de 2022 01:03 a. m.
*Para:* wien@zeus.theochem.tuwien.ac.at
*Asunto:* Re: [Wien] Install Wien2k using oneAPI
I believe it might have been the we
-randr.so.0 libxcb.so.1
libxcb-xinput.so.0
libQt6Network.so.6.1.3 libQt6QuickControls2.so.6.1.3
libQt6Widgets.so.6.1.3 libxcb-randr.so.0.1.0
libxcb.so.1.1.0 libxcb-xinput.so.0.1.0
Thank you very much
Bhamu
On Wed, Feb 16, 2022 at 4:30 PM Gavin Ab
With your offline install [1] command below, it will likely try to
install it in Intel's default location (/opt/intel) which is typically
for root permissions.
You would need to install it in a user directory that you have user
permission to. That might be for example /home/username/intel.
I believe it might have been the webpage at [1] that I followed to
install oneAPI within Ubuntu, which had me run a single terminal command
to install it:
sudo apt install intel-hpckit
I think I came across that webpage on the website at [2] having links to
installation of oneAPI also for
What cycle is that for? As described at [1], case.dmatup/dn must be
present for orb to run. If it is happening in the first scf cycle, it
might be fine since I believe case.dmatup/dn are created during cycle 1
such that you won't see orb until cycle 2.
[1]
That error looks similar to the one reported at:
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg20990.html
According to the post at
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg21012.html
the solution might have been to install the perl-Sys-Hostname
It might be for a very old version of Fedora the command:
dnf install compat-libstdc++-33
The new command seems be for Fedora 35 based on [1]:
dnf install libstdc++
or [2,3]:
yum install libstdc++
[1]
Whether installing on a local machine or a HPC system, the general
installation instructions from section "11.2 Installation of WIEN2k" of
the WIEN2k 21.1 usersguide [1] should be the same, which are:
1) Place WIEN2k_21.1.tar in a folder in your home directory (e.g.,
Apparently, that FFTPACK error in your message below is an intended
feature for WIEN2k 21.1. It seems to be because FFTPACK support was
removed. Since on the WIEN2k updates page [1], there is the following:
*all codes SRC_*/** have changed cmplx(a,b) to dcmplx(a,b), conjg to
dconjg and in
*Short answer*
The WIEN2k webpage has the sentence [1]:
/The linearized augmented plane wave (LAPW) method is among the most
accurate methods for performing electronic *structure calculations for
crystals*./
Amorphous is defined in [2] as non-crystalline and in [3] it means
"shapeless" and
Sometimes it can be better to have a cheap computer if you can remote
connect to a high performance computing (hpc) [1] cluster.
There can be quite a bit of difference in the computing resources that a
thousand dollar desktop computer provides compared at a million dollar
hpc [2].
If your
1101 - 1200 of 1293 matches
Mail list logo
