[Wien] Number of charge concentration in the system

[halim said]

 Dear Wien2k  users community,

I would like to ask you if we can get the results of  total number of 
concentration of the system from wien2k codeLooking forward your answer.
Halim Said
 

   

   

   

   ___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

Re: [Wien] Querry in a resultant structure

[Abderrahmane Reggad]

Hello again

I have repeated the calculation using the low symmetry structure and i
found a close results to those of the monoclinic one.

I have checked the wyckoof positions and the symmetry operations of the
orthorhombic  and the monoclinic structures and I have found that the later
is a subgroup of the former and the only difference is the change of the
lattice parameters and the atomic positions.


Here is the low symmetry structure

MnP-Pnma-afmIII2

P   LATTICE,NONEQUIV.ATOMS:
4
MODE OF CALC=RELA
unit=bohr
 11.637501  6.731303 11.245005 90.00 90.00 90.00
ATOM  -1: X=0.00032814 Y=0.2500
Z=0.24996705
  MULT= 2  ISPLIT=
8
  -1: X=0.99967186 Y=0.7500
Z=0.75003295
Ni1NPT=  781  R0=0.5000 RMT= 2.25Z:
28.0
LOCAL ROT MATRIX:0.000 1.000
0.000
 0.000 0.000
1.000
 1.000 0.000
0.000
ATOM  -2: X=0.50030217 Y=0.2500
Z=0.25003393
  MULT= 2  ISPLIT=
8
  -2: X=0.49969783 Y=0.7500
Z=0.74996607
Ni2NPT=  781  R0=0.5000 RMT= 2.25Z:
28.0
LOCAL ROT MATRIX:0.000 1.000
0.000
 0.000 0.000
1.000
 1.000 0.000
0.000
ATOM  -3: X=0.25012913 Y=0.2500
Z=0.58455708
  MULT= 2  ISPLIT=
8
  -3: X=0.74987087 Y=0.7500
Z=0.41544292
S 1NPT=  781  R0=0.0001 RMT= 1.84Z:
16.0
LOCAL ROT MATRIX:0.000 1.000
0.000
 0.000 0.000
1.000
 1.000 0.000
0.000
ATOM  -4: X=0.75011125 Y=0.2500
Z=0.91545439
  MULT= 2  ISPLIT=
8
  -4: X=0.24988875 Y=0.7500
Z=0.08454561
S 2NPT=  781  R0=0.0001 RMT= 1.84Z:
16.0
LOCAL ROT MATRIX:0.000 1.000
0.000
 0.000 0.000
1.000
 1.000 0.000
0.000
   4  NUMBER OF SYMMETRY
OPERATIONS
-1 0 0
0.
 0-1 0
0.
 0 0-1
0.

1
 1 0 0
0.
 0 1 0
0.
 0 0 1
0.

2
-1 0 0
0.
 0 1 0
0.5000
 0 0-1
0.

3
 1 0 0
0.
 0-1 0
0.5000
 0 0 1
0.
   4

Here is the monoclinic low symmetry structure

NiS-MnP-afmIII

P   LATTICE,NONEQUIV.ATOMS:  4
11_P21/m
MODE OF CALC=RELA
unit=bohr
 11.262961 10.563150  7.029377 90.00 90.00 90.00
ATOM  -1: X=0.25021227 Y=0.1424
Z=0.2500
  MULT= 2  ISPLIT=
8
  -1: X=0.74978773 Y=0.8576
Z=0.7500
Ni1NPT=  781  R0=0.5000 RMT= 2.13Z:
28.0
LOCAL ROT MATRIX:1.000 0.000
0.000
 0.000 1.000
0.000
 0.000 0.000
1.000
ATOM  -2: X=0.75024661 Y=0.50012576
Z=0.7500
  MULT= 2  ISPLIT=
8
  -2: X=0.24975339 Y=0.49987424
Z=0.2500
Ni2NPT=  781  R0=0.5000 RMT= 2.13Z:
28.0
LOCAL ROT MATRIX:1.000 0.000
0.000
 0.000 1.000
0.000
 0.000 0.000
1.000
ATOM  -3: X=0.08986359 Y=0.75012482
Z=0.7500
  MULT= 2  ISPLIT=
8
  -3: X=0.91013641 Y=0.24987518
