I think things are making sense but I did have a question on the
coordinate sytems for the real space wavefunctions.
It appears that "zero is zero" and then at n/2 the space folds
and that I can use index like (x+(a/2))%a to get x==0 to specify
the most negative coordinate on the grid- is this as intended ?
If I do this, the orbitals
sort of look right - looking down the axis of acetylene I can
get a ring for what I think should be largely S orbitals
and twin peaks along x+/-y for the next higher levels.
The input vexternal file appears to be in "normal" coordinates
with "z" being the first index. So, to define a plane z< something,
I can write xxx000xxx000xxx000 etc. If I do this, offhand things
look ok but hard to tell so far. If I define a vext like this, the
higher level orbitals seem to "pour" into the plane and the lower ones
tilt.
ion C 0.00 0.00 0.00 0 # The last 0 holds this atom fixed
ion C 0.00 0.00 2.26 1 # The last 0 holds this atom fixed
ion H 0.00 0.00 4.26 1 # The last 0 holds this atom fixed
ion H 0.00 0.00 -2.00 1 # The last 0 holds this atom fixed
marchywka@marchywka-Latitude-E6510:~/d/jdft/jdftx$ grep -ni -A 10 getColu electronic/ColumnBundle.cpp
100:complexDataGptr ColumnBundle::getColumn(int i) const
101-{ const GridInfo& gInfo = *(basis->gInfo);
102- complexDataGptr full; nullToZero(full, gInfo); //initialize a full G-space vector to zero
103- //scatter from the i'th column to the full vector:
104- callPref(eblas_scatter_zdaxpy)(basis->nbasis, 1, basis->indexPref, dataPref()+index(i,0), full->dataPref());
105- return full;
106-}
107-
( LOL, this is the first time I'd seen && and I just assumed you were returning
const & to something internal until I looked above ),
The outputs are on the FFT grid from lattice coordinates [0,0,0] -> (1,1,1) in a raster scan format with the third coordinate fastest and the first coordinate slowest.
The wrapping you mention is because the atoms with any lattice coordinate outside [0,1) effectively gets wrapped to the unit cell in the output. Note that this is all in a plane-wave basis set: therefore your real calculation is of a periodic system and there is perfect translation invariance. My point is, there is nothing special about n/2 as you mentioned, and the code doesn't do any special wrapping at any particular point in space. Rather every atom and electron is accompanied by a periodic repetition, once per unit cell.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
ok. so the vexternal input does in fact have the 3rd coordainate "fastest" and starts from the most negative grid point. The FFT output will always output 0,0,0, as the first point and yes I guess fold was not the right word as I was expecting something odd near n/2 but I think the indexing scheme was right to put most negative grid coords in the corner of the output but the offset then is not always length/2 but depends on the grid origin. Thanks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think things are making sense but I did have a question on the
coordinate sytems for the real space wavefunctions.
It appears that "zero is zero" and then at n/2 the space folds
and that I can use index like (x+(a/2))%a to get x==0 to specify
the most negative coordinate on the grid- is this as intended ?
If I do this, the orbitals
sort of look right - looking down the axis of acetylene I can
get a ring for what I think should be largely S orbitals
and twin peaks along x+/-y for the next higher levels.
The input vexternal file appears to be in "normal" coordinates
with "z" being the first index. So, to define a plane z< something,
I can write xxx000xxx000xxx000 etc. If I do this, offhand things
look ok but hard to tell so far. If I define a vext like this, the
higher level orbitals seem to "pour" into the plane and the lower ones
tilt.
ion C 0.00 0.00 0.00 0 # The last 0 holds this atom fixed
ion C 0.00 0.00 2.26 1 # The last 0 holds this atom fixed
ion H 0.00 0.00 4.26 1 # The last 0 holds this atom fixed
ion H 0.00 0.00 -2.00 1 # The last 0 holds this atom fixed
./jdft_tool -grid vext.bin 80 80 | more
0 0 0 0.5
1 0 0 0.5
2 0 0 0.5
3 0 0 0.5
[...]
36 0 0 0.5
37 0 0 0.5
38 0 0 0.5
39 0 0 0.5
40 0 0 0
41 0 0 0
--More--
marchywka@marchywka-Latitude-E6510:~/d/jdft/jdftx$ grep -n saveRaw electronic/Dump.cpp
81: saveRawBinary(object, fname.c_str()); \
200: saveRawBinary(I(nboundTilde), fname.c_str());
218: saveRawBinary(I(eVars.C[q].getColumn(b)), fname.c_str());
marchywka@marchywka-Latitude-E6510:~/d/jdft/jdftx$
marchywka@marchywka-Latitude-E6510:~/d/jdft/jdftx$ grep -ni -A 10 getColu electronic/ColumnBundle.cpp
100:complexDataGptr ColumnBundle::getColumn(int i) const
101-{ const GridInfo& gInfo = *(basis->gInfo);
102- complexDataGptr full; nullToZero(full, gInfo); //initialize a full G-space vector to zero
103- //scatter from the i'th column to the full vector:
104- callPref(eblas_scatter_zdaxpy)(basis->nbasis, 1, basis->indexPref, dataPref()+index(i,0), full->dataPref());
105- return full;
106-}
107-
( LOL, this is the first time I'd seen && and I just assumed you were returning
const & to something internal until I looked above ),
marchywka@marchywka-Latitude-E6510:~/d/jdft/jdftx$ grep -n -A 10 "I(com" core/Operators.cpp
153:complexDataRptr I(complexDataGptr&& in)
154-{ //Destructible input (transform in place):
155- #ifdef GPU_ENABLED
156- cufftExecZ2Z(in->gInfo.planZ2Z, (double2)in->dataGpu(false), (double2)in->dataGpu(false), CUFFT_INVERSE);
157- #else
158- fftw_execute_dft(threadOperators ? in->gInfo.planInverseInPlaceMulti : in->gInfo.planInverseInPlaceSingle,
159- (fftw_complex)in->data(false), (fftw_complex)in->data(false));
160- #endif
161- return (complexDataRptr&&)in;
162-}
163-
marchywka@marchywka-Latitude-E6510:~/d/jdft/jdftx/svn/cpp$
The outputs are on the FFT grid from lattice coordinates [0,0,0] -> (1,1,1) in a raster scan format with the third coordinate fastest and the first coordinate slowest.
The wrapping you mention is because the atoms with any lattice coordinate outside [0,1) effectively gets wrapped to the unit cell in the output. Note that this is all in a plane-wave basis set: therefore your real calculation is of a periodic system and there is perfect translation invariance. My point is, there is nothing special about n/2 as you mentioned, and the code doesn't do any special wrapping at any particular point in space. Rather every atom and electron is accompanied by a periodic repetition, once per unit cell.
ok. so the vexternal input does in fact have the 3rd coordainate "fastest" and starts from the most negative grid point. The FFT output will always output 0,0,0, as the first point and yes I guess fold was not the right word as I was expecting something odd near n/2 but I think the indexing scheme was right to put most negative grid coords in the corner of the output but the offset then is not always length/2 but depends on the grid origin. Thanks.