Hi, I downloaded a code binary a few days ago (on 2/6-08) and have the following problems:
I used to be able to get a cube file called bader_rho.dat which had integer values describing the domain of each bader volume. This was in my opinion the single most usefull output of the code, as I could get anything else, by using this file as a filter on my original density, and then integrate, or do other stuff. I could also visualize the dividing surfaces by viewing some half-integer iso-contour surface in e.g. vmd.
The code no longer seem to output this file. Can I get this back? If not: how do you guys plot the dividing surfaces?
Another problem: The output cube files of the bader program have always been a mystery to me.
If I try to plot it in vmd, the plot makes no sense.
My input cube file has the data sorted according to a loop of x first, then y, then z.
It used to be so that I could manually read in your output file point-by-point, assuming a z-y-x ordering and then write my own cube file which could then be visualized in vmd. This however no longer seems to be possible. The question is simply this: how do I use/analyse your output files (preferable using vmd :-) )
With kind regards,
Carsten Rostgaard (Ph.D.),
Center for atomic-scale materials design,
Technical University of Denmark
Obtaining the dividing surfaces
Moderator: moderators
Re: Obtaining the dividing surfaces
Hi Carsten,
Thank you for catching the cube writing error. We almost exclusively use chgcar files, and had not noticed the rank-order problem.
We did output a file with the bader and atomic volumes in the past. I had no idea that anyone used this, but it makes sense if you want to use it as a filter. I just spoke with Wenjie, and she will add this back in (as well as fix the cube writing). We should have a new version up next week.
To visualize a Bader volume, you can write that volume to a chgcar/cube file. This will have the charge value for all points in the volume and zero elsewhere. Then you can visualize it by choosing a low isosurface value. I found this preferable to the isosufaces of integer+1/2 values in the bader_rho.dat file because it lets you choose a single volume. With the integer+1/2 method, it includes all volumes with index less than integer as well as the one you want. But anyways, if you are using a file as a filter, you can easily select a volume index and write a file with 1's for that index and 0's otherwise.
- Graeme
Thank you for catching the cube writing error. We almost exclusively use chgcar files, and had not noticed the rank-order problem.
We did output a file with the bader and atomic volumes in the past. I had no idea that anyone used this, but it makes sense if you want to use it as a filter. I just spoke with Wenjie, and she will add this back in (as well as fix the cube writing). We should have a new version up next week.
To visualize a Bader volume, you can write that volume to a chgcar/cube file. This will have the charge value for all points in the volume and zero elsewhere. Then you can visualize it by choosing a low isosurface value. I found this preferable to the isosufaces of integer+1/2 values in the bader_rho.dat file because it lets you choose a single volume. With the integer+1/2 method, it includes all volumes with index less than integer as well as the one you want. But anyways, if you are using a file as a filter, you can easily select a volume index and write a file with 1's for that index and 0's otherwise.
- Graeme
-
- Posts: 3
- Joined: Fri Jun 06, 2008 11:56 am
Re: Obtaining the dividing surfaces
Hi, and thanks for the quick response.
As the chgcar files should work, I downloaded the vaspview program (vmd doesn't seem to support chgcar files), and analysed my density (cube) file using
$ bader -i cube -o chgcar -p atom_all density.cube
But looking at the output files (BvAt00x.dat) it seems that the program still tries to write cube output (despite the "-o chgcar" option).
My fear with trying to plot the dividing surface using the bader volume and a low iso-value, is just that I use a code that supports non-periodic boundary conditions, which has the consequence, that my edge points are *exactly* zero. Thus I would see a contour surface all the way around my box. But that remains to be seen. As you say the bader_rho.dat will return, I might wait for that.
Thanks a lot,
Carsten
As the chgcar files should work, I downloaded the vaspview program (vmd doesn't seem to support chgcar files), and analysed my density (cube) file using
$ bader -i cube -o chgcar -p atom_all density.cube
But looking at the output files (BvAt00x.dat) it seems that the program still tries to write cube output (despite the "-o chgcar" option).
My fear with trying to plot the dividing surface using the bader volume and a low iso-value, is just that I use a code that supports non-periodic boundary conditions, which has the consequence, that my edge points are *exactly* zero. Thus I would see a contour surface all the way around my box. But that remains to be seen. As you say the bader_rho.dat will return, I might wait for that.
Thanks a lot,
Carsten
Re: Obtaining the dividing surfaces
VMD does read CHGCAR files, thanks to a recent plugin (~ 1 year ago) that is now included with the program.
The -o flag was never implemented; it has been removed. All charge density output files are in the same form as the input.
The bader_rho.dat has returned, although it is now named BvIndex.dat. You can also write the atomic volumes to AtIndex.dat. The flags to write these are -p bader_index and -p atom_index, respectively.
These changes have been made in v0.25 (06/09/08).
Thanks to Wenjie for making these changes.
The -o flag was never implemented; it has been removed. All charge density output files are in the same form as the input.
The bader_rho.dat has returned, although it is now named BvIndex.dat. You can also write the atomic volumes to AtIndex.dat. The flags to write these are -p bader_index and -p atom_index, respectively.
These changes have been made in v0.25 (06/09/08).
Thanks to Wenjie for making these changes.
-
- Posts: 3
- Joined: Fri Jun 06, 2008 11:56 am
Re: Obtaining the dividing surfaces
Hi again
I hate to be a pain in the b**, but I downloaded the new file binary (I also downloaded the source and compiled it myself), and everything works, except if I try to use the new -p bader_index or -p atom_index options. If I try this, I get a segmentation fault.
On the upside, I tried to plot the Bader volumes with a low iso-contour surface, and the plot looks very nice (i.e. your fix for the cube format seems to work)
But it does have the unwanted effect we discussed earlier, see:
http://dcwww.fys.dtu.dk/~carstenr/water_divide_surf.png
My test system is H2O, and the dividing surfaces look almost identical (by eye) to the ones in Wenjie's paper.
By the way I get the Bader charges 9.0852, 0.4574, and 0.4574 (for O, H, and H respectively). This is not identical to yours, but that is of course code specific. I'm very pleased to get the same charges on both Hydrogen atoms, which I didn't when using the old algorithm.
I hate to be a pain in the b**, but I downloaded the new file binary (I also downloaded the source and compiled it myself), and everything works, except if I try to use the new -p bader_index or -p atom_index options. If I try this, I get a segmentation fault.
On the upside, I tried to plot the Bader volumes with a low iso-contour surface, and the plot looks very nice (i.e. your fix for the cube format seems to work)
But it does have the unwanted effect we discussed earlier, see:
http://dcwww.fys.dtu.dk/~carstenr/water_divide_surf.png
My test system is H2O, and the dividing surfaces look almost identical (by eye) to the ones in Wenjie's paper.
By the way I get the Bader charges 9.0852, 0.4574, and 0.4574 (for O, H, and H respectively). This is not identical to yours, but that is of course code specific. I'm very pleased to get the same charges on both Hydrogen atoms, which I didn't when using the old algorithm.
Re: Obtaining the dividing surfaces
Thanks for you help debugging this. There is a slightly new version (v0.25a) with the changes that fix the segfaults on some machines.