Giter Site home page Giter Site logo

feff10's People

Contributors

cjantonelli avatar fdvila avatar haozeke avatar jjkas avatar times-software avatar tunsheng avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

feff10's Issues

xnatph(stoichiometry) ratio maximum of 999999

Given how FEFF writes the pot.inp file, stoichiometries of 10^6 or larger end up spilling over into the lmaxsc column.

feff.inp
image

pot.inp
image

A quick fix for this is to scale down all the stoichiometry values by dividing them all by 10.
4185 -> 418.5
14570 -> 1457.0
135 -> 13.5
4810 -> 481.0
And leave the Nitrogen stoichiometry alone. This does change the overall ratio, but it's up to the user if a ratio of 10^5 vs a ratio of 10^6 really makes a difference.

For a more permanent, but still a Band-Aid fix, I also tried changing line 592 in /src/COMMON/m_inpmodules.f90 such that the string formatting had more digits to work with when pot.inp gets written.
image
to
image

Deleting duplicate source atoms

This was a piece of code in src/RDINP/ffsort.f90 which is causing duplicate source atoms to get removed. Normally the code should fail on duplicate atoms, but there is a loop that "makes a smaller list of atoms from a big one". I'm not quite sure what the original intention of this block was, but changing from

image

to

image

fixes the issue. Alternatively you could just set the condition to "greater than zero" to entirely avoid this problem. Dr. Kas hypothesized that this code might be a left over way of simulating vibrational effects by having multiple source atoms all very close together.

The input file which initially brought this bug to light had this code block for ATOMS
image
where the Fe.1 atoms are too close to the absorbing Fe to be physical. This input file was most likely created using some automated tool like Web Atoms, where the coordinates for the Fe were not defined properly.

The header at the top of the input file reads
image

