shankar1729
commented
6 years ago Default ionic coordinates are fractional, so you need to specify "coords-type cartesian" in your input file.
Best, Shankar
Closed yashpalsingh007 closed 6 years ago
shankar1729
commented
6 years ago Default ionic coordinates are fractional, so you need to specify "coords-type cartesian" in your input file.
Best, Shankar
yashpalsingh007
commented
6 years ago many thanks it worked!
yashpalsingh007
commented
6 years ago thanks for the reply.
I have one more issue: My optimization word very fine and it was quick for my system but now when I include van-der-waals tag in order to include the D2 corrections in the previously optimized structure. It is taking a long time its been more than 48 hrs now. Is there any way to check, whether the calculation (re-optimization using D2) is running fine or not.
Thanks again! Yash
On Fri, May 4, 2018 at 9:24 PM, Ravishankar Sundararaman < notifications@github.com> wrote:
Closed #25 https://github.com/shankar1729/jdftx/issues/25.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/shankar1729/jdftx/issues/25#event-1609710174, or mute the thread https://github.com/notifications/unsubscribe-auth/AXyzlAhAj-l-gEPs63YkEniyx-AErhkrks5tvEhsgaJpZM4TwkWt .
-- Yashpal Singh
Post Doc Researcher, Advanced Material Simulation Group http://qchem.kaist.ac.kr/ Graduate School of EEWS Korean Advanced Institute of Science and Technology Daejeon 305-701 South Korea Email: yashpal@kaist.ac.kr https://sites.google.com/site/yashpalphysics/home
shankar1729
commented
6 years ago You can tail the output file to check progress. Can you post your output file here, perhaps the parallelization strategy may need to be tweaked?
yashpalsingh007
commented
6 years ago The job got over but it took around 60 hrs which is too high as compared to without vdw correction. The output is attached herewith
I will contact you again if i come across other problems. thanks for the quick response. best regards Yashpal
On Fri, May 11, 2018 at 9:25 PM, Ravishankar Sundararaman < notifications@github.com> wrote:
You can tail the output file to check progress. Can you post your output file here, perhaps the parallelization strategy may need to be tweaked?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/shankar1729/jdftx/issues/25#issuecomment-388348857, or mute the thread https://github.com/notifications/unsubscribe-auth/AXyzlCUoxppHlOOIOlXsPH66DXBBmtUVks5txYNUgaJpZM4TwkWt .
-- Yashpal Singh
Post Doc Researcher, Advanced Material Simulation Group http://qchem.kaist.ac.kr/ Graduate School of EEWS Korean Advanced Institute of Science and Technology Daejeon 305-701 South Korea Email: yashpal@kaist.ac.kr https://sites.google.com/site/yashpalphysics/home
yashpalsingh007
commented
6 years ago Hi,
Regarding solvation correction through CANDLE
as i mentioned earlier including van-der-waals took a long time to optimize and the optimization energy which I got is: -414.6529216614947018
In order to verify I considered same structure previously optimized with VASP with D2 and performed a single point calculation using following common.in scrip
include fen4c-ooh.lattice include fen4c-ooh.ionpos coords-type cartesian
spintype z-spin ion-species GBRV/$ID_pbe.uspp elec-ex-corr gga-PBE elec-cutoff 20 100
coulomb-interaction Slab 001 coulomb-truncation-ion-margin 3
van-der-waals
The optimization energy I got is: -414.6496407339589041
which is similar to above. So far so good.. Now I wanna include solvent correction here for which I am using following LinearPCM.in
include common.in dump-name LinearPCM.$VAR dump End State BoundCharge
and in common.in I have
include fen4c-ooh.lattice include fen4c-ooh.ionpos coords-type cartesian
spintype z-spin ion-species GBRV/$ID_pbe.uspp elec-ex-corr gga-PBE elec-cutoff 20 100
coulomb-interaction Slab 001 coulomb-truncation-ion-margin 3 coulomb-truncation-embed 0 0 0
van-der-waals
Now the issue is: Job gets killed with the following message Atom 28 lies within the margin of 5 bohrs from the truncation boundary. Expand unit cell, or if absolutely sure, reduce coulomb-truncation-ion-margin. Failed.
I tried to reduce coulomb-truncation-ion-margin further to 1 but the issue still persists. Since I used similar common.in for optimization, I could not understand the reason of failure.
Is there any mistake in the input?
Thanks sincere regards yash
On Sat, May 12, 2018 at 9:50 PM, Yashpal Singh yashpalsingh007@gmail.com wrote:
The job got over but it took around 60 hrs which is too high as compared to without vdw correction. The output is attached herewith
I will contact you again if i come across other problems. thanks for the quick response. best regards Yashpal
On Fri, May 11, 2018 at 9:25 PM, Ravishankar Sundararaman < notifications@github.com> wrote:
You can tail the output file to check progress. Can you post your output file here, perhaps the parallelization strategy may need to be tweaked?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/shankar1729/jdftx/issues/25#issuecomment-388348857, or mute the thread https://github.com/notifications/unsubscribe-auth/AXyzlCUoxppHlOOIOlXsPH66DXBBmtUVks5txYNUgaJpZM4TwkWt .
-- Yashpal Singh
Post Doc Researcher, Advanced Material Simulation Group http://qchem.kaist.ac.kr/ Graduate School of EEWS Korean Advanced Institute of Science and Technology Daejeon 305-701 South Korea Email: yashpal@kaist.ac.kr https://sites.google.com/site/yashpalphysics/home
-- Yashpal Singh
Post Doc Researcher, Advanced Material Simulation Group http://qchem.kaist.ac.kr/ Graduate School of EEWS Korean Advanced Institute of Science and Technology Daejeon 305-701 South Korea Email: yashpal@kaist.ac.kr https://sites.google.com/site/yashpalphysics/home
shankar1729
commented
6 years ago You probably need to fix the center specification in your coulomb-truncation-embed command. It looks like your atoms are centered at a finite z within the cell, rather than at the origin.
Shankar
yashpalsingh007
commented
6 years ago Hi, My aim is to perform a fixed potential calculation but before that, I have to perform a neutral calculation. While doing neutral calculation my Neutral.out file gives following error.
Bulk fluid is non-neutral with a net charge density of 8.923885e-06 e/bohr^3
But my system is neutral on which i already performed geometry optimization.
include fen4c-ooh.lattice
include Vacuum.ionpos
coords-type cartesian
spintype z-spin
ion-species GBRV/$ID_pbe.uspp
elec-ex-corr gga-PBE
elec-cutoff 20 100
van-der-waals
kpoint-folding 4 4 1
elec-smearing Fermi 0.01
fluid LinearPCM
pcm-variant CANDLE
fluid-solvent H2O
fluid-cation H3O(4H2O)+ 0.1
fluid-anion ClO4- 0.1
dump-name common.$VAR #This will overwrite outputs from successive runs
initial-state common.$VAR #This will initialize from the preceding calculation
Neutral.in
==============
include common.in
Am I doing some mistake in the input files? I am using my optimized ionpos file for my calculation.
Thanks for being supportive.
Sincerely Yash
On Thu, May 17, 2018 at 2:17 AM, Ravishankar Sundararaman < notifications@github.com> wrote:
You probably need to fix the center specification in your coulomb-truncation-embed command. It looks like your atoms are centered at a finite z within the cell, rather than at the origin.
Shankar
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/shankar1729/jdftx/issues/25#issuecomment-389597603, or mute the thread https://github.com/notifications/unsubscribe-auth/AXyzlBYI829K_5HhdFbWedWbpS3tukCEks5tzF80gaJpZM4TwkWt .
-- Yashpal Singh
Post Doc Researcher, Advanced Material Simulation Group http://qchem.kaist.ac.kr/ Graduate School of EEWS Korean Advanced Institute of Science and Technology Daejeon 305-701 South Korea Email: yashpal@kaist.ac.kr https://sites.google.com/site/yashpalphysics/home
shankar1729
commented
6 years ago The identity of the ions does not matter for continuum solvation models: use NaF, the typical non-adsorbing electrolyte in experiment as a reminder of this.
Your error is, i found now, because the hydronium ions have not actually been setup within the code. I have updated the code to raise a not implemented error at the very beginning instead of the cryptic non-neutral error you saw now.
Best, Shankar
yashpalsingh007
commented
6 years ago Thank for the quick response! In my system of interest, experimentally people use 0.1M solution HClO4 or H2SO4 as an electrolyte. That is the reason why I wanted to use those options to create the experimental condition (acidic medium). Does considering NaF computationally mimic my acidic condition requirement? If not, then please suggest some other electrolyte.
Thank for the help!
Sincerely Yash
On Tue, Jul 17, 2018 at 10:51 PM, Ravishankar Sundararaman < notifications@github.com> wrote:
The identity of the ions does not matter for continuum solvation models: use NaF, the typical non-adsorbing electrolyte in experiment as a reminder of this.
Your error is, i found now, because the hydronium ions have not actually been setup within the code. I have updated the code to raise a not implemented error at the very beginning instead of the cryptic non-neutral error you saw now.
Best, Shankar
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/shankar1729/jdftx/issues/25#issuecomment-405589277, or mute the thread https://github.com/notifications/unsubscribe-auth/AXyzlDcAFs1mkAHi9KzH3xn6tD80r0Z7ks5uHevngaJpZM4TwkWt .
-- Yashpal Singh
Post Doc Researcher, Advanced Material Simulation Group http://qchem.kaist.ac.kr/ Graduate School of EEWS Korean Advanced Institute of Science and Technology Daejeon 34141 South Korea Email: yashpal@kaist.ac.kr https://sites.google.com/site/yashpalphysics/home
shankar1729
commented
6 years ago Hi Yash,
Continuum solvation models cannot automatically account for acidity and other specific interactions, only the overall electrostatic environment. If you expect species to protonate because of the acidic environment, you will need to explicitly add a proton and calculate the energetics of doing so. The continuum solvation models will only help you do this easily and efficiently by correctly treating the possibly-charged protonated species etc.
Hence my comment: use any electrolyte in the continuum solvation model: they will give identical results.
Best, Shankar
yashpalsingh007
commented
6 years ago Got it ! Thank you once again!
On Wed, Jul 18, 2018 at 1:35 AM, Ravishankar Sundararaman < notifications@github.com> wrote:
Hi Yash,
Continuum solvation models cannot automatically account for acidity and other specific interactions, only the overall electrostatic environment. If you expect species to protonate because of the acidic environment, you will need to explicitly add a proton and calculate the energetics of doing so. The continuum solvation models will only help you do this easily and efficiently by correctly treating the possibly-charged protonated species etc.
Hence my comment: use any electrolyte in the continuum solvation model: they will give identical results.
Best, Shankar
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/shankar1729/jdftx/issues/25#issuecomment-405646410, or mute the thread https://github.com/notifications/unsubscribe-auth/AXyzlO4OJyzBwIbtYBKRvk6lpPZyCitZks5uHhI6gaJpZM4TwkWt .
-- Yashpal Singh
Post Doc Researcher, Advanced Material Simulation Group http://qchem.kaist.ac.kr/ Graduate School of EEWS Korean Advanced Institute of Science and Technology Daejeon 34141 South Korea Email: yashpal@kaist.ac.kr https://sites.google.com/site/yashpalphysics/home
yashpalsingh007
commented
6 years ago Hi,
Another query in the fixed potential calculation:
The formula for the target mu is given as follows: mu = -(Vref + V)/27.2114,
Now for the e.g. case give on website, we need to run the following script
for iMu in {-10..10}; do export mu="$(echo $iMu | awk '{printf("%.4f", -0.2015+0.1*$1/27.2114)}')" mpirun -n 4 jdftx -i Charged.in | tee Charged$mu.out mv common.nbound Charged$mu.nbound done
-0.2015 is the mu value for the neutral case (0 applied voltage) which we get from Neutral.out
Since the above script varies from -1 to 1 V, my query is does this numerator 0.1*$1 = -(Vref+V) where Vref=-4.66 eV or -4.44 eV ( depending on the choice). If true then we can calculate the value of applied potential V based on the above formula.
Am I looking at it correctly?
thanks Yash
On Wed, Jul 18, 2018 at 1:40 AM, Yashpal Singh yashpalsingh007@gmail.com wrote:
Got it ! Thank you once again!
On Wed, Jul 18, 2018 at 1:35 AM, Ravishankar Sundararaman < notifications@github.com> wrote:
Hi Yash,
Continuum solvation models cannot automatically account for acidity and other specific interactions, only the overall electrostatic environment. If you expect species to protonate because of the acidic environment, you will need to explicitly add a proton and calculate the energetics of doing so. The continuum solvation models will only help you do this easily and efficiently by correctly treating the possibly-charged protonated species etc.
Hence my comment: use any electrolyte in the continuum solvation model: they will give identical results.
Best, Shankar
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/shankar1729/jdftx/issues/25#issuecomment-405646410, or mute the thread https://github.com/notifications/unsubscribe-auth/AXyzlO4OJyzBwIbtYBKRvk6lpPZyCitZks5uHhI6gaJpZM4TwkWt .
-- Yashpal Singh
Post Doc Researcher, Advanced Material Simulation Group http://qchem.kaist.ac.kr/ Graduate School of EEWS Korean Advanced Institute of Science and Technology Daejeon 34141 South Korea Email: yashpal@kaist.ac.kr https://sites.google.com/site/yashpalphysics/home
-- Yashpal Singh
Post Doc Researcher, Advanced Material Simulation Group http://qchem.kaist.ac.kr/ Graduate School of EEWS Korean Advanced Institute of Science and Technology Daejeon 34141 South Korea Email: yashpal@kaist.ac.kr https://sites.google.com/site/yashpalphysics/home
shankar1729
commented
6 years ago Above, 0.1*$1 is the potential in volts relative to the neutral potential.
If you want the applied potential relative to SHE, then you convert the overall mu using mu = -(Vref + V)/27.2114. In that case, do not subtract out the neutral mu value (as written in your formula).
yashpalsingh007
commented
6 years ago I am testing my system for stability against dissolution in a range of 0 to 1.2 V for ORR. In order to do calculations in the above range of fixed potentials, I divided step size a (1.2-0.0)/24 =0.05
0 V = 0.050 and 1.2 V = 0.0524
I have modified the script as follows without considering any reference voltage:
for iMu in {0..24}; do export mu="$(echo $iMu | awk '{printf("%.4f", 0.05*$1/27.2114)}')" mpirun -n 4 jdftx -i Charged.in | tee Charged$mu.out mv common.nbound Charged$mu.nbound done
I hope am not wrong here?
Thanks Regards Yash
On Tue, Jul 24, 2018 at 9:42 PM, Ravishankar Sundararaman < notifications@github.com> wrote:
Above, 0.1*$1 is the potential in volts relative to the neutral potential.
If you want the applied potential relative to SHE, then you convert the overall mu using mu = -(Vref + V)/27.2114. In that case, do not subtract out the neutral mu value (as written in your formula).
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/shankar1729/jdftx/issues/25#issuecomment-407392995, or mute the thread https://github.com/notifications/unsubscribe-auth/AXyzlLGPs7K5dwfrB56GGMp1zl59m94eks5uJxZIgaJpZM4TwkWt .
-- Yashpal Singh
Post Doc Researcher, Advanced Material Simulation Group http://qchem.kaist.ac.kr/ Graduate School of EEWS Korean Advanced Institute of Science and Technology Daejeon 34141 South Korea Email: yashpal@kaist.ac.kr https://sites.google.com/site/yashpalphysics/home
shankar1729
commented
6 years ago That is incorrect: the mu specified to the code is absolute, and your formula must include Vref if you want V to be potential relative to SHE.
yashpalsingh007
commented
6 years ago Hello Sir,
I am now trying to run a simple H2 molecule in a box. The error and input file is the following:
include h2.lattice include h2.ionpos
coords-type cartesian
spintype z-spin ion-species GBRV/$ID_pbe.uspp elec-ex-corr gga-PBE elec-cutoff 20 100
ionic-minimize nIterations 3 \ energyDiffThreshold 1e-6 \ knormThreshold 1e-6
dump-name common.$VAR #This will overwrite outputs from successive runs dump End State
ion H 0.00000 0.00000 0.69660 0 ion H 0.00000 0.00000 -0.69660 1
lattice \ 15 0 0 \ 0 15 0 \ 0 0 16.3932
I tried in many different ways but could not surpass this error. Please help me here.
Thanks Sincerely Yash
On Wed, Jul 25, 2018 at 12:33 AM, Ravishankar Sundararaman < notifications@github.com> wrote:
That is incorrect: the mu specified to the code is absolute, and your formula must include Vref if you want V to be potential relative to SHE.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/shankar1729/jdftx/issues/25#issuecomment-407450098, or mute the thread https://github.com/notifications/unsubscribe-auth/AXyzlJCrgxyE1QKNtNUt-hCksowr26XLks5uJz4tgaJpZM4TwkWt .
-- Yashpal Singh
Post Doc Researcher, Advanced Material Simulation Group http://qchem.kaist.ac.kr/ Graduate School of EEWS Korean Advanced Institute of Science and Technology Daejeon 34141 South Korea Email: yashpal@kaist.ac.kr https://sites.google.com/site/yashpalphysics/home
shankar1729
commented
6 years ago Set the move scale for both atoms to 1
yashpalsingh007
commented
6 years ago the error is resolved b setting move scale 1 for both the atoms in h2.ionpos file but now the error is
Atoms are too close, have overlapping pseudopotential cores.
Failed.
I encountered similar problem earlier also which was resolved by setting
coords-type cartesian
In this case, I don't know what the issue. The distance between H atoms is equal to the bond length of the H2 molecule which is fine. Is the issue related with the pseudopotential of H atom owing to its single electron nature?
Thanks for the patience!
Sincerely Yash
On Wed, Aug 1, 2018 at 8:15 PM, Ravishankar Sundararaman < notifications@github.com> wrote:
Set the move scale for both atoms to 1
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/shankar1729/jdftx/issues/25#issuecomment-409540343, or mute the thread https://github.com/notifications/unsubscribe-auth/AXyzlElhTCAjjvuX98JH0jA2yuoFL5gWks5uMY3HgaJpZM4TwkWt .
-- Yashpal Singh
Post Doc Researcher, Advanced Material Simulation Group http://qchem.kaist.ac.kr/ Graduate School of EEWS Korean Advanced Institute of Science and Technology Daejeon 34141 South Korea Email: yashpal@kaist.ac.kr https://sites.google.com/site/yashpalphysics/home
shankar1729
commented
6 years ago Oh right, H2 is a corner case in the most recent GBRV due to wider nonlocal projectors that overlap at the equilibrium geometry. Disable the check using "core-overlap-check None" to circumvent this issue.
yashpalsingh007
commented
6 years ago it is working now!
thanks again Yash
On Wed, Aug 1, 2018 at 10:17 PM, Ravishankar Sundararaman < notifications@github.com> wrote:
Oh right, H2 is a corner case in the most recent GBRV due to wider nonlocal projectors that overlap at the equilibrium geometry. Disable the check using "core-overlap-check None" to circumvent this issue.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/shankar1729/jdftx/issues/25#issuecomment-409571271, or mute the thread https://github.com/notifications/unsubscribe-auth/AXyzlNft0juH3wAhlyZtZXfnHfTOIkzxks5uMaqGgaJpZM4TwkWt .
-- Yashpal Singh
Post Doc Researcher, Advanced Material Simulation Group http://qchem.kaist.ac.kr/ Graduate School of EEWS Korean Advanced Institute of Science and Technology Daejeon 34141 South Korea Email: yashpal@kaist.ac.kr https://sites.google.com/site/yashpalphysics/home
yashpalsingh007
commented
6 years ago Hi,
There is one more similar issue with bulk Fe-crystal. Its a body centred crystal with two atoms one at the origin and other in the centre of the cube. Now when I use vesta and convert cif file to .xyz file it automatically save other atoms also and after using xyzToionpos we get following two files.
lattice \ 5.42351 0 0 \ 0 5.42351 0 \ 0 0 5.42351
ion Fe 0.000000000000000 0.000000000000000 0.000000000000000 1 ion Fe 0.000000000000000 0.000000000000000 5.423514089420331 1 ion Fe 0.000000000000000 5.423514089420331 0.000000000000000 1 ion Fe 0.000000000000000 5.423514089420331 5.423514089420331 1 ion Fe 5.423514089420331 0.000000000000000 0.000000000000000 1 ion Fe 5.423514089420331 0.000000000000000 5.423514089420331 1 ion Fe 5.423514089420331 5.423514089420331 0.000000000000000 1 ion Fe 5.423514089420331 5.423514089420331 5.423514089420331 1 ion Fe 2.711757044710165 2.711757044710165 2.711757044710165 1
On running following common.in file
include febulk.lattice include febulk.ionpos
coords-type cartesian spintype z-spin ion-species GBRV/$ID_pbe.uspp elec-ex-corr gga-PBE elec-cutoff 20 100
ionic-minimize nIterations 3 \ energyDiffThreshold 1e-6 \ knormThreshold 1e-6 dump-name common.$VAR #This will overwrite outputs from successive runs dump End State
The error is!
WARNING: Fe #0 and Fe #1 are closer than the vector-sum of their core radii. WARNING: Fe #0 and Fe #2 are closer than the vector-sum of their core radii. WARNING: Fe #0 and Fe #3 are closer than the vector-sum of their core radii. WARNING: Fe #0 and Fe #4 are closer than the vector-sum of their core radii. WARNING: Fe #0 and Fe #5 are closer than the vector-sum of their core radii. WARNING: Fe #0 and Fe #6 are closer than the vector-sum of their core radii. WARNING: Fe #0 and Fe #7 are closer than the vector-sum of their core radii. WARNING: Fe #1 and Fe #2 are closer than the vector-sum of their core radii. WARNING: Fe #1 and Fe #3 are closer than the vector-sum of their core radii. WARNING: Fe #1 and Fe #4 are closer than the vector-sum of their core radii. WARNING: Fe #1 and Fe #5 are closer than the vector-sum of their core radii. WARNING: Fe #1 and Fe #6 are closer than the vector-sum of their core radii. WARNING: Fe #1 and Fe #7 are closer than the vector-sum of their core radii. WARNING: Fe #2 and Fe #3 are closer than the vector-sum of their core radii. WARNING: Fe #2 and Fe #4 are closer than the vector-sum of their core radii. WARNING: Fe #2 and Fe #5 are closer than the vector-sum of their core radii. WARNING: Fe #2 and Fe #6 are closer than the vector-sum of their core radii. WARNING: Fe #2 and Fe #7 are closer than the vector-sum of their core radii. WARNING: Fe #3 and Fe #4 are closer than the vector-sum of their core radii. WARNING: Fe #3 and Fe #5 are closer than the vector-sum of their core radii. WARNING: Fe #3 and Fe #6 are closer than the vector-sum of their core radii. WARNING: Fe #3 and Fe #7 are closer than the vector-sum of their core radii. WARNING: Fe #4 and Fe #5 are closer than the vector-sum of their core radii. WARNING: Fe #4 and Fe #6 are closer than the vector-sum of their core radii. WARNING: Fe #4 and Fe #7 are closer than the vector-sum of their core radii. WARNING: Fe #5 and Fe #6 are closer than the vector-sum of their core radii. WARNING: Fe #5 and Fe #7 are closer than the vector-sum of their core radii. WARNING: Fe #6 and Fe #7 are closer than the vector-sum of their core radii.
Atoms are too close, have overlapping pseudopotential cores.
=========================================================== In VASP I start with two atoms only for a periodic calculation. and when i just delete all the atoms except one at origin and other in the centre of the box then calculations runs fine. Could you please clarify whats going on in here.
Thanks Yash
On Thu, Aug 2, 2018 at 12:17 AM, Yashpal Singh yashpalsingh007@gmail.com wrote:
it is working now!
thanks again Yash
On Wed, Aug 1, 2018 at 10:17 PM, Ravishankar Sundararaman < notifications@github.com> wrote:
Oh right, H2 is a corner case in the most recent GBRV due to wider nonlocal projectors that overlap at the equilibrium geometry. Disable the check using "core-overlap-check None" to circumvent this issue.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/shankar1729/jdftx/issues/25#issuecomment-409571271, or mute the thread https://github.com/notifications/unsubscribe-auth/AXyzlNft0juH3wAhlyZtZXfnHfTOIkzxks5uMaqGgaJpZM4TwkWt .
-- Yashpal Singh
Post Doc Researcher, Advanced Material Simulation Group http://qchem.kaist.ac.kr/ Graduate School of EEWS Korean Advanced Institute of Science and Technology Daejeon 34141 South Korea Email: yashpal@kaist.ac.kr https://sites.google.com/site/yashpalphysics/home
-- Yashpal Singh
Post Doc Researcher, Advanced Material Simulation Group http://qchem.kaist.ac.kr/ Graduate School of EEWS Korean Advanced Institute of Science and Technology Daejeon 34141 South Korea Email: yashpal@kaist.ac.kr https://sites.google.com/site/yashpalphysics/home
shankar1729
commented
6 years ago Did you convert lattice constant to bohrs?
yashpalsingh007
commented
6 years ago yes when I use xyzToionpos febulk.xyz > febulk.ionpos I get everything in Bohr right ?
[yash@mu02 rep]$ xyzToIonpos febulk.xyz >febulk.ionpos Offseting atoms by ( 0.000000000000000 0.000000000000000 0.000000000000000 ) bohrs Bounding box x: [ 0.000000000000000 to 5.404616827784719 ] bohrs Bounding box y: [ 0.000000000000000 to 5.404616827784719 ] bohrs Bounding box z: [ 0.000000000000000 to 5.404616827784719 ] bohrs
So I am using similar lattice parameters in febulk.lattice file.
On Mon, Aug 6, 2018 at 1:37 PM, Ravishankar Sundararaman < notifications@github.com> wrote:
Did you convert lattice constant to bohrs?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/shankar1729/jdftx/issues/25#issuecomment-410586673, or mute the thread https://github.com/notifications/unsubscribe-auth/AXyzlMEzSp7_6ApNruk3mcWMSdpRdUvvks5uN8gmgaJpZM4TwkWt .
-- Yashpal Singh
Post Doc Researcher, Advanced Material Simulation Group http://qchem.kaist.ac.kr/ Graduate School of EEWS Korean Advanced Institute of Science and Technology Daejeon 34141 South Korea Email: yashpal@kaist.ac.kr https://sites.google.com/site/yashpalphysics/home
yashpalsingh007
commented
6 years ago I think I got the issue, we have to be careful in using xyzToionpos because the bounding box values x,y,z only give the box size based on the coordinates of atoms. We should only use two atoms instead of 9 atoms as given in .cif file.
On Mon, Aug 6, 2018 at 1:45 PM, Yashpal Singh yashpalsingh007@gmail.com wrote:
yes when I use xyzToionpos febulk.xyz > febulk.ionpos I get everything in Bohr right ?
[yash@mu02 rep]$ xyzToIonpos febulk.xyz >febulk.ionpos Offseting atoms by ( 0.000000000000000 0.000000000000000 0.000000000000000 ) bohrs Bounding box x: [ 0.000000000000000 to 5.404616827784719 ] bohrs Bounding box y: [ 0.000000000000000 to 5.404616827784719 ] bohrs Bounding box z: [ 0.000000000000000 to 5.404616827784719 ] bohrs
So I am using similar lattice parameters in febulk.lattice file.
On Mon, Aug 6, 2018 at 1:37 PM, Ravishankar Sundararaman < notifications@github.com> wrote:
Did you convert lattice constant to bohrs?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/shankar1729/jdftx/issues/25#issuecomment-410586673, or mute the thread https://github.com/notifications/unsubscribe-auth/AXyzlMEzSp7_6ApNruk3mcWMSdpRdUvvks5uN8gmgaJpZM4TwkWt .
-- Yashpal Singh
Post Doc Researcher, Advanced Material Simulation Group http://qchem.kaist.ac.kr/ Graduate School of EEWS Korean Advanced Institute of Science and Technology Daejeon 34141 South Korea Email: yashpal@kaist.ac.kr https://sites.google.com/site/yashpalphysics/home
-- Yashpal Singh
Post Doc Researcher, Advanced Material Simulation Group http://qchem.kaist.ac.kr/ Graduate School of EEWS Korean Advanced Institute of Science and Technology Daejeon 34141 South Korea Email: yashpal@kaist.ac.kr https://sites.google.com/site/yashpalphysics/home
shankar1729
commented
6 years ago Yes, that's right. XyzToIonpos* scripts are for molecules, not solids. There's no automatic way to figure out lattice vectors from the atom coordinates in an xyz file alone.
yashpalsingh007
commented
6 years ago Hi, I have a issue which I would like to bring to your notice.
I calculated free energy change for a reaction Fe-N4C +2(H+e) —> 2H-N4C + Fe
For systems Fe-N4C and 2H-N4C (carbon based nanomaterials) I calculated grand free energies at 0 V to 1.2 V as we discussed earlier. For H+e =0.5* H2 and for Fe = Bulk Fe/no. of atoms.
I used VASP for that considering it at 0V and got a change of -0.9 eV Using JDFTx (only at 0V) the value of -2.4 eV.
Now the reason behind this dfference which I am expecting is: For Fe bulk and H2 calculations I never performed fixed potential calculations and most probably the algorithm which is used for the minimization (grand free energy) during fixed potential calculation is different that the normal minimization.
I would like to know your thoughts here.
Thanks Yash
On Mon, Aug 6, 2018 at 8:51 PM, Ravishankar Sundararaman < notifications@github.com> wrote:
Yes, that's right. XyzToIonpos* scripts are for molecules, not solids. There's no automatic way to figure out lattice vectors from the atom coordinates in an xyz file alone.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/shankar1729/jdftx/issues/25#issuecomment-410682540, or mute the thread https://github.com/notifications/unsubscribe-auth/AXyzlHXy7prDdj1IE2qPtbCENoZI-8IDks5uOC25gaJpZM4TwkWt .
-- Yashpal Singh
Post Doc Researcher, Advanced Material Simulation Group http://qchem.kaist.ac.kr/ Graduate School of EEWS Korean Advanced Institute of Science and Technology Daejeon 34141 South Korea Email: yashpal@kaist.ac.kr https://sites.google.com/site/yashpalphysics/home
shankar1729
commented
6 years ago Did you add a mu*N term for Fe and H energies to make them Grand canonical? You don't need to do a fixed potential calculation, but you do have to put all terms on same mu. For the fixed electron calcs, you set N to the fixed value, but put the mu same as the fixed potential calculations.
yashpalsingh007
commented
6 years ago Hello Sir,
Its been a while as I was occupied with some other works. In order to test the fixed potential calculation, I took the example structure of Pt(111) with common.in as lattice Hexagonal 5.23966 36 ion Pt 0.333333 -0.333333 -0.237676 1 ion Pt -0.333333 0.333333 -0.118838 1 ion Pt 0.000000 0.000000 0.000000 1 ion Pt 0.333333 -0.333333 0.118838 1 ion Pt -0.333333 0.333333 0.237676 1
spintype z-spin ion-species GBRV/$ID_pbe.uspp elec-ex-corr gga-PBE elec-cutoff 20 100 van-der-waals
kpoint-folding 8 8 1 elec-smearing Fermi 0.01 fluid LinearPCM pcm-variant CANDLE fluid-solvent H2O fluid-cation Na+ 0.1 fluid-anion F- 0.1
dump-name common.$VAR #This will overwrite outputs from successive runs initial-state common.$VAR dump End State BoundCharge
and,
Now when I perform a similar calculation for Fe bulk with common.in
include febulk.lattice include febulk.ionpos coords-type cartesian spintype z-spin ion-species GBRV/$ID_pbe.uspp elec-ex-corr gga-PBE elec-cutoff 20 100
van-der-waals
kpoint-folding 4 4 4 elec-smearing Fermi 0.01 fluid LinearPCM pcm-variant CANDLE fluid-solvent H2O fluid-cation Na+ 0.1 fluid-anion F- 0.1
dump-name common.$VAR #This will overwrite outputs from successive runs initial-state common.$VAR dump End State BoundCharge
I get convergence error with last few lines in Charged.out file as
From your last reply: " For the fixed electron calcs, you set N to the fixed value, but put the mu same as the fixed potential calculations." I didn't follow the above statement.
Kindly help me here. Sorry for the delay.
Yours Sincerely, Yash
On Tue, Aug 14, 2018 at 8:57 PM Ravishankar Sundararaman < notifications@github.com> wrote:
Did you add a mu*N term for Fe and H energies to make them Grand canonical? You don't need to do a fixed potential calculation, but you do have to put all terms on same mu. For the fixed electron calcs, you set N to the fixed value, but put the mu same as the fixed potential calculations.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/shankar1729/jdftx/issues/25#issuecomment-412847449, or mute the thread https://github.com/notifications/unsubscribe-auth/AXyzlHyIE9s8Wfbf4lCDT9Dzew-zN31mks5uQrsrgaJpZM4TwkWt .
-- Yashpal Singh
Post Doc Researcher, Advanced Material Simulation Group http://qchem.kaist.ac.kr/ Graduate School of EEWS Korean Advanced Institute of Science and Technology Daejeon 34141 South Korea Email: yashpal@kaist.ac.kr https://sites.google.com/site/yashpalphysics/home
shankar1729
commented
6 years ago Hi Yash,
You can't do fixed potential calculations in bulk: there is no room for the liquid / counter charge. You need a surface for these.
Best, Shankar
yashpalsingh007
commented
6 years ago Oh, I didn't realize that. My aim is to calculate the reaction free energy of a reaction that requires the chemical potential of Fe as an input (wanted to compare it with the vasp result). Since I want to calculate the chemical potential for Fe which I generally calculate bulk energy per atom. The reason behind using grand canonical energy is to keep it on equal footing with all the other fixed potential calculations.
Now in the current scenario what I understand is best for me is to calculate the energy of a single Fe atom in a box.
What do you think? Thanks for the quick response.
Sincere regards Yash
On Tue, Oct 30, 2018 at 7:15 PM Ravishankar Sundararaman < notifications@github.com> wrote:
Hi Yash,
You can't do fixed potential calculations in bulk: there is no room for the liquid / counter charge. You need a surface for these.
Best, Shankar
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/shankar1729/jdftx/issues/25#issuecomment-434243926, or mute the thread https://github.com/notifications/unsubscribe-auth/AXyzlCnxJSptTvneVMMEh1LDLq0Wy-Kwks5uqCaxgaJpZM4TwkWt .
-- Yashpal Singh
Post Doc Researcher, Advanced Material Simulation Group http://qchem.kaist.ac.kr/ Graduate School of EEWS Korean Advanced Institute of Science and Technology Daejeon 34141 South Korea Email: yashpal@kaist.ac.kr https://sites.google.com/site/yashpalphysics/home
shankar1729
commented
6 years ago For the bulk reference, calculate G = F - mu N at the mu of the reaction you are calculating , but using helmholtz free energy F and electron number N of neutral bulk calculation (no solvent or charge).
See the grand canonical DFT JCP final section for an example of this for the UPD process.
Best, Shankar
potti-charles
commented
10 months ago Hello Sir,
I am calculating a model of CO2 adsorption on graphene with defects at fixed potential. I got an convergence issue of "roundoff error limit". Here is my last line of convergence error.
ElecMinimize: Iter: 41 G: -540.716639360690920 |grad|_K: 1.370e-07 alpha: 0.000e+00
Linear fluid (dielectric constant: 78.4, screening length: 5.74355 Bohr) occupying 0.862331 of unit cell: Completed after 0 iterations at t[s]: 19709.40 ElecMinimize: Predicted alpha/alphaT>3.000000, increasing alphaT to 2.080951e-01. Linear fluid (dielectric constant: 78.4, screening length: 5.74355 Bohr) occupying 0.862330 of unit cell: Com pleted after 3 iterations at t[s]: 19794.32 Linear fluid (dielectric constant: 78.4, screening length: 5.74355 Bohr) occupying 0.862332 of unit cell: Com pleted after 0 iterations at t[s]: 19871.65 ElecMinimize: Step increased G by 5.636912e-08, reducing alpha to 6.420471e-03. Linear fluid (dielectric constant: 78.4, screening length: 5.74355 Bohr) occupying 0.862332 of unit cell: Com pleted after 0 iterations at t[s]: 19997.97 ElecMinimize: Step increased G by 2.093964e-08, reducing alpha to 6.420471e-04. Linear fluid (dielectric constant: 78.4, screening length: 5.74355 Bohr) occupying 0.862332 of unit cell: Com pleted after 0 iterations at t[s]: 20124.54 ElecMinimize: Step increased G by 1.754472e-08, reducing alpha to 6.420471e-05. ElecMinimize: Step failed to reduce G after 3 attempts. Quitting step. ElecMinimize: Undoing step. Linear fluid (dielectric constant: 78.4, screening length: 5.74355 Bohr) occupying 0.862332 of unit cell: Com pleted after 0 iterations at t[s]: 20251.13 ElecMinimize: Step failed along negative gradient direction. ElecMinimize: Probably at roundoff error limit. (Stopping) Setting wave functions to eigenvectors of Hamiltonian Single-point solvation energy estimate, DeltaG = -0.044496259017592
Here is my input files:
"common.in"
ion-species GBRV/$ID_pbesol.uspp elec-ex-corr gga-PBEsol elec-cutoff 20 100 core-overlap-check None
coulomb-interaction Slab 001 coulomb-truncation-embed 0 0 0 coulomb-truncation-ion-margin 5
kpoint-folding 1 1 1 elec-smearing Fermi 0.01
fluid LinearPCM pcm-variant CANDLE fluid-solvent H2O fluid-cation Na+ 1. fluid-anion F- 1.
dump-name common.$VAR #This will overwrite outputs from successive runs initial-state common.$VAR #This will initialize from the preceding calculation dump End State BoundCharge
"Charged.in"
include common.in electronic-minimize nIterations 200 target-mu ${mu}
I would like to know your thoughts here.
Thanks very much.
Tianfu
shankar1729
commented
10 months ago Hi Tianfu,
From a quick look, your calculation seems adequately converged. The issue here is that there is an inner fluid minimization with a specified convergence threshold, and an outer electronic minimization. In order for the outer optimization algorithm to detect smooth convergence, the inner algorithm needs to be converged at each step to a greater level of accuracy. In your example, you have reached a position where the fluid minimization is converging in 0 steps each time, meaning that the difference in fluid state between electronic configurations is negligible to the specified accuracy of your fluid minimize.
In short, this is fine. If you want to get rid of this situation, you can increase the level of convergence of the fluid by adding command fluid-minimize knormThreshold 3e-12 (the default amounted to 1e-11).
Best, Shankar
I took optimized Graphene structure from VASP. In order to use JDFT for optimization, I just followed the tutorial given in http://jdftx.org/Pt100.html my .lattice file contains parameters converted in Bohr from VASP. and I also have .ionpos generated from the xyzToionpos script. Now having said that, when I proceed with dryrun as instructed in the above link. I get the above error.
fen4c-ooh.lattice lattice \ 18.881480721 0.0000000000000000 0.0000000000000000 \ 0.0000000000000000 15.841132463 0.0000000000000000 \ 0.0000000000000000 0.0000000000000000 28.292656874
fen4c-ooh.ionpos
Ionic positions in cartesian coordinates:
ion C 15.176443731891698 1.175948245691613 4.427212661467652 0 ion C 17.561255473591832 2.445001409735718 4.406289613384703 1 ion C 17.594061119791252 5.103655259523653 4.384015411094809 1 ion C 15.279248614641750 6.406205709543041 4.399076528618391 1 ion C 15.283113104646231 9.093611742909559 4.401960250743985 1 ion C 17.597390817291448 10.393219889292283 4.377633805840463 1 ion C 17.564923432075304 13.053217334382509 4.401480260298441 1 ion C 15.179214070447479 14.323975031426146 4.424395079757783 1 ion C 10.480927749721644 1.226150710952777 4.568685120976490 1 ion C 12.857005177093797 2.586275447997382 4.497257251446207 1 ion C 12.862600656264101 12.913196184567287 4.492323176433150 1 ion C 10.481453093595114 14.271831817395006 4.553510619883093 1 ion C 5.783327399593180 1.176530281349990 4.493976686826265 1 ion C 8.101567868003384 2.589899942779092 4.576561499626212 1 ion C 5.682338543686312 6.403053646302221 4.503081387482303 1 ion C 5.680231499013941 9.088246810331208 4.474474712818314 1 ion C 8.104551745615646 12.912729422204889 4.530299113416073 1 ion C 5.784519816802387 14.323107647117073 4.474913129288261 1 ion C 1.039150968711426 1.151345900768211 4.425608283954789 1 ion C 3.396387826232876 2.443937493905633 4.454647705910232 1 ion C 3.367412654966994 5.103887695841771 4.436428855967339 1 ion C 1.041246675026815 6.423154663504021 4.388250287427350 1 ion C 1.041019907887188 9.071290297465575 4.383590222708007 1 ion C 3.368140199539965 10.391507797388096 4.417096957314110 1 ion C 3.399460520974827 13.051318159588131 4.432420746774427 1 ion C 1.040596609226550 14.344915087044566 4.419117074582957 1 ion Fe 10.490928180579209 7.764949056762084 5.065448775948775 1 ion H 9.630265627468454 5.885828036430897 11.129803022503614 1 ion H 6.535170071575268 12.570928981823103 11.760999907025472 1 ion H 8.279982584283678 10.166919512027350 11.620597032525211 1 ion H 13.056911749032270 4.949034085368758 12.646073942717109 1 ion H 11.627725079614162 2.293186478933711 12.547825189747405 1 ion H 10.687794183120513 13.794581474787652 12.309746149304997 1 ion H 13.188657787977260 14.331518818271082 13.771931216991208 1 ion H 16.648050974229424 8.372102955304953 10.881848273130437 1 ion H 13.753487489634852 8.125554162197465 10.268392137832091 1 ion N 12.978522128315429 5.210315183647368 4.475939250595075 1 ion N 12.986712201508304 10.296001037081718 4.495034933477860 1 ion N 7.983136839606846 5.210848086425492 4.627064431347383 1 ion N 7.978187646784479 10.286291624053343 4.538526981132218 1 ion O 8.756133106263837 7.282634248036385 10.067533143907182 1 ion O 10.891550127254160 7.984714760953421 8.433116543947850 1 ion O 8.091648695370852 11.862574578043045 12.422800906766202 1 ion O 11.383357030499424 4.152289630014294 12.771394912705990 1 ion O 12.206795757640352 14.921030233350946 12.335155407300240 1 ion O 15.053373425763619 7.777298417240954 11.565048531947332 1