Z=0.2500
S 1NPT=  781  R0=0.0001 RMT= 1.74Z:
16.0
LOCAL ROT MATRIX:1.000 0.000
0.000
 0.000 1.000
0.000
 0.000 0.000
1.000
ATOM  -4: X=0.41013993 Y=0.25012471
Z=0.7500
  MULT= 2  ISPLIT=
8
  -4: X=0.58986007 Y=0.74987529
Z=0.2500
S 2NPT=  781  R0=0.0001 RMT= 1.74Z:
16.0
LOCAL ROT MATRIX:1.000 0.000
0.000
 0.000 1.000
0.000
 0.000 0.000
1.000
   4  NUMBER OF SYMMETRY
OPERATIONS
 1 0 0
0.
 0 1 0
0.
 0 0 1
0.

1
-1 0 0
0.
 0-1 0
0.
 0 0 1
0.5000

2
-1 0 0
0.
 0-1 0
0.
 0 0-1
0.

3
 1 0 0
0.
 0 1 0
0.
 0 0-1
0.5000

4

The results are as follows respectively

AFMIII2

Equation of state: Birch-Murnaghaninfo   2
 E = E0 + 9/16*(B/14703.6)*V0*[(eta**2-1)**3*BP + (eta**2-1)**2*(6-4*eta**2)]
  --> eta = (V0/V)**(1/3)
 Pressure = 3/2*B*(eta**7 - eta**5)*(1 + 3/4*(BP-4)*[eta**2 - 1])
 V0,B(GPa),BP,E0   760.8174   104.6494 4.1456 -15359.539382
 vol   energy de(Birch-Murnaghan)  Pressure(GPa)
 762.9081   -15359.539337-0.25   -0.286
 739.3131   -15359.536947-0.0001633.184
 715.7179   -15359.528892 0.747.259
 880.8836   -15359.487014 0.40  -11.327
 786.5033   -15359.536637 0.000170   -3.244
 810.0984   -15359.529313 0.000130   -5.768
 833.6935   -15359.517895-0.000258   

Re: [Wien] problems with gfortran when unit 6 is associated to file

[Pavel Ondračka]

Od: Peter Blaha 
Komu: A Mailing list for WIEN2k users 
Datum: 31. 10. 2017 15:27:42
Předmět: Re: [Wien] problems with gfortran when unit 6 is associated to file

"I can reproduce this.

Apparently, some "clever informatics-guy" has changed the default
behaviour, namely that

