Menu

coordinates of vexternal and real space wfns relation to grid cariables

2012-11-06
2012-11-10
  • mike marchywka

    mike marchywka - 2012-11-06

    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$

     
  • Ravishankar Sundararaman

    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.

     
  • mike marchywka

    mike marchywka - 2012-11-10

    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.