Cannot determine Norman radius (could not integrate enough charge)

[realitychemist]

I'm trying to run some ELNES simulations using relaxed SQS supercells, but am running into some unexpected errors when generating the potentials. Here's the text that's printed to stdout when the error occurs; looks like it almost found enough charge, but I'm uncertain about that radius (seems like it's in $a_0$ units, in which case it's way too large):

Calculating atomic potentials ...
overlapped atomic potential and density for unique potential 0
FRNRM Could not integrate enough charge to reach required z.
Atom type Z= 7 charge found= 6.9999998940294272 r= 40.447304179253848
Cannot determine Norman radius -- quitting.
FRNRM-1
...

And here's the associated stderr output:

Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG IEEE_DENORMAL
Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG IEEE_DENORMAL
STOP
At line 107 of file rdpot.f90 (unit = 3)
Fortran runtime error: Cannot open file 'pot.bin': No such file or directory
...

And that's followed by a failed backtrace. That error printed to stdout seems to be raised at this line, but I'm not fluent in Fortran nor familiar enough with the code to fully understand how that section of code works.

I've run successful simulations using the same settings for perfect crystals (i.e. not SQS supercells). I've tried messing around with a variety of settings, but this error seems to happen at the very beginning of the process, before anything I've got control over with cards (or if it is something I have control over, I don't know what cards to use).

Here's the contents of the feff.inp file I am using (same as the successful runs, excepting .cif location, target, and ELNES orientation):

TITLE AlGdN

EDGE K  
CONTROL 1 0 0 0 0 0

PRINT 0 0 0 0 0 0

COREHOLE RPA
CIF E:\Users\...\CONTCAR_x0p083.cif

TARGET 74

EXCHANGE 0 0 0 0 
FMS 8 0     
EQUIVALENCE 2

EGRID
e_grid  0  35.0  0.1


SCF 5 0 100 0.2 1 
ELNES 4 0.07 0
200 0 1 1
1 -1 -2
10 1
50 1
0 0

END

And in case it's useful, here's the final electronic configuration from the last successful simulation I had with the non-SQS cell:

Electronic configuration
  type     l     N_el
     0     0    1.654
     0     1    3.709
     0     2    0.026
     0     3    0.000
     1     0    0.768
     1     1    1.209
     1     2    0.631
     1     3    0.000
     2     0    1.654
     2     1    3.709
     2     2    0.026
     2     3    0.000

I'm also willing to share one of the SQS .cif files in question if you'd like it to help reproduce this.

I don't actually know if this is a FEFF bug, or if there're some settings I've got messed up, or if I'm trying to do something that's just fundamentally not going to work. I am happy to help troubleshoot further, and can share any information that would be useful to that end! In the meantime, I'm also curious if there are any workarounds to get these simulations running.

[realitychemist]

After working on this more for today, I've found that if I use the POTENTIALS and ATOMS cards instead of the CIF and TARGET cards (but with the same data) the simulation runs and gives reasonable-looking results (similar to what I've seen in experiments). It's a bit of a pain since I need to convert atomic positions from the .cif file to the ATOMS format, but not too bad with a python script, so for now this works as a reasonable workaround for me.

Out of curiosity I also tested some non-relaxed SQS supercells and those seemed to run without issue; their output looks a little weird but that's not too surprising since they're quite unphysical structures when not relaxed. The non-relaxed .cif files are formatted slightly differently and need a bit of manual editing (some of the lines are too long for FEFF), but they work. It's not the .cif file formatting causing the original issue, though: I have a regular unit cell (not a supercell) that has the same file formatting as the relaxed SQS cells that cause the problem, but those non-relaxed cells run with no issue and their output looks as expected from literature and experiment.

Since I've got a workaround now I'm probably going to stop trying to troubleshoot this myself, but I'm still happy to give feedback / share files / etc to help with troubleshooting if anyone decides they want to look into this.

[jjkas]

Glad you figured out a workaround. I would love to have an input and cif file if possible. As for getting a real-space input file from cif, you can use webatoms to do this as well. https://millenia.cars.aps.anl.gov/webatoms/

…

On Mon, Jan 20, 2025 at 7:37 PM Charles Evans ***@***.***> wrote: After working on this more for today, I've found that if I use the POTENTIALS and ATOMS cards instead of the CIF and TARGET cards (but with the same data) the simulation runs and gives reasonable-looking results (similar to what I've seen in experiments). It's a bit of a pain since I need to convert atomic positions from the .cif file to the ATOMS format, but not too bad with a python script, so for now this works as a reasonable workaround for me. Out of curiosity I also tested some non-relaxed SQS supercells and those seemed to run without issue; their output looks a little weird but that's not too surprising since they're quite unphysical structures when not relaxed. The non-relaxed .cif files are formatted slightly differently and need a bit of manual editing (some of the lines are too long for FEFF), but they work. It's not the .cif file formatting causing the original issue, though: I have a regular unit cell (not a supercell) that has the same file formatting as the relaxed SQS cells that cause the problem, but those non-relaxed cells run with no issue and their output looks as expected from literature and experiment. Since I've got a workaround now I'm probably going to stop trying to troubleshoot this myself, but I'm still happy to give feedback / share files / etc to help with troubleshooting if anyone decides they want to look into this. — Reply to this email directly, view it on GitHub <https://urldefense.com/v3/__https://github.com/times-software/feff10/issues/28*issuecomment-2603592223__;Iw!!K-Hz7m0Vt54!hx_qoIucH2ID1nMfSvFoH53WZLFbL53wvO3f4RUUyU2q4zUEEdAaifFn51FbSK5sYtj_Nzb1JFHq1eqpYQM1hQ$>, or unsubscribe <https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AA2RF22NTRDUJRCQDMLW2KT2LW6IXAVCNFSM6AAAAABVM4H6XSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMBTGU4TEMRSGM__;!!K-Hz7m0Vt54!hx_qoIucH2ID1nMfSvFoH53WZLFbL53wvO3f4RUUyU2q4zUEEdAaifFn51FbSK5sYtj_Nzb1JFHq1eqV79qy8Q$> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- Joshua Kas (He/Him/His) Research Assistant Professor University of Washington

[realitychemist]

Here's a zip file with a bunch of stuff in it: test.zip

It contains:

• A feff.inp file with the settings I've been using, which seem to reproduce the experimental AlN N-K edge well.
• Two .cif files: the one that ends in 000 is AlN, and runs with no issue. The one that ends in 083 is a supercell based on AlN with a small amount of Gd, and that one fails with the error described.
• All of the files generated by FEFF during a failed run.

[realitychemist]

I found a new .cif file that fails. This time it's an unrelaxed SQS supercell very similar to others I have which run without issue.

I've included the new offending .cif file here (along with a feff.inp file), along with an extremely similar file which works fine. The main difference I can personally see is that the one that works is sized 3x3x3 unit cells (108 atoms in the supercell) whereas the one that does not work is sized 4x3x2 unit cells (96 atoms in the supercell). Both were generated and exported to .cif using using sqsgen), and I did a small amount of hand editing on both to get FEFF to load them at all (e.g. the direct output from sqsgen results in many lines which are longer than FEFF's line length limit).

Here're the new files: test2.zip