write(*,... prints to stdout

while

write(6,... prints to the connected file, and ONLY if it has not been
connected explicitly via an OPEN statement, it would print to stdout.

Now, in gfortran one has changed that to "*" = "6" (why this limitation ??)

We have been using this different behaviour of unit=* or 5 and 6 (for 
read and write) in several places, when we want to alert a user of a
certain fact (like "inversion is (not) present).

I'll change in SRC_symmetry all "write(6," to "write(66,", which should 
fix this problem (and also modify x_lapw for the corresponding def file).

There might be similar problems in other parts. Let me know if you find one.

Regards"
 

Thanks for looking into this.


I did not detect any more problems so far, however since this type of
problems can be easily undetected (eg. this can result in extra lines  in
output files and the unlucky programs trying to parse the files later could
be in troubles, but not necessarily visibly crashing...so the problems can
stay hidden), IMO it would be better to stop using the unit 6 for file
output all over the place. If this is too much work  I can volunteer to
prepare some patches (on top of 17.1) to change the output files from unit 6
to 66 (or some other) all over the place. This should be quite easy grep
exercise. I'm using gfortran systems extensively so this is quite important
for me. Might be a good idea to get rid of the usage of unit 5 for reading
input files as well (in general fortran guides recommend using unit numbers
above 9 for file input/output).

Best regards

Pavel
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

Re: [Wien] configuring static linking with siteconfig

[Laurence Marks]

I agree that you cannot link Scalapack and different versions of mpi (e.g.
openmpi versus impi), the blacs are different.

However, one can (I have several times) do a static link of  Scalapack and
then use different versions of impi, different infiniband drivers etc on
different clusters. I have also done the same for openmpi. While there can
be advantages to doing a fresh compile on every different cluster, in many
(most) cases one can avoid this in my experience. (This can avoid broken
OS.)

On Tue, Oct 31, 2017 at 9:33 AM, Peter Blaha 
wrote:

> SCALAPACK and mpi are interconnected !!!
>
> You cannot statically link scalapack and then dynamically add different
> versions of mpi.
>
> fftw: it is so trivial to copy the fftw libraries into eg. $HOME/libs
> and link them from there 
> And a home-directory is hopefully available on every cluster 
>
>
> On 10/30/2017 04:21 PM, Laurence Marks wrote:
> > I am going to beg to differ about dynamic versus static compiling. It is
> > convenient to have a version that can be ported to other clusters and
> > only need dynamic linking of the mpi fabric (i.e. impi or openmpi). Not
> > every cluster has up to date (or even working) scalapack!
> >
> > The same holds for fftw...
> >
> > It should not be hard to do something like add a "ifndef $SCALAPACK" to
> > the Makefiles, for version 17.2 (or 18.1).
> >
> > (The user is right, except when she is wrong.)
> >
> >
> > On Mon, Oct 30, 2017 at 10:03 AM, Ruh Thomas  > > wrote:
> >
> > Dear Pavel,
> >
> > I looked into static linking with no / minimal changes into the
> > default Makefiles of WIEN2k and I am afraid it is not possible - the
> > suggested workaround by Gavin should not work. At least it did not
> > for me. Mainly because, as Gavin already mentioned, siteconfig_lapw
> > sets all the linking up dynamically.
> > Our point of view in the WIEN-group is that dynamic linking is
> > preferential anyway (especially if you want mpi-parallelism),
> > because the binaries would be rather large.
> >
> > In case you absolutely need statically linked ScaLAPACK and/or
> > FFTW-libraries you will have to manually adapt the necessary
> Makefiles.
> >
> > Kind regards
> > Thomas
> >
> > 
> > Von: Wien  > > im Auftrag von
> > Gavin Abo >
> > Gesendet: Montag, 30. Oktober 2017 12:59
> > An: wien@zeus.theochem.tuwien.ac.at
> > 
> > Betreff: Re: [Wien] configuring static linking with siteconfig
> >
> > In WIEN2k versions older than 17.1, I think the advanced user could
> > directly modify WIEN2k_OPTIONS (or OPTIONS), then run siteconfig to
> load
> > the file and just do a save to propagate the settings to the
> Makefiles.
> > I think it might be with the parallel settings that the new
> > auto-generation in siteconfig_lapw changed it so that also no longer
> > works.
> >
> > On line 2036 in siteconfig_lapw, there should be:
> >
> >  set SCALAPACK_LIBNAME = 'mkl_scalapack_lp64'
> >
> > Have you tried changing it to:
> >
> >  set SCALAPACK_LIBNAME = 'ibscalapack.a'
> >
> > Similarly, maybe try changing line 2795:
> >
> >  set fftwlibspara = "-l${FFTW_LIBNAME}_mpi"
> >
> > to say
> >
> >  set fftwlibspara = "-lfftw3_mpi.a"
> >
> > On 10/30/2017 3:21 AM, Pavel Ondračka wrote:
> > > Dear Wien2k mailing list,
> > >
> > > what is the recomended way to link Wien2k with static libs using
> the
> > > siteconfig script? For example when I go to "SCALAPACK Settings" I
> > > would like to link with static libscalapack.a, however I can only
> set
> > > the SCALAPACKROOT and SCALAPACK_LIBNAME and the final
> > SCALAPACK_LIBS is
> > > autogenerated to link with a dynamical library. Is there a way to
> edit
> > > the SCALAPACK_LIBS and link with a static library without editing
> the
> > > generated makefiles manually? BTW similar problems is with fftw
> > > settings...
> > >
> > > Best regards
> > > Pavel Ondračka
> > ___
> > Wien mailing list
> > Wien@zeus.theochem.tuwien.ac.at  tuwien.ac.at>
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__zeus.
> theochem.tuwien.ac.at_mailman_listinfo_wien=DwIFBA=
> yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws=U_
> T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0=Q6Vgp8k1XOuU6scVd5mmvZz1YmYubE
> 5qd9eDgXDOH9g=xSQeLsy-LVR66lvZdADYnonOoM0A44mTqV0kKpZScZA=
> >  3A__zeus.theochem.tuwien.ac.at_mailman_listinfo_wien=DwIFBA=
> 

Re: [Wien] configuring static linking with siteconfig

[Peter Blaha]

SCALAPACK and mpi are interconnected !!!

You cannot statically link scalapack and then dynamically add different 
versions of mpi.


fftw: it is so trivial to copy the fftw libraries into eg. $HOME/libs 
and link them from there 

And a home-directory is hopefully available on every cluster 


On 10/30/2017 04:21 PM, Laurence Marks wrote:

I am going to beg to differ about dynamic versus static compiling. It is
convenient to have a version that can be ported to other clusters and
only need dynamic linking of the mpi fabric (i.e. impi or openmpi). Not
every cluster has up to date (or even working) scalapack!

The same holds for fftw...

It should not be hard to do something like add a "ifndef $SCALAPACK" to
the Makefiles, for version 17.2 (or 18.1).

(The user is right, except when she is wrong.)


On Mon, Oct 30, 2017 at 10:03 AM, Ruh Thomas > wrote:

Dear Pavel,

I looked into static linking with no / minimal changes into the
default Makefiles of WIEN2k and I am afraid it is not possible - the
suggested workaround by Gavin should not work. At least it did not
for me. Mainly because, as Gavin already mentioned, siteconfig_lapw
sets all the linking up dynamically.
Our point of view in the WIEN-group is that dynamic linking is
preferential anyway (especially if you want mpi-parallelism),
because the binaries would be rather large.

In case you absolutely need statically linked ScaLAPACK and/or
FFTW-libraries you will have to manually adapt the necessary Makefiles.

Kind regards
Thomas


Von: Wien > im Auftrag von
Gavin Abo >
Gesendet: Montag, 30. Oktober 2017 12:59
An: wien@zeus.theochem.tuwien.ac.at

Betreff: Re: [Wien] configuring static linking with siteconfig

In WIEN2k versions older than 17.1, I think the advanced user could
directly modify WIEN2k_OPTIONS (or OPTIONS), then run siteconfig to load
the file and just do a save to propagate the settings to the Makefiles.
I think it might be with the parallel settings that the new
auto-generation in siteconfig_lapw changed it so that also no longer
works.

On line 2036 in siteconfig_lapw, there should be:

 set SCALAPACK_LIBNAME = 'mkl_scalapack_lp64'

Have you tried changing it to:

 set SCALAPACK_LIBNAME = 'ibscalapack.a'

Similarly, maybe try changing line 2795:

 set fftwlibspara = "-l${FFTW_LIBNAME}_mpi"

to say

 set fftwlibspara = "-lfftw3_mpi.a"

On 10/30/2017 3:21 AM, Pavel Ondračka wrote:
> Dear Wien2k mailing list,
>
> what is the recomended way to link Wien2k with static libs using the
> siteconfig script? For example when I go to "SCALAPACK Settings" I
> would like to link with static libscalapack.a, however I can only set
> the SCALAPACKROOT and SCALAPACK_LIBNAME and the final
SCALAPACK_LIBS is
> autogenerated to link with a dynamical library. Is there a way to edit
> the SCALAPACK_LIBS and link with a static library without editing the
> generated makefiles manually? BTW similar problems is with fftw
> settings...
>
> Best regards
> Pavel Ondračka
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at 

https://urldefense.proofpoint.com/v2/url?u=http-3A__zeus.theochem.tuwien.ac.at_mailman_listinfo_wien=DwIFBA=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws=U_T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0=Q6Vgp8k1XOuU6scVd5mmvZz1YmYubE5qd9eDgXDOH9g=xSQeLsy-LVR66lvZdADYnonOoM0A44mTqV0kKpZScZA=


SEARCH the MAILING-LIST at:

https://urldefense.proofpoint.com/v2/url?u=http-3A__www.mail-2Darchive.com_wien-40zeus.theochem.tuwien.ac.at_index.html=DwIFBA=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws=U_T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0=Q6Vgp8k1XOuU6scVd5mmvZz1YmYubE5qd9eDgXDOH9g=wdlvciFGzC1kPAxeB-rTSyqpzfXnq5o5X9P5ynYqpW4=


___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at 

Re: [Wien] problems with gfortran when unit 6 is associated to file

[Peter Blaha]

I can reproduce this.

Apparently, some "clever informatics-guy" has changed the default 
behaviour, namely that


write(*,...prints to stdout

while

write(6,...prints to the connected file, and ONLY if it has not been 
connected explicitly via an OPEN statement, it would print to stdout.


Now, in gfortran one has changed that to "*" = "6"  (why this limitation ??)

We have been using this different behaviour of unit=* or 5 and 6 (for 
read and write) in several places, when we want to alert a user of a 
certain fact (like "inversion is (not) present).


I'll change in SRC_symmetry all "write(6," to "write(66,", which should 
fix this problem (and also modify x_lapw for the corresponding def file).


There might be similar problems in other parts. Let me know if you find one.

Regards

On 10/30/2017 06:13 PM, Pavel Ondračka wrote:

Dear Wien2k mailing list,

this is probably gfortran (I have version 7.2.1) specific. Recently I
saw some problems with dstart crashing in init_lapw for structures
without inversion, when trying to open the complex input files
(case.in1c and case.in2c), which are not present.

In init_lapw the in1c and in2c files are prepared if this test
succeeds:
set b = `grep INVERSION $file.outputs`
if ( $#b == 7 ) then

The problem is that on ifort system the case.outputs contains the line:
PGBSYM: SPACE GROUP DOES NOT CONTAIN INVERSION
and with gfortran there is one extra line:
SPACE GROUP DOES NOT CONTAIN INVERSION
which is printed to stdout with ifort

Greeping for the error message in SRC_symmetry finds this two
consequent lines:
SRC_symmetry/pgbsym.f:  WRITE(6,*) 'PGBSYM: SPACE GROUP DOES NOT
CONTAIN INVERSION'
SRC_symmetry/pgbsym.f:  WRITE(*,*) 'SPACE GROUP DOES NOT CONTAIN
INVERSION'

looking at the def file:
6, 'testcase.outputs','unknown','formatted',0
17,'testcase.in2_sy', 'unknown','formatted',0
20,'testcase.struct', 'old','formatted',0
21,'testcase.struct_st', 'unknown','formatted',0
the unit 6 (usually stdout although IIRC not mandated by the standard)
is attached to testcase.outputs

The question is what is the standard way to do in this case, the
gfortran still treats the asterisk as unit 6 (and hence the WRITE(*,*)
stuff end in the testcase.outputs file), while the ifort still sends
the WRITE(*,*) stuff to stdout.

This manifests later in dstart, x script actually checks for the
inversion by different method and crashes when it tries to open the
in*c files. When looking at the x script, there are also other
instances of redefining the unit 6, so this might be problematic in
more places...

Is this an undefined behavior or a bug in gfortran? Is there maybe some
gfortran switch to force the ifort behavior?

Best regards
Pavel
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html



--

  P.Blaha
--
Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
Phone: +43-1-58801-165300 FAX: +43-1-58801-165982
Email: bl...@theochem.tuwien.ac.atWIEN2k: http://www.wien2k.at
WWW:   http://www.imc.tuwien.ac.at/TC_Blaha
--
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

[Wien] CPU advice

[Laurence Marks]

I am going to buy a few more nodes for my own small cluster. From what I
can see the Skylark 6130 looks to be an appropriate CPU/cost compromise,
taking into account that I have 4 IB connections available so 32 cores/node
is appropriate. I am undecided as yet about 4Gb/core or 6Gb/core -- the
target is large calculations.

Any comments?

-- 
Professor Laurence Marks
"Research is to see what everybody else has seen, and to think what nobody
else has thought", Albert Szent-Gyorgi
www.numis.northwestern.edu ; Corrosion in 4D: MURI4D.numis.northwestern.edu
Partner of the CFW 100% program for gender equity, www.cfw.org/100-percent
Co-Editor, Acta Cryst A
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

Re: [Wien] Methods to change spin states

[Laurence Marks]

Dear Pavel,

Thanks. Probably this and other small utilities should go into a directory
somewhere that is on the unsupported page.

On Thu, Oct 26, 2017 at 8:15 AM, nov...@fzu.cz  wrote:

> Dear Laurence,
>
> when we calculated the exchange integrals by subtracting total energy of
> different spin configurations we first converged single configuration.
> Starting .clmup(dn) and .vorbup(dn) for next configuration were obtained
> by fliping the selected spin. To this end simple programs were used. The
> method worked in cases we considered and convergence was much faster
> comparing to calculation from scratch. I attach spinreverse.tar containing
> the programs and jobs.
> I hope this will help.
> Regards Pavel
>
> > Anyone have any suggestions about approaches to change in a fairly
> > controlled fashion final spin states. (I am asking because different spin
> > states can be local minima, so some sort of search over them can be
> > needed.) The methods I know of are (briefly):
> >
> > a) Change case.inst and use lstart & clmextrapol -up/dn.[1]
> >
> > b) With +U, edit dmat, run orb -up/dn and use -orbc
> >
> > c) Use runfsm
> >
> > d) Use different starting spins -- which can be very slow so is a last
> > resort except for AFM ordering.
> >
> > In one case I am working on, a) & c) are failing, I am trying b) but
> there
> > may be others.
> >
> > [1] For a), with a given case.inst run "x dstart -super -up/dn", edit
> > case.inst to add/subtract spins then use lsttart & clmextrapol -up/dn
> >
> > --
> > Professor Laurence Marks
> > "Research is to see what everybody else has seen, and to think what
> nobody
> > else has thought", Albert Szent-Gyorgi
> > www.numis.northwestern.edu ; Corrosion in 4D:
> > MURI4D.numis.northwestern.edu
> > Partner of the CFW 100% program for gender equity,
> www.cfw.org/100-percent
> > Co-Editor, Acta Cryst A
> > ___
> > Wien mailing list
> > Wien@zeus.theochem.tuwien.ac.at
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__zeus.
> theochem.tuwien.ac.at_mailman_listinfo_wien=DwIDaQ=
> yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws=U_
> T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0=kUoFbpT47ecdZ_
> 0kixe4aT9O_vuXHUMxTPE7-Z5dcCk=3QlVBmZ-ho4GdQ4esySJehc0jAFSJy66dfSbTk
> c9L6M=
> > SEARCH the MAILING-LIST at:
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.
> mail-2Darchive.com_wien-40zeus.theochem.tuwien.ac.at_
> index.html=DwIDaQ=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws=U_
> T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0=kUoFbpT47ecdZ_
> 0kixe4aT9O_vuXHUMxTPE7-Z5dcCk=C5ZgIsf1qjIr7toZ7P1LST10pVX7fI
> 4PJ_ScLENw6t8=
> >
>