It should be noted that the x, y, and z coordinates should be 0.3 (repeating), 0.6 (repeating, and 0.75, but they are cut off after only two digits. Putting this into Web Atoms, we get the same input file

image

but this can be fixed by using fractional coordinates (Web Atoms automatically converts 1/3 to 0.33333333333333 (up to machine precision))

image

And we see that the two duplicate source atoms that were 0.02 Angstroms away no longer appear. The key takeaway here is to always make sure the structure you have defined is indeed what you want to calculated. Try looking at your structure in a molecular viewer, and whenever possible, use high precision or fractional coordinates when defining atomic coordinates.

Makefile `. Utility/MkFeffScript mpi` failed in Ubuntu

Dear developer!

I found that when I execute make mpi in wsl2 ubuntu, it generates feff instead of feffmpi. I found that the reason is that when Makefile executes . Utility/MkFeffScript mpi, it will call /bin/sh shell, in ubuntu /bin/sh -> dash. But in the dash shell, . Utility/MkFeffScript mpi cannot read $1 as mpi.
On the contrary, bash Utility/MkFeffScript mpi works well for me.

Error with example (HUBBARD - NiO): Unknown card HUBBARD

Using the most recent version from the downloads area, v10.0.0, with the most recent stable JRE on windows, version 8 update 371 (April 18, 202).

Loading in the Hubbard NiO example, I get an error window that reads the following:

An error occurred while parsing
<my messy directory structure>/feff.inp

edu.washington.jfeff.inp.InpDataException: Unknown card HUBBARD found in inp data at line 20
Please check that the file is a  valid feff.inp file.

The manual does not mention anything about a HUBBARD card either. Is this from an a more recent, yet unreleased version?
And additionally, are there some instruction from compiling from source? There are a few issues I'm having with the Java install on the Linux HPC systems I use.

Many thanks,
Ben

Relative Mag. for L3 and L2

Hi , Thanks for developing this wonderful tool. I have a general question and am not sure if this is the right place to ask.

  1. Is there any way to simultaneously compute L3 and L2?
  2. If not, can I directly compare the intensity from the two calculations? In the documentation, it was mentioned that output intensity in eels.dat is in absolute scale, so I am assuming we can directly compare the results for L3 and L2 edge. However, the simulation gives a much weaker peak of Ti L2 in SrTiO3 compared to Ti L3, which is inconsistent with experimental data? Do you have any comments on this? Thanks a lot for your help.

SCF Found bad counts

Hello,

I am using feff 10.0.0 to calculate XANES for the spinel structure FeCr2O4 and got the following issue in the SCF step:

image

Here is the feff.inp:

TITLE spinel
TARGET 1
CIF HEO.cif
RECIPROCAL
XANES 6.0
LDOS -30 15 0.01
CONTROL 1 1 1 1 1 1
KMESH 200
PRINT 5 1 1 1 1 1
EDGE L2 0.0
SCF 4.5
S02 0.0
COREHOLE None
FMS 6.0
END

I also attach here the HEO.cif file uesd in the calculation
HEO.txt

It seems to do with the element Cr that the issue happened also in some other spinel structures containg Cr but it works well without Cr. Is there any way to work out? Thanks in advance.

Best,
Bo Zhao

Runtime segfault

I get the following segmentation fault when running the XANES/Cu example using a serial binary compiled with optimizations (FLAGS = -O3). The segfault doesn't happen if I remove the compiler optimization flags (FLAGS = -O0 -g -fp-stack-check -traceback -heap-arrays -check bounds). The Compiler.mk is also listed at the end.

New Fermi level:    mu=  -7.729 eV  Charge distance=  0.0000 (partial c.d.=  0.0002)
Electronic configuration
  type     l     N_el
     0     0    0.692
     0     1    0.754
     0     2    9.554
     0     3    0.000
     1     0    0.692
     1     1    0.754
     1     2    9.554
     1     3    0.000
Charge transfer:  type  charge
       0    0.000
       1   -0.000
Convergence reached in    8 iterations.
Done with module: potentials.

Calculating screened core-hole potential ...
FMS for a cluster of   19 atoms around iph =   0
    0% of energy integration
   20%
   40%
   60%
   80%
  100%
Preparing response function.
Computing (1 - K Chi0)^-1 v_ch
Done with module: screened core-hole potential.

Calculating cross-section and phases ...
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image              PC                Routine            Line        Source
xsph               00000000021B87FA  Unknown               Unknown  Unknown
libpthread-2.31.s  00007FCF4FB4C420  Unknown               Unknown  Unknown
xsph               000000000048A5A4  Unknown               Unknown  Unknown
xsph               0000000000471E5A  Unknown               Unknown  Unknown
xsph               0000000000403A22  Unknown               Unknown  Unknown
libc-2.31.so       00007FCF4F81B0B3  __libc_start_main     Unknown  Unknown
xsph               000000000040392E  Unknown               Unknown  Unknown
FMS calculation of full Green's function ...
FEFF-serial using 1 thread.
 Error opening file, phase.bin in module rdxsph
 Fatal error
CHOPEN
##### This file contains compiler settings for the FEFF9 project
## Define below:
## - F90    :  choice of fortran90 compiler
## - FLAGS  :  compilation options
## - MPIF90 :  mpif90 compiler (optional)
## - USE_MKL:  blas/lapack libraries (optional)


########################################
#              ifort
########################################
F90 = ifort
# for a MacBook1,1 with a 32-bit Intel Core Duo processor ("Yonah") running Snow Leopard - generate 32bit executable:
# FLAGS = -O3  -L/Developer/SDKs/MacOSX10.6.sdk/usr/lib/ -m32 -O2 -axsse4.2,sse3 -prec_div -132  -g
# Regular 64-bit code e.g. for iMac, (recent-ish) MacBook Pro, etc. (10.7, 10.6) :
# Full-on debugging mode for ifort:  (note this catches different things depending on optimization settings)
# FLAGS = -O3 -check arg_temp_created -gen-interfaces -warn interfaces -g -fp-stack-check -traceback  -FR -heap-arrays -check bounds
# FLAGS = -O0  -g -fp-stack-check -traceback -heap-arrays -check bounds
# Production code Mac: (note this runs for Leopard and higher without performance sacrifice compared to 10.8 optimizations) :
# FLAGS =   -O3 -mmacosx-version-min=10.5 $(FCINCLUDE)
# Production code Linux:
  FLAGS = -O3


########################################
#              mpi
########################################
 MPIF90 = mpif90
 MPIFLAGS =  -g -O2 -ffree-line-length-none
# MPIFLAGS = -O3 -check arg_temp_created -gen-interfaces -warn interfaces -g -fp-stack-check -traceback  -heap-arrays -check bounds


########################################
#              mkl
########################################
# MAIN SWITCH (toggle mkl on/off) :
# uncomment to use MKL
# comment to use standard FEFF blas/lapack (MATH/lu.f90)
USE_MKL = "on"

# Must edit for local mkl installation
# $MKLROOT must exist (optionally you can define it here)
#
## Mac MKL:
 MKLSEQUENTIALMAC = $(MKLROOT)/lib/libmkl_blas95_lp64.a $(MKLROOT)/lib/libmkl_lapack95_lp64.a $(MKLROOT)/lib/libmkl_intel_lp64.a $(MKLROOT)/lib/libmkl_sequential.a $(MKLROOT)/lib/libmkl_core.a -lpthread -lm
 MKLTHREADEDMAC =   $(MKLROOT)/lib/libmkl_blas95_lp64.a $(MKLROOT)/lib/libmkl_lapack95_lp64.a $(MKLROOT)/lib/libmkl_intel_lp64.a $(MKLROOT)/lib/libmkl_intel_thread.a $(MKLROOT)/lib/libmkl_core.a -liomp5 -lpthread -lm
## Intel MKL:
MKLSEQUENTIALLINUX =  $(MKLROOT)/lib/intel64/libmkl_blas95_lp64.a $(MKLROOT)/lib/intel64/libmkl_lapack95_lp64.a -Wl,--start-group  $(MKLROOT)/lib/intel64/libmkl_intel_lp64.a $(MKLROOT)/lib/intel64/libmkl_sequential.a $(MKLROOT)/lib/intel64/libmkl_core.a -Wl,--end-group -lpthread -lm
## Windows MKL:
#   On Windows I use Visual Studio rather than this Makefile/Compiler.mk structure.
#   Just enable "Use math libraries - MKL - Sequential" in the Project Settings
#   For the time-consuming modules (pot, fms, screen, ldos, Compton)

# Choose the right OS here :
#  MKL_LDFLAGS = $(MKLSEQUENTIALMAC)
 MKL_LDFLAGS = $(MKLSEQUENTIALLINUX)
 MKL_FCINCLUDE = -I$(MKLROOT)/include/intel64/lp64 -I$(MKLROOT)/include

# If no MKL, use these defaults instead (lu.f90 provides non-optimized blas/lapack)
 FEFF_LDFLAGS =
 FEFF_FCINCLUDE =

##### Make your final choice here :
ifdef USE_MKL
# 1/ Use the MKL settings defined above:
    LDFLAGS = $(MKL_LDFLAGS)
    FCINCLUDE = $(MKL_FCINCLUDE)
    DEPTYPE = _MKL
else
# 2/ Use the standard FEFF blas/lapack (slower but no need to install MKL):
    LDFLAGS =
    FCINCLUDE =
    DEPTYPE =
endif


########################################
#              pgf90
########################################
# F90 = pgf90
# FLAGS = -O3

########################################
#              gfortran
########################################
# KJ  Mac OS X 10.7 + gfortran
# F90 =  gfortran
# FLAGS = -ffree-line-length-none -mcmodel=medium -march=native -O2
# FDV, cygwin
#  F90 = gfortran
#  FLAGS = -ffree-line-length-none -cpp -O3

Fatal error when running Feff on Feff examples after installation

After installing Feff10 with its needed packages, and I run any of the feff examples, I get a fatal error and it doesn't find the files it needs to run the calculation. Below is my input and error message. There seems to be a space inserted into the path that feff takes but there might be something else also.

Input:
C:\Users\Jens\Documents\PhD\Fefflder\Feff10\feff10\feff10_examples\EXAFS\Cu>feff

Output:
C:\Users\Jens\Documents\PhD\Fefflder\Feff10\feff10\feff10_examples\EXAFS\Cu>set FeffPath=C:\Users\Jens\Documents\PhD\Fefflder\Feff10\feff10\bin

C:\Users\Jens\Documents\PhD\Fefflder\Feff10\feff10\feff10_examples\EXAFS\Cu>cd C:\Users\Jens

C:\Users\Jens>"C:\Users\Jens\Documents\PhD\Fefflder\Feff10\feff10\bin \rdinp"
Launching FEFF version FEFF 10.0.0

read error: cannot find file

>> file name = feff.inp

No absorbing atom (unique pot 0) was defined.
RDINP
STOP

C:\Users\Jens>"C:\Users\Jens\Documents\PhD\Fefflder\Feff10\feff10\bin \dmdw"
At line 1466 of file m_inpmodules.f90 (unit = 3)
Fortran runtime error: Cannot open file 'ff2x.inp': No such file or directory

Error termination. Backtrace:

Could not print backtrace: libbacktrace could not find executable to open
#0 0x47455b
#1 0x46ae94
#2 0x46362b
#3 0x46e567
#4 0x464f58
#5 0x436b9e
#6 0x43b6d6
#7 0x48ff53
#8 0x4013c0
#9 0x4014f5
#10 0x80187613
#11 0x80e226a0
#12 0xffffffff

C:\Users\Jens>"C:\Users\Jens\Documents\PhD\Fefflder\Feff10\feff10\bin \atomic"
Error opening file, .dimensions.dat in module dimsmod
Fatal error
CHOPEN
STOP

C:\Users\Jens>"C:\Users\Jens\Documents\PhD\Fefflder\Feff10\feff10\bin \pot"
Error opening file, .dimensions.dat in module dimsmod
Fatal error
CHOPEN
STOP

C:\Users\Jens>"C:\Users\Jens\Documents\PhD\Fefflder\Feff10\feff10\bin \ldos"
Error opening file, .dimensions.dat in module dimsmod
Fatal error
CHOPEN
STOP

C:\Users\Jens>"C:\Users\Jens\Documents\PhD\Fefflder\Feff10\feff10\bin \screen"
Error opening file, .dimensions.dat in module dimsmod
Fatal error
CHOPEN
STOP

C:\Users\Jens>"C:\Users\Jens\Documents\PhD\Fefflder\Feff10\feff10\bin \crpa"
Error opening file, .dimensions.dat in module dimsmod
Fatal error
CHOPEN
STOP

C:\Users\Jens>"C:\Users\Jens\Documents\PhD\Fefflder\Feff10\feff10\bin \opconsat"
Error opening file, .dimensions.dat in module dimsmod
Fatal error
CHOPEN
STOP

C:\Users\Jens>"C:\Users\Jens\Documents\PhD\Fefflder\Feff10\feff10\bin \xsph"
Error opening file, .dimensions.dat in module dimsmod
Fatal error
CHOPEN
STOP

C:\Users\Jens>"C:\Users\Jens\Documents\PhD\Fefflder\Feff10\feff10\bin \fms"
Error opening file, .dimensions.dat in module dimsmod
Fatal error
CHOPEN
STOP

C:\Users\Jens>"C:\Users\Jens\Documents\PhD\Fefflder\Feff10\feff10\bin \mkgtr"
Error opening file, .dimensions.dat in module dimsmod
Fatal error
CHOPEN
STOP

C:\Users\Jens>"C:\Users\Jens\Documents\PhD\Fefflder\Feff10\feff10\bin \path"
Error opening file, .dimensions.dat in module dimsmod
Fatal error
CHOPEN
STOP

C:\Users\Jens>"C:\Users\Jens\Documents\PhD\Fefflder\Feff10\feff10\bin \genfmt"
Error opening file, .dimensions.dat in module dimsmod
Fatal error
CHOPEN
STOP

C:\Users\Jens>"C:\Users\Jens\Documents\PhD\Fefflder\Feff10\feff10\bin \ff2x"
Error opening file, .dimensions.dat in module dimsmod
Fatal error
CHOPEN
STOP

C:\Users\Jens>"C:\Users\Jens\Documents\PhD\Fefflder\Feff10\feff10\bin \sfconv"
At line 1526 of file m_inpmodules.f90 (unit = 3)
Fortran runtime error: Cannot open file 'sfconv.inp': No such file or directory

Error termination. Backtrace:

Could not print backtrace: libbacktrace could not find executable to open
#0 0x45cceb
#1 0x455e94
#2 0x45206b
#3 0x459567
#4 0x453318
#5 0x40ff95
#6 0x414012
#7 0x4742f3
#8 0x4013c0
#9 0x4014f5
#10 0x80187613
#11 0x80e226a0
#12 0xffffffff

C:\Users\Jens>"C:\Users\Jens\Documents\PhD\Fefflder\Feff10\feff10\bin \compton"
Error opening file, .dimensions.dat in module dimsmod
Fatal error
CHOPEN
STOP

C:\Users\Jens>"C:\Users\Jens\Documents\PhD\Fefflder\Feff10\feff10\bin \eels"

C:\Users\Jens>"C:\Users\Jens\Documents\PhD\Fefflder\Feff10\feff10\bin \rhorrp"

gfortran11 fails to compile feff10: Error: Line truncated at (1) [-Werror=line-truncation]

cd FF2X; ifort  -c -O3 -DFEFF -I../ATOM -I../BAND -I../COMMON -I../COMPTON -I../CRPA -I../DEBYE -I../DMDW -I../EELS -I../EELSMDFF -I../ERRORMODS -I../EXCH -I../FF2X -I../FMS -I../FOVRG -I../FULLSPECTRUM -I../GENFMT -I../IOMODS -I../KSPACE -I../LDOS -I../MATH -I../MKGTR -I../MODS -I../PAR -I../PATH -I../POT -I../RDINP -I../RHORRP -I../RIXS -I../SCREEN -I../SELF -I../SFCONV -I../TDLDA -I../XSPH -I../INPGEN m_thermal_xscorr.f90
m_thermal_xscorr.f90:140:132:

  140 |       WRITE(149, '(20E20.10E3)') DBLE(omega(ie)), DBLE(cchi(ie)), DIMAG(cchi(ie)), DBLE(dummy), DBLE(xmu0), DIMAG(xmu0), DBLE(fermiDirac(z1,tk,efermi))
      |                                                                                                                                    1
Error: Line truncated at (1) [-Werror=line-truncation]
m_thermal_xscorr.f90:140:132:

  140 |       WRITE(149, '(20E20.10E3)') DBLE(omega(ie)), DBLE(cchi(ie)), DIMAG(cchi(ie)), DBLE(dummy), DBLE(xmu0), DIMAG(xmu0), DBLE(fermiDirac(z1,tk,efermi))
      |                                                                                                                                    1
Error: Syntax error in argument list at (1)
m_thermal_xscorr.f90:692:132:

  692 |       WRITE(9991,'(20E20.10E3)') DBLE(z1), DIMAG(z1), DBLE(f1), DBLE(f2), DBLE(f1*f2*cauchy(z1,omega,xloss)), DBLE(emxs(ic+1)-emxs(ic))
      |                                                                                                                                    1
Error: Line truncated at (1) [-Werror=line-truncation]
m_thermal_xscorr.f90:692:132:

  692 |       WRITE(9991,'(20E20.10E3)') DBLE(z1), DIMAG(z1), DBLE(f1), DBLE(f2), DBLE(f1*f2*cauchy(z1,omega,xloss)), DBLE(emxs(ic+1)-emxs(ic))
      |                                                                                                                                    1
Error: Invalid form of array reference at (1)
f951: some warnings being treated as errors

OS: FreeBSD 13

Bug in dym2feffinp

If the dym file is of type 3, the dipole derivatives are read but not written after printing the block dynamical matrix.
This renders the created feff.dym file unusable.

I believe that adding something like this solves the problem:

`*** /usr/local/feff10-10.0.0/src/DMDW/m_dmdw.f90.ORIG 2022-04-03 10:58:24.219007337 +0200
--- /usr/local/feff10-10.0.0/src/DMDW/m_dmdw.f90 2022-04-03 11:18:50.495637646 +0200


*** 2537,2542 ****
--- 2537,2559 ----
end do
end do

  • ! Added by RRP to write the dipole derivatives for IR spectrum
  • if ( dym_In%Type .eq. 3 ) then
    
  • ! Empty separator line
  •   write(IO_dym,fmt='(a)') ''
    
  • ! Read the dipole derivatives and store in the right order
  • ! This order should allow us to use the dip. derivs directly as Lanczos seed.
  •   do iAt=1,dym_In%nAt
    
  •     do ip=1,3
    
  •       write(IO_dym,fmt='(3e14.6)') (dym_In%Dip_Der(jq,Swap(iAt),ip),jq=1,3)        
    
  •     end do
    
  •   end do
    
  • end if
    
  • ! Added by FDV to write the cell vectors, if we have the right dym type
    if ( dym_In%Type == 4 ) then
    `

Code Cleanup Suggestions

Unfortunately I will most probably not have the time to complete these tasks, but these are some thoughts from a quick code review.

  • tcsh is a nightmare
    • Even bash would be a better alternative since it supports functions
  • Makefiles are fragile
    • CMake would speed things up and make testing on the CI more trivial
      • Under the current setup the actions configuration needs to patch the generated Config.mk to test gfortran and friends
  • Depending on how the first two points are addressed, unit testing on the CI should become much simpler, with a separate job for the long running tests
    • This will allow PRs which do not modify, say, COMPTON (the slowest) be merged even faster (i.e. without waiting for over an hour to see if it passes)
  • The code has comments, but they should be formatted for Doxygen (like LAPACK is), which could then be used to generate API documentation

Why?

I was at the Les Houches 2021 School on Multiple Scattering Greens functions (actually The Green’s function approach to multiple scattering theory in electronic structure and spectroscopies) and Prof. John Rehr spoke very highly of FEFF10. Plus it is the only truly FOSS spectroscopy code I came across here so I thought this would be good.

GFortran 10+ Errors

For Gnu Fortran compilers from version 10 onwards, argument mismatches are treated as errors by default.

This means that if :

gfortran --version | head -n 1 | awk -F ' ' '{print $NF}'
# 10.3.0
# 11.1.0

returns a version greater than 10; you will be greeted with:

m_thermal_scf.f90:346:26:

  329 |       call par_bcast_double(xmunew, 1, 0)
      |                            2
......
  346 |     call par_bcast_double(xnmues, (lx+1)*(nphx+1), 0)
      |                          1
Error: Rank mismatch between actual argument at (1) and actual argument at (2) (scalar and rank-2)
m_thermal_scf.f90:347:26:

  329 |       call par_bcast_double(xmunew, 1, 0)
      |                            2
......
  347 |     call par_bcast_double(rhoval, 251*(nphx+1), 0)
      |                          1
Error: Rank mismatch between actual argument at (1) and actual argument at (2) (scalar and rank-2)
make[1]: *** [Makefile:457: POT/m_thermal_scf.o] Error 1
make[1]: Leaving directory '$HOME/Git/Github/Fortran/feff10/src'
make: *** [Makefile:171: all] Error 2

An easy workaround is simply:

87c87
> FLAGS = -ffree-line-length-none -mcmodel=medium -march=native -O2 -fallow-argument-mismatch
---
< FLAGS = -ffree-line-length-none -mcmodel=medium -march=native -O2

Basically -fallow-argument-mismatch needs to be added to the Compiler.mk.

This is a workaround and not a fix.

The fix is to follow the error and ensure the right arguments are passed throughout. Will open a PR soon.

Failed to use cif file with large structure

Dear developers,

When I use a cif file with a larger structure as structure input, feff10 will fail with an error message (in log1.dat):

Calculating SCF potentials ...
FEFF-MPI using     1 parallel threads.
Muffin tin radii and interstitial parameters [bohr]:
 FOLP for POTENTIAL type  15 is too big.
 Reduce overlap using FOLP and rerun
MOVRLP-1

I found that the reason is that when feff processes the cif file, it generates potentials for all atoms, which in my case is pot 0 to 16.
But when it converts cif to atom.dat, its default cluster radius (approximately 16.9 angstroms) is smaller than my cif unit cell parameters, so some atoms are not included in the clusters generated in atom.dat, It is the atomic type 15 in the error message.
So when I commented the atom type 15 (Pt15) in the cif file, it worked well. Using webatoms to generate input files is also effective.
I have attached all relevant files for reference.
test.zip

version

FEFF 10.0.0
feffmpi

feff.inp

TITLE test
  
CIF feff.cif
TARGET 1

XANES

EGRID
e_grid -10 20 0.1

COREHOLE RPA
EDGE K

SCF 7.0

FMS 9.0 0 2

feff.cif

data_Pt.111.a2b2c8_O1_vac15
_audit_creation_date              2021-11-11
_audit_creation_method            'Materials Studio'
_symmetry_space_group_name_H-M    'P3M1'
_symmetry_Int_Tables_number       156
_symmetry_cell_setting            trigonal
loop_
_symmetry_equiv_pos_as_xyz
  x,y,z
  -y,x-y,z
  -x+y,-x,z
  -y,-x,z
  -x+y,y,z
  x,x-y,z
_cell_length_a                    5.6105
_cell_length_b                    5.6105
_cell_length_c                    36.7204
_cell_angle_alpha                 90.0000
_cell_angle_beta                  90.0000
_cell_angle_gamma                 120.0000
loop_
_atom_site_label
_atom_site_type_symbol
_atom_site_fract_x
_atom_site_fract_y
_atom_site_fract_z
_atom_site_U_iso_or_equiv
_atom_site_adp_type
_atom_site_occupancy
O1     O     0.00000   0.00000   0.04139   1.00000  Uiso   1.00
Pt2    Pt    0.00000   0.00000   0.19903   1.00000  Uiso   1.00
Pt3    Pt    0.00000   0.00000   0.38616   0.00000  Uiso   1.00
Pt4    Pt    0.66667   0.83333   0.26141   1.00000  Uiso   1.00
Pt5    Pt    0.65398   0.82699   0.07264   1.00000  Uiso   1.00
Pt6    Pt   -0.00000   0.50000   0.19903   1.00000  Uiso   1.00
Pt7    Pt    0.00000   0.50000   0.38616   0.00000  Uiso   1.00
Pt8    Pt    0.66667   0.83333   0.44854   0.00000  Uiso   1.00
Pt9    Pt    0.83425   0.16575   0.13761   1.00000  Uiso   1.00
Pt10   Pt    0.66667   0.33333   0.26141   1.00000  Uiso   1.00
Pt11   Pt    0.66667   0.33333   0.07682   1.00000  Uiso   1.00
Pt12   Pt    0.66667   0.33333   0.44854   0.00000  Uiso   1.00
Pt13   Pt    0.33333   0.66667   0.13434   1.00000  Uiso   1.00
Pt14   Pt    0.33333   0.66667   0.32378   0.00000  Uiso   1.00
Pt15   Pt    0.33333   0.66667   0.51091   0.00000  Uiso   1.00
Pt16   Pt    0.33333   0.16667   0.32378   0.00000  Uiso   1.00

rfms converage failed

I am using feff10 to calculate O K-edge XANES for a Pt/O surface system. The SCF radius rfms1 converaged well with 7.0 angstrom. While the FMS radius rfms could't converge with 9.0, 10.0, 11.0 angstrom. I have tried increasing the cluster radius to 27.0 angstrom and increasing FMS radius to 17.0 angstrom but it was useless. I don't know what's wrong. Thanks for any suggestions!
All the related files have been attached for reference. test.zip

feff.inp

( ATOMS card is excluded for clarity.)

*--------------------------------------[structure]
TITLE test

 POTENTIALS
 *   ipot   Z  element        l_scmt  l_fms   stoichiometry
     0     8      O            1       1       0.001
     1     8      O            1       1       1
     2     78     Pt           3       3       20
     3     78     Pt           3       3       3
     4     78     Pt           3       3       3
     5     78     Pt           3       3       1
     6     78     Pt           3       3       1

*--------------------------------------[spectrum]
XANES 6 0.05 0.3

POLARIZATION 0.0 0.0 1.0

EGRID
e_grid -10 20 0.1

COREHOLE RPA
EDGE K

SCF 7.0

FMS 9.0 0 2

ABSOLUTE

test

Script to read ORCA frequencies

Dear Sir,
Starting from the fchk2dym.script I have created a orca2dym.script which uses the output from ORCA 5. Please tell me if you are interested to include it with feff10.

Best regards,
Rafael RP

Testing the compiled code

I am using the runtests.csh script to test the compiled code on our cluster. For some of the tests, I get a rather larger deviation from the reference. Before I dig deeper into the issue, would it be possible to confirm that references are correct? For example in the case of the EXAFS/SF6 example (which has a very large deviation), and I see that there was a commit ba2b82a that changed some of the input parameters.

Below is the summary of running the test:

SUMMARY OF TEST RESULTS:
========================

Test                        Started            Finished  Crash   Avg.Deviation   Max.Deviation
----------------------------------------------------------------------------------------------
COMPTON/Cu/                 11/15/21 10:45:16  10:45:49   No      0.002%          0.00%
DANES/BN/                   11/15/21 10:46:21  10:47:21   No      0.001%          0.02%
DANES/Cu/                   11/15/21 10:47:22  10:47:51   No      0.020%          0.04%
DANES/GeCl_4/               11/15/21 10:47:53  10:48:11   No      0.069%          0.30%
DEBYE/EM/Cu/                11/15/21 10:48:14  10:49:43   No      2.056%         21.50%
DEBYE/EM/Zn_Tetraimidazole/ 11/15/21 10:49:52  10:50:12   No      0.994%          5.07%
DEBYE/RM/Cu/                11/15/21 10:50:19  10:51:45   No      2.180%         21.87%
DEBYE/RM/Zn_Tetraimidazole/ 11/15/21 10:51:55  10:52:11   No      0.590%          5.46%
ELNES/Cu/                   11/15/21 10:52:24  10:54:35   No      0.018%          0.04%
EXAFS/Cu/                   11/15/21 10:54:37  10:54:55   No      0.887%          8.52%
EXAFS/Cu_SCF/               11/15/21 10:55:08  10:55:58   No      0.001%          0.01%
EXAFS/GeCl_4/               11/15/21 10:56:09  10:56:27   No      0.528%          3.26%
EXAFS/SF6/                  11/15/21 10:56:39  10:56:56   No     11.441%        244.89%
EXAFS/YBCO/                 11/15/21 10:57:09  10:57:27   No      0.000%          0.00%
EXELFS/Cu/                  11/15/21 10:57:33  10:59:03   No      0.027%          0.21%
FPRIME/GeCl4/               11/15/21 10:59:10  10:59:29   No      1.846%         17.26%
HUBBARD/CeO2/               11/15/21 10:59:32  12:33:44   No     64.443%       1623.82%
HUBBARD/NiO/                11/15/21 12:33:46  12:34:36   No     29.448%        233.86%
KSPACE/Cr2GeC/              11/15/21 12:34:38  12:44:15   No      6.997%         29.28%
KSPACE/Graphite/            11/15/21 12:44:18  12:48:14   No      1.179%          3.37%
MPSE/Cu/                    11/15/21 12:48:17  12:49:20   No      0.147%          1.34%
MPSE/Cu_OPCONS/             11/15/21 12:49:23  12:52:25   No      0.002%          0.01%
NRIXS/GeCl_4/               11/15/21 12:52:27  12:52:46   No      0.421%          1.33%
NRIXS/MgB2/                 11/15/21 12:52:49  12:53:33   No      1.855%          5.65%
XANES/BN/                   11/15/21 12:53:36  12:54:40   No      0.000%          0.00%
XANES/Cu/                   11/15/21 12:54:42  12:55:10   No      0.120%          1.14%
XANES/GeCl_4/               11/15/21 12:55:13  12:55:31   No      0.184%          0.78%
XES/BN/                     11/15/21 12:55:34  12:56:40   No      0.000%          0.00%
XES/Cu/                     11/15/21 12:56:47  12:57:15   No      0.219%          0.81%
XES/GeCl_4/                 11/15/21 12:57:18  12:57:35   No      0.289%          0.68%
XMCD/Gd_L1/                 11/15/21 12:57:38  12:58:07   No    123.217%        759.12%
XMCD/MnF2_SPXAS/            11/15/21 12:58:10  12:58:30   No   1121.986%      52139.89%
XNCD/LiIO3/                 11/15/21 12:58:33  12:59:13   No      0.000%          0.00%

Negative electronic configuration in scf

I am using feff10.0 to perform O K-edge XANES simulation on a Pt/O surface system.
But after the first SCF cycle, convergence.scf.fine gave me this non-physical negative electron configuration:

 SCF ITERATION NUMBER  1
   Electronic configuration
   type     l     N_el
      0     0    1.455
      0     1    3.711
      0     2   -3.679
      0     3    0.000
      1     0    1.455
...

And the stdout feff.log show:

...
 Found bad counts.
  Occupation number in getorb is     0.000
  Will repeat this iteration
 Found bad counts.
  Occupation number in getorb is     1.000
  Will repeat this iteration
 Found bad counts.
  Occupation number in getorb is     0.000
  Will repeat this iteration
 Found bad counts.
  Occupation number in getorb is     0.000
  Will repeat this iteration
 Found bad counts.
  Occupation number in getorb is     1.000
  Will repeat this iteration
 Found bad counts.
  Occupation number in getorb is     0.000
  Will repeat this iteration
 Found bad counts.
  Occupation number in getorb is     0.000
  Will repeat this iteration
 FRNRM Could not integrate enough charge to reach required z.
 FRNRM-1
...

All the related files have been attached. Is there any suggestions?
test.zip

feff.inp

CIF feff.cif
RECIPROCAL
TARGET 1
TITLE test
XANES 4.0
POLARIZATION 0.0 0.0 1.0
KMESH 100
EGRID
e_grid -10 20 0.1
COREHOLE RPA
EDGE K
SCF 7.0
* EXCHANGE 0 0 0.0
* CHBROADENING 0
CHWIDTH 0.45
FMS 9.0 0 2
* CORRECTIONS 0.0 0.0
ABSOLUTE

Feature Request

I would like to increase the number of energy points calculated in a run. The current number seems to be fixed to 86 points. I have done a quick search of the dimensioning module, but I didn't see any arrays that are of this size that I could modify. Can anyone point out how to increase the number of points calculated (the XANES card just changes the point spacing leaving the total number of points unchanged)? Thanks.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.