I am trying to access charge density files in order to estimate bader partial charges using this program. I can access the chgcar files for each mp-id using the API here, but these only include the valence electron density, whereas the bader analysis requires the total electron densities. It seems as though the core electron densities were calculated (the inputs have LAECHG=TRUE, at least for the mp-149 example) - have these been stored in an accessible way, or is there a simple way to recreate them?
Additionally, is there an easy way to search for tasks/material ids which have the chgcar data available? I haven’t been able to find one with my tinkering.
we also provide the parsed AECCARs and CHGCARs through our AWS OpenData repositories. You can use the AWS CLI (in conjunction with gnu parallel if needed) to download them for a bader analysis. I’m working on making sure that the set of AECCARs is complete but you should be able to get started.
@Aaron_Kaplan is also working on potentially providing pre-computed Bader results through MPContribs in the future since it’s often requested by the community.
You should be able to use HasProps.charge_density in your search. See this example.
Thanks! I’ve gone through the available AECCARs on AWS, and it seems as though they are not complete (aka there are quite a few tasks, including all tasks from the MPtrj subset, that are not available). I’ve been able to set up scripts to download the available AECCARs and compute bader charges from them in the meantime, but I’d appreciate it greatly if those tasks from MPtrj would be made available in the near future. What’s the best way to receive notifications on the progress of this and/or the MPContribs Bader partial charges you mentioned?
I also noticed that in order to convert the resulting Bader charges to true partial atomic charges, I need to subtract out the number of valence electrons for each atom in the PAW calculation. There was some prior discussion to this that I found (Finding electron count of MP_API CHGCAR), but has there since been introduced an easier way to get these values?
@jlw2245 I just finished sync’ing all AECCAR0/1/2s we have (~138k each). Could you check whether that includes the ones you’re looking for? This thread is probably the best way to receive notifications on related progress. We sometimes also put notifications on our website (bell in upper right corner) for the benefit of the entire community.
@Aaron_Kaplan might have some insights on your second question.
Thanks! That makes sense. We likely parsed most of the CHGCARs but didn’t parse the AECCARs at the time. This is unfortunately not something we can tackle right now.
@jlw2245 regarding the pseudopotential / charge density issue: AECCAR0 is an approximation of the core charge density, so you have to run a bader charge analysis on the grid-wise sum of the AECCAR0 and AECCAR2 files (AECCAR2 contains the valence charge density, and is identical to CHGCAR up to the grid used, which is the same density or higher than that in CHGCAR).
The same logic applies to any other charge-partitioning scheme (like DDEC). You will get very incorrect oxidation states if you neglect the core charge density. Simply subtracting the number of pseudo-core electrons based on the pseudopotential valence isn’t the right approach, since these schemes usually rely on the topology of the full charge density.
@Aaron_Kaplan Thanks for your input! I’ve been using this codebase to calculate bader charges, which as far as I understand uses the sum of valence and core densities to determine the topological partitioning (via defining -ref) while actually computing partial charges only using the valence densities in AECCAR2/CHGCAR. Since the partial charges obtained in this workflow are valence sums, I still need to know the number of core electrons in the pseudopotential.
I believe this is because the core charge densities in VASP are very sensitive to the cutoffs/grids used, resulting in total charge densities (if you sum partial charges using the core + valence density) that don’t match the total electronic charge of the system. In the example I was looking at from the AWS server, the mismatch was on the order of 6 electronic charges. I tested this before @tschaume verified that all of the AECCARs were synced though so it’s perhaps worth testing again
If I’m incorrect about any of this, or if you know a workaround, please let me know!