ddec-news Mailing List for Program Computing DDEC Atomic Charges
Brought to you by:
thomasamanz
Menu
▾
▴
ddec-news — receive alerts when new versions of the chargemol program are released
You can subscribe to this list here.
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2016 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
(2) |
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(5) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(4) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2023 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Emre G. <ae...@gm...> - 2023-06-21 18:20:49
|
As far as I know, there is a python module which enables to obtain DDEC6 charges from gaussian type cube files. At first, you have to convert Castep electron density into cube format. Best regards Emre On Wed, 21 Jun 2023, 12:22 Fabio Biffoli, <fab...@un...> wrote: > It is possible to obtain DDEC6 with CASTEP calculations? > _______________________________________________ > DDEC-news mailing list > DDE...@li... > https://lists.sourceforge.net/lists/listinfo/ddec-news > |
|
From: Fabio B. <fab...@un...> - 2023-06-21 09:22:00
|
It is possible to obtain DDEC6 with CASTEP calculations? |
|
From: Morteza C. <mor...@gm...> - 2023-01-25 22:10:53
|
Hello Just wondering how I can computer ddec charges using the quantum espresso output files? Thanks Sincerely, Morteza |
|
From: Mario S. <san...@gm...> - 2022-08-29 11:40:55
|
Hello Arka Prava Sarka,
Did you specified the amount of extra
charge + or - you have in your system? in the "job_control" file, you can
do it by setting:
<net charge>
0.0
</net charge>
If you already did it, and for my experience, sometimes the accuracy of the
system could make a small difference that you will have to adjust by
running more accurately (or double checking the system had electronically
converged, ie. running a properly SCf) or just looking at the number of
total electrons that charge mole identified (at the end of its report file)
and subtracting by the total number of electrons you system have when no
extra charge is added. Then, you can use this amount to set up your
"job_control" file.
Goog look!
Best,
Mario G Sandoval
El lun, 29 ago 2022 a la(s) 02:09, Arka Prava Sarkar (
sar...@gm...) escribió:
> Dear All,
> I am trying to calculate the DDEC6 charges for a charged metal
> surface-cation system (+1 charge). The valence density cube file is
> generated using CP2K. The ddec output file shows the error
> "The electrons are not properly accounted for. Either the grid in your
> electron density input file is too coarse, you have specified the incorrect
> net charge in the chargemol_job.m file, or the number of core electrons for
> each atom has not been setup correctly."
>
> My system consists of a Platinum surface with an imidazolium cation. I am
> considering the core electrons of Platinum as 28, Carbon and Nitrogen as 2
> and Hydrogen as 0. Kindly help me in this regard.
>
> --
>
> *Thanks and Regards,*
>
> *অর্ক প্রভ সরকার*
> *Arka Prava Sarkar*
> *বৃত্তিজীবী বাচস্পত্যাধয়নকারী*
> *Research Scholar (Ph.D.), *
>
> *গণনা এবং তথ্য বিজ্ঞান কেন্দ্র *
> *Centre for Computational and Data Sciences (CCDS)*
>
> *ভারতীয় প্রযুক্তি প্রতিষ্ঠান, খড়গপুর*
> *Indian Institute of Technology, Kharagpur*
>
> *পশ্চিমবঙ্গ - ৭২১৩০২ *
> *West Bengal-721302*
> *email1 : sar...@gm... <sar...@gm...>*
> *email2 : ark...@ii... <ark...@ii...>*
> <http://www.linkedin.com/in/quantum-arka-phys-497052>
> _______________________________________________
> DDEC-news mailing list
> DDE...@li...
> https://lists.sourceforge.net/lists/listinfo/ddec-news
>
--
Sandoval, Mario Germán
|
|
From: Arka P. S. <sar...@gm...> - 2022-08-29 05:09:19
|
Dear All, I am trying to calculate the DDEC6 charges for a charged metal surface-cation system (+1 charge). The valence density cube file is generated using CP2K. The ddec output file shows the error "The electrons are not properly accounted for. Either the grid in your electron density input file is too coarse, you have specified the incorrect net charge in the chargemol_job.m file, or the number of core electrons for each atom has not been setup correctly." My system consists of a Platinum surface with an imidazolium cation. I am considering the core electrons of Platinum as 28, Carbon and Nitrogen as 2 and Hydrogen as 0. Kindly help me in this regard. -- *Thanks and Regards,* *অর্ক প্রভ সরকার* *Arka Prava Sarkar* *বৃত্তিজীবী বাচস্পত্যাধয়নকারী* *Research Scholar (Ph.D.), * *গণনা এবং তথ্য বিজ্ঞান কেন্দ্র * *Centre for Computational and Data Sciences (CCDS)* *ভারতীয় প্রযুক্তি প্রতিষ্ঠান, খড়গপুর* *Indian Institute of Technology, Kharagpur* *পশ্চিমবঙ্গ - ৭২১৩০২ * *West Bengal-721302* *email1 : sar...@gm... <sar...@gm...>* *email2 : ark...@ii... <ark...@ii...>* <http://www.linkedin.com/in/quantum-arka-phys-497052> |
|
From: Leopold T. <leo...@ep...> - 2020-11-30 14:45:50
|
Dear Tom, we've been using chargemol in our research group since some time, and we have a minor issue with the current input file format that requires the absolute path to the atomic densities directory - this makes the input files inherently not portable between different machines and complicates the use of chargemol as part of continuous integration tests. Since adding an option to read from a relative path as well would seem like such a small change, I was wondering whether there currently is a way of contributing to the chargemol source code. Have you considered setting up a repository on Github to make it easy for others to contribute back changes and improvements? To some degree this seems to have already started, e.g. I noticed this repository [1] which added support for making chargemol via cmake, but chargemol is currently not accompanied by a license, which leaves it unclear to which degree this approach is tolerated / wanted from your side. Happy to discuss in more detail in private as well, Best wishes, Leopold [1] https://github.com/berquist/chargemol |
|
From: Srinidhi M. <S....@tu...> - 2020-05-31 13:10:26
|
Hello, Crystal17 gives gaussian cube files for total density of primitive cell in e/Bohr3. So, I tried to make the job control file same as examples given in documentation for GPAW calculations. But I keep getting the following error: “checkme = 4.9926E+01 The electrons are not properly accounted for. Either the grid in your electron density input file is too coarse, you have specified the incorrect net charge in the chargemol_job.m file, or the number of core electrons for each atom has not been setup correctly. Program will terminate” The checkme is also quite high . I tried changing the grid and make it finer, but it gives the same error. Below is my job _control file: <net charge> 0.0 </net charge> <periodicity along A, B, and C vectors> .true. .true. .true. </periodicity along A, B, and C vectors> <atomic densities directory complete path> /home/smula/bin/chargemol_09_26_2017/atomic_densities/ </atomic densities directory complete path> <charge type> DDEC6 </charge type> It would be great if anybody could help me solve this problem. I am attaching and output file. Srinidhi From: Thomas Manz <tho...@gm...> Date: Friday, May 29, 2020 at 6:06 PM To: Srinidhi Mula <S....@tu...> Subject: Re: [DDDEC-news] DDEC charges for crystal17 output files Hi Srinidhi, I personally have not used Crystal cube files with Chargemol. The Cube format in Chargemol can read distances in bohrs or angstroms. According to the Chargemol manual: In version 3.4.5 (released on October 27, 2016), we added an option to choose whether to read cube file inputs in units of bohr or angstrom. For reading the input geometry and density from the cube file in bohr, no action is necessary (default behavior). For reading the input geometry and density from the cube file in angstroms, add the following lines to the job_control.txt file: <density format> e_per_angs3 </density format> I would try to generate cube files with either units of bohrs or angstroms and then see if Chargemol can read those. Sincerely, Tom On Fri, May 29, 2020 at 8:13 AM Srinidhi Mula <S....@tu...<mailto:S....@tu...>> wrote: Hello, I am trying to calculate DDEC charges from gaussian cube format files obtained as output from CRYSTAL17 program. Instructions doesn’t specifically tell about job_control format of crystal17 software. Any suggestions on which format to use would be great. Thanks Srinidhi _______________________________________________ DDEC-news mailing list DDE...@li...<mailto:DDE...@li...> https://lists.sourceforge.net/lists/listinfo/ddec-news<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_ddec-2Dnews&d=DwMFaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=FyKYph8p2vEJTRpx9CuRWiV8qNlY2hErtPJwj3xXsoA&m=q7aAZXk3ge57VJtPAjvFA20bg31D3VhsFfLmurFFClw&s=o3GthG9i6l86n-M8jDGGTjUKxGbpeoE3itGAl0fYhM8&e=> |
|
From: Suman C. <sum...@gm...> - 2020-05-29 18:39:30
|
I am trying to run the DDEC program to calculate the NET atomic charges. I am using VASP. I was trying to run the program in a folder where I have kept AECCAR0, AECCAR2, CHGCAR and POTCAR. I have also correctly written the path of the atomic densities. But while trying to run the program I am getting the following error : Could not find a suitable reference density. Program will terminate. Can onyone help me to solve this? Thanks, Regards Suman Chowdhury |
|
From: Srinidhi M. <S....@tu...> - 2020-05-29 14:13:15
|
Hello, I am trying to calculate DDEC charges from gaussian cube format files obtained as output from CRYSTAL17 program. Instructions doesn’t specifically tell about job_control format of crystal17 software. Any suggestions on which format to use would be great. Thanks Srinidhi |
|
From: Loay El A. <loa...@gm...> - 2020-05-13 01:42:27
|
Dears, I have just downloaded and started using the code with VASP. in spite of correctly defining the path to atomic densities folder that was included in the downloaded ZIP file, it gives out the message "Could not find a suitable reference density. Program will terminate." Could you please guide me what could be my problem. Best Regards, Loay |
|
From: Howard S. <hs...@gm...> - 2019-09-24 18:33:05
|
Dear Prof. Manz, In one of my recent projects, I need to calculate the IR spectroscopy of a hydrogen-containing system, based on AIMD. To that end, I will need to calculate the polarizability of the system as a function of time. Since your group has developed a new method to compute polarizabilities based on a single standard calculation, I find this method particularly appealing. You mentioned in one of the posts that you would make it publicly available soon. I wonder when a new release of the program is likely? Thank you very much. Howard Sheng Department of Physics and Astronomy George Mason University |
|
From: Daniela K. <dk...@ca...> - 2019-08-13 13:33:35
|
I am trying to compute believable charges while simulating cationic zeolites using AIMD (within CP2K). I had no trouble obtaining charges when the forces where evaluated using the Gaussian and Plane Waves (GPW) method as implemented in Quickstep (within CP2K). However, I have not been able to obtain charges when using the Gaussian and AUGMENTED plane wave method (GAPW); which is the method I use when running AIMD. The error I get is “The electrons are not properly accounted for. Either the grid in your electron density input file is too coarse, you have specified the incorrect ne t charge in the chargemol_job.m file, or the number of core electrons for each atom has not been setup correctly. Program will terminate” Note that I get this error when the only difference between a CP2K run that leads to charges and one that fails is the the choice of method (GAPW vs. GPW). I would appreciate any advice. Thanks so so much Daniela Kohen Carleton College |
|
From: Yanhui Z. <YZ...@tc...> - 2019-05-02 20:38:56
|
Dear DDEC users, I am a newbie here, and have compiled chargemol_09_26_2017 for giving it a go. When testing the VASP examples in the code, it gives me the error message: ############################################################ The CHGCAR file size is: 3232711 bytes. non_collinear = F spin_available = F c2_011_011_011_500_100.txt Could not find a suitable reference density. Program will terminate. ############################################################ The files of AECCAR0, AECCAR2, CHGCAR, POTCAR and job_control.txt are all put in the same directory. All atomic density files are from "chargemol_09_26_2017/examples_to_run/VASP4_NaCl_bulk_example". Here is the job_control.txt file: ##################################################################### <net charge> 0.0 </net charge> <periodicity along A, B, and C vectors> .true. .true. .true. </periodicity along A, B, and C vectors> <atomic densities directory complete path> /home/users/yzhang1/VASP-tools/chargemol_09_26_2017/examples_to_run/VASP4_NaCl_bulk_example/ </atomic densities directory complete path> <charge type> DDEC6 </charge type> ##################################################################### Please advice possible solutions. Thanks in advance! Yanhui -------------------------------------- Dr. Yanhui ZHANG Research Fellow Lloyd Building 210 CRANN / School of Physics Trinity College Dublin Email: yz...@tc... |
|
From: Suvardhan J. <j.s...@gm...> - 2019-01-31 14:18:00
|
Respected All, I am trying to deduce partial charges from the charge density obtained from Siesta. When I run it, I am getting an error message as "*Attempting to allocate already allocated variable 'raw_spin_1'*". It tried both serial and parallel modes. I am using the latest version of DDEC. Can some one tell me how to avoid this? Thanks and regards Vardhan |
|
From: Thomas M. <tho...@gm...> - 2018-09-07 16:22:51
|
Hi Satish, During the past few years, my research group developed a new method to compute polarizabilities and dispersion coefficients using the DDEC partition as inputs. We have a manuscript written up that is undergoing final editing in preparation for submission to a journal. (I predict that submission will occur within 2 weeks from now.) As soon as the manuscript is published, I plan to release an updated version of Chargemol that will compute polarizabilities and dispersion coefficients. We have these methods already programmed in a development version that has not yet been made publicly available. Because this new approach does not require manually applying an external electric field, only a single standard calculation is needed as the input. Although I could go through the detailed equations regarding the dipole moments and polarizabilities, this is something that is best left up to being explained in published journal articles and to be computed in an automated fashion by the program. However, I would like to point out that the polarizability is related to the dipole moment change polarizability tensor = change in dipole moment vector per change in applied electric field component Please find responses to your questions below: > Based on the atomic dipole vector (muA equation 100 in your RSC Adv. 2016 paper), I calculated the magnitude of the sum of atomic dipoles (muO, muH, muH). This magnitude of dipole moment of H2O was 0.12 Debye (of course this is much smaller than 1.8 Debye as the first term of eq 102 is neglected). Response: The molecular dipole moment (eq. 102 of paper (RSC Adv. 6 (2016) 47771-47801, DOI: 10.1039/c6ra04656h (open access))) must be computed included both terms. >Is it correct to assume that the atomic dipole moment calculated by DDEC6 represents induced dipole (which can be used in the expression for induced dipole moment)? Response: The atomic dipole moments (eq. 99 of paper) are not the induced dipoles. The induced dipole moment is the difference between molecular dipole moment (eq. 102) with and without the applied electric field. >Is there a less arbitrary way of obtaining polarizability from atomic dipole moments rather than choosing an arbitrary value for Efield? Response: Please see my comments above about the new method to compute polarizabilities that does not require applying any electric field. This new method will be available in the next Chargemol version. >However, based on there is a strong coordinate dependence of dipole moment within the equation. Response: The dipole moment of a molecule with no net charge is independent of the coordinate system origin. For a molecule with net charge (i.e., ion), the dipole moment depends on the coordinate system origin. Sincerely, Tom On Fri, Sep 7, 2018 at 9:26 AM Satish Kumar <sat...@gm...> wrote: > Hello Professor Manz and other DDEC users, > > I was trying to make sense of the results I obtained for polarizability of > a water molecule from the atomic dipole moments. I run a regular PBE > calculation and get DDEC6 charges, atomic dipoles etc. Based on the atomic > dipole vector (muA equation 100 in your RSC Adv. 2016 paper), I calculated > the magnitude of the sum of atomic dipoles (muO, muH, muH). This magnitude > of dipole moment of H2O was 0.12 Debye (of course this is much smaller > than 1.8 Debye as the first term of eq 102 is neglected). Using the > standard expression for calculating polarizabilty (induced dipole moment = > polarizability * Efield), I get a polarizability of 14 Angst^3 when Efield > was 0.01 V/Angst (a standard value in density functional perturbation > theory). However, polarizability of H2O is ~ 1.6 Angst3. Couple of > questions: > > 1) Is it correct to assume that the atomic dipole moment calculated by > DDEC6 represents induced dipole (which can be used in the expression for > induced dipole moment)? > 2) Is there a less arbitrary way of obtaining polarizability from atomic > dipole moments rather than choosing an arbitrary value for Efield? > > On a slightly different note, Equation 102 of the paper states that the > total dipole moment for a molecule can be calculated using DDEC6. However, > based on there is a strong coordinate dependence of dipole moment within > the equation. This means a molecule placed in the center of box will be > have a much different dipole moment than that placed at one of the corners > of the box. How do we avoid the ambiguity of dipole moment calculated using > equation 102 that depends on molecular coordinate system? > > - Satish Iyemperumal > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > DDEC-news mailing list > DDE...@li... > https://lists.sourceforge.net/lists/listinfo/ddec-news > |
|
From: Satish K. <sat...@gm...> - 2018-09-06 14:13:14
|
Hello Professor Manz and other DDEC users, I was trying to make sense of the results I obtained for polarizability of a water molecule from the atomic dipole moments. I run a regular PBE calculation and get DDEC6 charges, atomic dipoles etc. Based on the atomic dipole vector (muA equation 100 in your RSC Adv. 2016 paper), I calculated the magnitude of the sum of atomic dipoles (muO, muH, muH). This magnitude of dipole moment of H2O was 0.12 Debye (of course this is much smaller than 1.8 Debye as the first term of eq 102 is neglected). Using the standard expression for calculating polarizabilty (induced dipole moment = polarizability * Efield), I get a polarizability of 14 Angst^3 when Efield was 0.01 V/Angst (a standard value in density functional perturbation theory). However, polarizability of H2O is ~ 1.6 Angst3. Couple of questions: 1) Is it correct to assume that the atomic dipole moment calculated by DDEC6 represents induced dipole (which can be used in the expression for induced dipole moment)? 2) Is there a less arbitrary way of obtaining polarizability from atomic dipole moments rather than choosing an arbitrary value for Efield? On a slightly different note, Equation 102 of the paper states that the total dipole moment for a molecule can be calculated using DDEC6. However, based on there is a strong coordinate dependence of dipole moment within the equation. This means a molecule placed in the center of box will be have a much different dipole moment than that placed at one of the corners of the box. How do we avoid the ambiguity of dipole moment calculated using equation 102 that depends on molecular coordinate system? - Satish Iyemperumal |
|
From: gigi a. <gig...@gm...> - 2018-08-16 16:46:57
|
Hi again In your job file do you have right all electrons and valence electrons for each atom? I had similar problem but using different software and files. And i needed a really tight grid size for the cube file. I don't know how quantum expresso and xsf file work. Sorry. Best Geraldine Le mer. 15 août 2018 14:36, Christoph Wolf <wol...@qn...> a écrit : > Hi Geraldine, > > thank you for your reply! I tried to increase the integration grid > (n_i=40,80,120, ...400 where i=x,y,z) but the result does not change. The > Quantum Espresso postprocessing routine actually integrates it up to 16 > electrons > > Calling punch_plot, plot_num = 0 > Writing data to file pot.dat > Reading data from file pot.dat > > Writing data to be plotted to file rho_40.xsf > > * Min, Max, Total, Abs charge: 0.009524 7.513486 16.0000 > 16.0000* > * Plot Type: 3D Output format: XCrySDen * > > So I think ddec uses a different integration scheme... > > Best, > Chris > > > On Wed, Aug 15, 2018 at 8:23 PM, gigi asia <gig...@gm...> wrote: > >> Dear Chris, >> >> Could be that your grid is in fact not tight enough. Try to play with the >> grid size used to obtain the cube file. >> >> Best >> Geraldine >> >> Le lun. 13 août 2018 06:35, Christoph Wolf <wol...@qn...> >> a écrit : >> >>> Dear all, >>> >>> I was trying to use the recent version of Chargemol (3.5) for xsf files >>> created from densities using Quantum Espresso and PAW pseudopotentials. I >>> know that this is not an officially supported charge but as it allows to >>> create XSF files I was optimistic. >>> >>> Unfortunately for the simple test case of MgO I always get rather large >>> "checkme" values, irrespective of convergence parameters from the >>> calculation and grid densities >>> >>> * ncore = 4.0000* >>> * nvalence = 16.0000* >>> * pixelvolume = 7.7137E-05* >>> * numerically integrated valence density = 1.5474E+01* >>> * sum_valence_occupancy_correction = 0.0000E+00* >>> * checkme = 5.2627E-01* >>> * The electrons are not properly accounted for.* >>> * Either the grid in your electron density input file is too coarse, you >>> have specified the incorrect net charge in the chargemol_job.m file, or the >>> number of core electrons for each atom has not been setup correctly.* >>> * Program will terminate* >>> >>> by using the checkme value as input charge in the job_control file I can >>> of course run it but that seems a rather brutal way if tricking the code... >>> >>> Any idea why this might be happening? Is that a problem of the pseudo or >>> the post-processing? Below are the input file and the header of the xsf >>> file for reference >>> >>> Best, >>> Chris >>> >>> *<net charge>* >>> *0.0* >>> *</net charge>* >>> >>> *<periodicity along A, B, and C vectors>* >>> *.true.* >>> *.true.* >>> *.true.* >>> *</periodicity along A, B, and C vectors>* >>> >>> *<input filename>* >>> *rho.xsf* >>> *</input filename>* >>> >>> *<atomic densities directory complete path>* >>> */opt/chargemol/atomic_densities/* >>> *</atomic densities directory complete path>* >>> >>> *<charge type>* >>> *DDEC6* >>> *</charge type>* >>> >>> *<number of core electrons>* >>> *12 2* >>> *8 2* >>> *</number of core electrons>* >>> >>> *<density format>* >>> *e_per_angs3* >>> *</density format>* >>> >>> *rho.xsf* >>> >>> * CRYSTAL* >>> * PRIMVEC* >>> * -2.127609885 0.000000000 2.127609885* >>> * 0.000000000 2.127609885 2.127609885* >>> * -2.127609885 2.127609885 0.000000000* >>> * PRIMCOORD* >>> * 2 1* >>> *12 0.000000000 0.000000000 0.000000000* >>> *8 -2.127609885 2.127609885 2.127609885* >>> *BEGIN_BLOCK_DATAGRID_3D* >>> *3D_PWSCF* >>> * BEGIN_DATAGRID_3D_RHO:spin_1* >>> * 120 120 120* >>> * 0.000000 0.000000 0.000000* >>> * -2.127610 0.000000 2.127610* >>> * 0.000000 2.127610 2.127610* >>> * -2.127610 2.127610 0.000000* >>> >>> Information about the pseudos (from the PSLibrary) >>> >>> *Mg:* >>> >>> * Valence configuration: * >>> * nl pn l occ Rcut Rcut US E pseu* >>> * 2S 1 0 2.00 0.700 0.900 -5.868494* >>> * 3S 2 0 2.00 0.700 0.900 -0.345836* >>> * 2P 2 1 6.00 0.900 1.400 -3.426014* >>> * 3P 3 1 0.00 0.900 1.400 -0.097756* >>> >>> *O:* >>> * Valence configuration: * >>> * nl pn l occ Rcut Rcut US E pseu* >>> * 2S 1 0 2.00 1.000 1.300 -1.761150* >>> * 2P 2 1 4.00 0.900 1.350 -0.663754* >>> -- >>> Postdoctoral Researcher >>> Center for Quantum Nanoscience, Institute for Basic Science >>> Ewha Womans University, Seoul, South Korea >>> >>> >>> ------------------------------------------------------------------------------ >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>> _______________________________________________ >>> DDEC-news mailing list >>> DDE...@li... >>> https://lists.sourceforge.net/lists/listinfo/ddec-news >>> >> > > > -- > Postdoctoral Researcher > Center for Quantum Nanoscience, Institute for Basic Science > Ewha Womans University, Seoul, South Korea > > |
|
From: Christoph W. <wol...@qn...> - 2018-08-15 11:36:45
|
Hi Geraldine,
thank you for your reply! I tried to increase the integration grid
(n_i=40,80,120, ...400 where i=x,y,z) but the result does not change. The
Quantum Espresso postprocessing routine actually integrates it up to 16
electrons
Calling punch_plot, plot_num = 0
Writing data to file pot.dat
Reading data from file pot.dat
Writing data to be plotted to file rho_40.xsf
* Min, Max, Total, Abs charge: 0.009524 7.513486 16.0000
16.0000*
* Plot Type: 3D Output format: XCrySDen *
So I think ddec uses a different integration scheme...
Best,
Chris
On Wed, Aug 15, 2018 at 8:23 PM, gigi asia <gig...@gm...> wrote:
> Dear Chris,
>
> Could be that your grid is in fact not tight enough. Try to play with the
> grid size used to obtain the cube file.
>
> Best
> Geraldine
>
> Le lun. 13 août 2018 06:35, Christoph Wolf <wol...@qn...> a
> écrit :
>
>> Dear all,
>>
>> I was trying to use the recent version of Chargemol (3.5) for xsf files
>> created from densities using Quantum Espresso and PAW pseudopotentials. I
>> know that this is not an officially supported charge but as it allows to
>> create XSF files I was optimistic.
>>
>> Unfortunately for the simple test case of MgO I always get rather large
>> "checkme" values, irrespective of convergence parameters from the
>> calculation and grid densities
>>
>> * ncore = 4.0000*
>> * nvalence = 16.0000*
>> * pixelvolume = 7.7137E-05*
>> * numerically integrated valence density = 1.5474E+01*
>> * sum_valence_occupancy_correction = 0.0000E+00*
>> * checkme = 5.2627E-01*
>> * The electrons are not properly accounted for.*
>> * Either the grid in your electron density input file is too coarse, you
>> have specified the incorrect net charge in the chargemol_job.m file, or the
>> number of core electrons for each atom has not been setup correctly.*
>> * Program will terminate*
>>
>> by using the checkme value as input charge in the job_control file I can
>> of course run it but that seems a rather brutal way if tricking the code...
>>
>> Any idea why this might be happening? Is that a problem of the pseudo or
>> the post-processing? Below are the input file and the header of the xsf
>> file for reference
>>
>> Best,
>> Chris
>>
>> *<net charge>*
>> *0.0*
>> *</net charge>*
>>
>> *<periodicity along A, B, and C vectors>*
>> *.true.*
>> *.true.*
>> *.true.*
>> *</periodicity along A, B, and C vectors>*
>>
>> *<input filename>*
>> *rho.xsf*
>> *</input filename>*
>>
>> *<atomic densities directory complete path>*
>> */opt/chargemol/atomic_densities/*
>> *</atomic densities directory complete path>*
>>
>> *<charge type>*
>> *DDEC6*
>> *</charge type>*
>>
>> *<number of core electrons>*
>> *12 2*
>> *8 2*
>> *</number of core electrons>*
>>
>> *<density format>*
>> *e_per_angs3*
>> *</density format>*
>>
>> *rho.xsf*
>>
>> * CRYSTAL*
>> * PRIMVEC*
>> * -2.127609885 0.000000000 2.127609885*
>> * 0.000000000 2.127609885 2.127609885*
>> * -2.127609885 2.127609885 0.000000000*
>> * PRIMCOORD*
>> * 2 1*
>> *12 0.000000000 0.000000000 0.000000000*
>> *8 -2.127609885 2.127609885 2.127609885*
>> *BEGIN_BLOCK_DATAGRID_3D*
>> *3D_PWSCF*
>> * BEGIN_DATAGRID_3D_RHO:spin_1*
>> * 120 120 120*
>> * 0.000000 0.000000 0.000000*
>> * -2.127610 0.000000 2.127610*
>> * 0.000000 2.127610 2.127610*
>> * -2.127610 2.127610 0.000000*
>>
>> Information about the pseudos (from the PSLibrary)
>>
>> *Mg:*
>>
>> * Valence configuration: *
>> * nl pn l occ Rcut Rcut US E pseu*
>> * 2S 1 0 2.00 0.700 0.900 -5.868494*
>> * 3S 2 0 2.00 0.700 0.900 -0.345836*
>> * 2P 2 1 6.00 0.900 1.400 -3.426014*
>> * 3P 3 1 0.00 0.900 1.400 -0.097756*
>>
>> *O:*
>> * Valence configuration: *
>> * nl pn l occ Rcut Rcut US E pseu*
>> * 2S 1 0 2.00 1.000 1.300 -1.761150*
>> * 2P 2 1 4.00 0.900 1.350 -0.663754*
>> --
>> Postdoctoral Researcher
>> Center for Quantum Nanoscience, Institute for Basic Science
>> Ewha Womans University, Seoul, South Korea
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot______
>> _________________________________________
>> DDEC-news mailing list
>> DDE...@li...
>> https://lists.sourceforge.net/lists/listinfo/ddec-news
>>
>
--
Postdoctoral Researcher
Center for Quantum Nanoscience, Institute for Basic Science
Ewha Womans University, Seoul, South Korea
|
|
From: gigi a. <gig...@gm...> - 2018-08-15 11:23:44
|
Dear Chris, Could be that your grid is in fact not tight enough. Try to play with the grid size used to obtain the cube file. Best Geraldine Le lun. 13 août 2018 06:35, Christoph Wolf <wol...@qn...> a écrit : > Dear all, > > I was trying to use the recent version of Chargemol (3.5) for xsf files > created from densities using Quantum Espresso and PAW pseudopotentials. I > know that this is not an officially supported charge but as it allows to > create XSF files I was optimistic. > > Unfortunately for the simple test case of MgO I always get rather large > "checkme" values, irrespective of convergence parameters from the > calculation and grid densities > > * ncore = 4.0000* > * nvalence = 16.0000* > * pixelvolume = 7.7137E-05* > * numerically integrated valence density = 1.5474E+01* > * sum_valence_occupancy_correction = 0.0000E+00* > * checkme = 5.2627E-01* > * The electrons are not properly accounted for.* > * Either the grid in your electron density input file is too coarse, you > have specified the incorrect net charge in the chargemol_job.m file, or the > number of core electrons for each atom has not been setup correctly.* > * Program will terminate* > > by using the checkme value as input charge in the job_control file I can > of course run it but that seems a rather brutal way if tricking the code... > > Any idea why this might be happening? Is that a problem of the pseudo or > the post-processing? Below are the input file and the header of the xsf > file for reference > > Best, > Chris > > *<net charge>* > *0.0* > *</net charge>* > > *<periodicity along A, B, and C vectors>* > *.true.* > *.true.* > *.true.* > *</periodicity along A, B, and C vectors>* > > *<input filename>* > *rho.xsf* > *</input filename>* > > *<atomic densities directory complete path>* > */opt/chargemol/atomic_densities/* > *</atomic densities directory complete path>* > > *<charge type>* > *DDEC6* > *</charge type>* > > *<number of core electrons>* > *12 2* > *8 2* > *</number of core electrons>* > > *<density format>* > *e_per_angs3* > *</density format>* > > *rho.xsf* > > * CRYSTAL* > * PRIMVEC* > * -2.127609885 0.000000000 2.127609885* > * 0.000000000 2.127609885 2.127609885* > * -2.127609885 2.127609885 0.000000000* > * PRIMCOORD* > * 2 1* > *12 0.000000000 0.000000000 0.000000000* > *8 -2.127609885 2.127609885 2.127609885* > *BEGIN_BLOCK_DATAGRID_3D* > *3D_PWSCF* > * BEGIN_DATAGRID_3D_RHO:spin_1* > * 120 120 120* > * 0.000000 0.000000 0.000000* > * -2.127610 0.000000 2.127610* > * 0.000000 2.127610 2.127610* > * -2.127610 2.127610 0.000000* > > Information about the pseudos (from the PSLibrary) > > *Mg:* > > * Valence configuration: * > * nl pn l occ Rcut Rcut US E pseu* > * 2S 1 0 2.00 0.700 0.900 -5.868494* > * 3S 2 0 2.00 0.700 0.900 -0.345836* > * 2P 2 1 6.00 0.900 1.400 -3.426014* > * 3P 3 1 0.00 0.900 1.400 -0.097756* > > *O:* > * Valence configuration: * > * nl pn l occ Rcut Rcut US E pseu* > * 2S 1 0 2.00 1.000 1.300 -1.761150* > * 2P 2 1 4.00 0.900 1.350 -0.663754* > -- > Postdoctoral Researcher > Center for Quantum Nanoscience, Institute for Basic Science > Ewha Womans University, Seoul, South Korea > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > DDEC-news mailing list > DDE...@li... > https://lists.sourceforge.net/lists/listinfo/ddec-news > |
|
From: SUDARSHAN B. <ssn...@gm...> - 2018-08-13 08:47:46
|
Hello Everyone,
I tried to calculate DDEC6 charges using valence_density and spin
_density files generated from CP2K (where I have used Local Spin Density
for the spin polarised system).
While running the Chargemol program it is showing an error which
I've pasted below :
Program received signal SIGSEGV: Segmentation fault - invalid memory
reference.
Backtrace for this error:
#0 0x4E77EE in _gfortran_backtrace
#1 0x4E7150 in _gfortrani_backtrace_handler
#2 0x14DFC87024AF
#3 0x42484B in
__module_read_spin_density_cube_files_MOD_read_spin_density_cube_files
#4 0x431A45 in
__module_format_valence_cube_density_MOD_format_valence_cube_density
#5 0x47F23C in
__module_run_valence_core_densities_MOD_run_valence_core_densities
#6 0x4E6766 in MAIN__ at chargemol.f08:?
While running for a non-spin polarised system it's working fine with no
error.
I'm using Chargemol_10_27_2016 package with Linux parallel version.
Can someone help me in this issue ??
Thanks..
Mr. Sudarshan Behera
JNCASR, Bengaluru
India
|
|
From: Christoph W. <wol...@qn...> - 2018-08-13 03:35:37
|
Dear all, I was trying to use the recent version of Chargemol (3.5) for xsf files created from densities using Quantum Espresso and PAW pseudopotentials. I know that this is not an officially supported charge but as it allows to create XSF files I was optimistic. Unfortunately for the simple test case of MgO I always get rather large "checkme" values, irrespective of convergence parameters from the calculation and grid densities * ncore = 4.0000* * nvalence = 16.0000* * pixelvolume = 7.7137E-05* * numerically integrated valence density = 1.5474E+01* * sum_valence_occupancy_correction = 0.0000E+00* * checkme = 5.2627E-01* * The electrons are not properly accounted for.* * Either the grid in your electron density input file is too coarse, you have specified the incorrect net charge in the chargemol_job.m file, or the number of core electrons for each atom has not been setup correctly.* * Program will terminate* by using the checkme value as input charge in the job_control file I can of course run it but that seems a rather brutal way if tricking the code... Any idea why this might be happening? Is that a problem of the pseudo or the post-processing? Below are the input file and the header of the xsf file for reference Best, Chris *<net charge>* *0.0* *</net charge>* *<periodicity along A, B, and C vectors>* *.true.* *.true.* *.true.* *</periodicity along A, B, and C vectors>* *<input filename>* *rho.xsf* *</input filename>* *<atomic densities directory complete path>* */opt/chargemol/atomic_densities/* *</atomic densities directory complete path>* *<charge type>* *DDEC6* *</charge type>* *<number of core electrons>* *12 2* *8 2* *</number of core electrons>* *<density format>* *e_per_angs3* *</density format>* *rho.xsf* * CRYSTAL* * PRIMVEC* * -2.127609885 0.000000000 2.127609885* * 0.000000000 2.127609885 2.127609885* * -2.127609885 2.127609885 0.000000000* * PRIMCOORD* * 2 1* *12 0.000000000 0.000000000 0.000000000* *8 -2.127609885 2.127609885 2.127609885* *BEGIN_BLOCK_DATAGRID_3D* *3D_PWSCF* * BEGIN_DATAGRID_3D_RHO:spin_1* * 120 120 120* * 0.000000 0.000000 0.000000* * -2.127610 0.000000 2.127610* * 0.000000 2.127610 2.127610* * -2.127610 2.127610 0.000000* Information about the pseudos (from the PSLibrary) *Mg:* * Valence configuration: * * nl pn l occ Rcut Rcut US E pseu* * 2S 1 0 2.00 0.700 0.900 -5.868494* * 3S 2 0 2.00 0.700 0.900 -0.345836* * 2P 2 1 6.00 0.900 1.400 -3.426014* * 3P 3 1 0.00 0.900 1.400 -0.097756* *O:* * Valence configuration: * * nl pn l occ Rcut Rcut US E pseu* * 2S 1 0 2.00 1.000 1.300 -1.761150* * 2P 2 1 4.00 0.900 1.350 -0.663754* -- Postdoctoral Researcher Center for Quantum Nanoscience, Institute for Basic Science Ewha Womans University, Seoul, South Korea |
|
From: gigi a. <gig...@gm...> - 2017-12-09 08:22:55
|
Hi Anil Did you download or have the atomic_densities file in the right folder for running chargemol??? This may be the problem. Best Geraldine Le 7 déc. 2017 06:22, "Anil Kumar Tummanapelli" <ch...@nu...> a écrit : Hi DDEC Users, I have started using DDEC with the new version. But I am facing problem with an error “Could not find a suitable reference density. Program will terminate.”. Best Regards, Anil Kumar NUS ------------------------------ Important: This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately; you should not copy or use it for any purpose, nor disclose its contents to any other person. Thank you. ------------------------------------------------------------ ------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ DDEC-news mailing list DDE...@li... https://lists.sourceforge.net/lists/listinfo/ddec-news |
|
From: Anil K. T. <ch...@nu...> - 2017-12-07 04:22:57
|
Hi DDEC Users, I have started using DDEC with the new version. But I am facing problem with an error "Could not find a suitable reference density. Program will terminate.". Best Regards, Anil Kumar NUS ________________________________ Important: This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately; you should not copy or use it for any purpose, nor disclose its contents to any other person. Thank you. |
|
From: gigi a. <gig...@gm...> - 2017-11-02 13:51:48
|
Dear Thomas, I am quite new to chargemol. I would like to calculate some BOs for my systems. I have practical problems upon running the linux binarie. The program runs fine until these points : ------------------------------------------------------------------- ******************** TIME CONTROL ******************** Starting check_grid_spacing ****************************************************** The grid spacing in your electron density input file is adequate. ******************** TIME CONTROL ******************** Finished check_grid_spacing in 0.35299998521804810 seconds ****************************************************** Finished the check for missing core electrons. ******************** TIME CONTROL ******************** Finished add_missing_core_density in 0.88200002908706665 seconds ****************************************************** ******************** TIME CONTROL ******************** Finished format_valence_cube_density in 34.268001556396484 seconds ****************************************************** then complains : ---------------------------------- ncore = 1034.0000 nvalence = 1850.0000 pixelvolume = 1.1386E-02 numerically integrated valence density = 1.7989E+03 sum_valence_occupancy_correction = 0.0000E+00 checkme = 5.1085E+01 The electrons are not properly accounted for. Either the grid in your electron density input file is too coarse, you have specified the incorrect net charge in the chargemol_job.m file, or the number of core electrons for each atom has not been setup correctly. Program will terminate -------------------------------------- Indeed the checkme value is quite big. I am wondering where can be the problem ! the run does not go further. My grid seems fine 0.22 bohr. The core electrons are properly set in the Job_control.txt file ( I guess this is this chargemol_job.m file mentioned in the complain ??? or where is that file) as well the net charge is well set as this is neutral system. Please let me know where can be the problem. If you need extra informations let me know. Best Geraldine |
|
From: Thomas M. <tm...@nm...> - 2017-10-01 22:59:37
|
Dear Chargemol users: Chargemol version 3.5 has now been released on ddec.sourceforge.net. Please download the latest version. The main differences between versions 3.5 and 3.4.x are: 1. The method for computing bond orders has been extensively reworked to make it faster and simpler. The code now uses the published method described in T. A. Manz, “Introducing DDEC6 atomic population analysis: part 3. Comprehensive method to compute bond orders <http://dx.doi.org/10.1039/c7ra07400j>,” *RSC Adv.*, *7* (2017) 45552-45581 (open access). 2. In addition to the r-cubed moments, the program now computes the r-squared and r-fourth radial moments for each atom. These radial moments are computed using numerical integration. In addition, for single atom systems with .wfx file inputs, the exact (i.e., analytic) values of these moments are also printed (if the input file contains no higher than g-type basis functions). 3. The atomic radial moments files are now printed in a format that can be read using the Jmol program. 4. The program memory requirements were decreased by removing an extra large array from the spin partitioning modules. The names of some variables and arrays have also been updated to make them consistent with the published articles. 5. The integration_tolerance_percent was increased to 0.1. 6. In the job_control.txt file, the option of whether to compute bond orders is now specified using the tag <compute BOs> instead of the tag <compute EBOs>. 7. The core iterator has been updated to include a step at the beginning that limits the number of core electrons assigned to a single pixel to ≤ 30 electrons before core partitioning and core grid correction. 8. When reading VASP input files, the program now looks for not-a-name (NAN, ±infinity) entries (as well as entries with an absolute value greater than 1012) in the density grid files and terminates with an error if any are found. 9. A bug in the reading of spin densities from .xsf files was fixed. 10. A bug in the processing of wfx files using periodic boundary conditions was fixed. 11. Some minor typos and spelling mistakes were corrected. Sincerely, Tom Manz |