-- 
Professor Laurence Marks
"Research is to see what everybody else has seen, and to think what nobody
else has thought", Albert Szent-Gyorgi
www.numis.northwestern.edu ; Corrosion in 4D: MURI4D.numis.northwestern.edu
Partner of the CFW 100% program for gender equity, www.cfw.org/100-percent
Co-Editor, Acta Cryst A
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

Re: [Wien] Methods to change spin states

[novakp]

Dear Laurence,

when we calculated the exchange integrals by subtracting total energy of
different spin configurations we first converged single configuration.
Starting .clmup(dn) and .vorbup(dn) for next configuration were obtained
by fliping the selected spin. To this end simple programs were used. The
method worked in cases we considered and convergence was much faster
comparing to calculation from scratch. I attach spinreverse.tar containing
the programs and jobs.
I hope this will help.
Regards Pavel

> Anyone have any suggestions about approaches to change in a fairly
> controlled fashion final spin states. (I am asking because different spin
> states can be local minima, so some sort of search over them can be
> needed.) The methods I know of are (briefly):
>
> a) Change case.inst and use lstart & clmextrapol -up/dn.[1]
>
> b) With +U, edit dmat, run orb -up/dn and use -orbc
>
> c) Use runfsm
>
> d) Use different starting spins -- which can be very slow so is a last
> resort except for AFM ordering.
>
> In one case I am working on, a) & c) are failing, I am trying b) but there
> may be others.
>
> [1] For a), with a given case.inst run "x dstart -super -up/dn", edit
> case.inst to add/subtract spins then use lsttart & clmextrapol -up/dn
>
> --
> Professor Laurence Marks
> "Research is to see what everybody else has seen, and to think what nobody
> else has thought", Albert Szent-Gyorgi
> www.numis.northwestern.edu ; Corrosion in 4D:
> MURI4D.numis.northwestern.edu
> Partner of the CFW 100% program for gender equity, www.cfw.org/100-percent
> Co-Editor, Acta Cryst A
> ___
> Wien mailing list
> Wien@zeus.theochem.tuwien.ac.at
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
> SEARCH the MAILING-LIST at:
> http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
>


spinreverse.tar
Description: Unix tar archive
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html