Re: [Spglib-users] problem with spg_get_ir_reciprocal_mesh
Brought to you by:
atztogo
From: Atsushi T. <atz...@gm...> - 2016-12-13 09:53:58
|
Hi again, I found an idea. I pushed the updated code to github. You can obtain the source code by % git clone https://github.com/atztogo/spglib.git % cd spglib % git checkout kpt_search I think this works as you like. I assume if no grid point exists after k-point rotation, it is not counted, which is not obvious. Togo On Tue, Dec 13, 2016 at 8:26 AM, Atsushi Togo <atz...@gm...> wrote: > Hi, > > I confirmed your results in spglib. Spglib outputs is wrong. > I implemented supposing mesh doesn't break symmetry. In this case, > algorithm with integers can handle dense mesh, e.g. 100x100x100 mesh is > easily handled. > > Anyway spglib results are clearly wrong. To avoid this and to implement an > algorithm to obtain the similar results by CASTEP that is as fast as > current spglib routine together with keeping the user interface, I need > some time to implement it. I show work-around in the last part of the > test-code below, which uses least common multiple. > > Togo > > ----------test-code---------- > #!/usr/bin/env python > > import spglib > > lattice = [[ 2.9306368570142554, 0.0000000000000000, 0.0000000000000000], > [-1.4653184285071277, 2.5380059674413284, 0.0000000000000000], > [ 0.0000000000000000, 0.0000000000000000, 4.6381396667889572]] > numbers = [1, 1] > points = [[0.6666666666666665, 0.3333333333333333, 0.7500000000000000], > [0.3333333333333334, 0.6666666666666667, 0.2500000000000000]] > cell = (lattice, points, numbers) > print("-----------") > mesh = [3, 3, 1] > mapping, grid = spglib.get_ir_reciprocal_mesh(mesh, cell, is_shift=[0, 0, > 0]) > for m, g in zip(mapping, grid): > print(("%2d " * 4) % (g[0], g[1], g[2], m)) > > print("-----------") > mesh = [3, 5, 1] > mapping, grid = spglib.get_ir_reciprocal_mesh(mesh, cell, is_shift=[0, 0, > 0]) > for m, g in zip(mapping, grid): > print(("%2d " * 4) % (g[0], g[1], g[2], m)) > > print("-----------") > mesh = [15, 15, 1] > mapping, grid = spglib.get_ir_reciprocal_mesh(mesh, cell, is_shift=[0, 0, > 0]) > import numpy as np > red_grid = np.array([(g, m) for g, m in zip(grid, mapping) if (g % [5, 3, > 1] == [0, 0, 0]).all()]) > for g, m in red_grid: > print(("%2d " * 4) % (g[0], g[1], g[2], m)) > for g, m in red_grid: > print(("%f " * 3 + "%d") % (g[0] / 15.0, g[1] / 15.0, g[2], m)) > > Togo > > On Tue, Dec 13, 2016 at 4:17 AM, Corsetti, Fabiano < > fab...@im...> wrote: > >> Corsetti, Fabiano has shared OneDrive for Business files with you. To >> view them, click the links below. >> >> <https://imperiallondon-my.sharepoint.com/personal/fc08_ic_ac_uk/Documents/Email%20attachments/input_data.txt> >> input_data.txt >> <https://imperiallondon-my.sharepoint.com/personal/fc08_ic_ac_uk/Documents/Email%20attachments/input_data.txt> >> >> <https://imperiallondon-my.sharepoint.com/personal/fc08_ic_ac_uk/Documents/Email%20attachments/input_data.txt> >> >> >> <https://imperiallondon-my.sharepoint.com/personal/fc08_ic_ac_uk/Documents/Email%20attachments/test(1).f90> >> test(1).f90 >> <https://imperiallondon-my.sharepoint.com/personal/fc08_ic_ac_uk/Documents/Email%20attachments/test(1).f90> >> >> <https://imperiallondon-my.sharepoint.com/personal/fc08_ic_ac_uk/Documents/Email%20attachments/test(1).f90> >> >> Dear all, >> >> >> I am having a problem generating the list of irreducible k-points with >> spglib for certain cases. >> >> >> I have written a minimal example to demonstrate this in the attached code >> (it's in Fortran using the spglib_f08.f90 interface). The system is a >> hexagonal unit cell of graphene with two carbon atoms. If I set >> mesh=(3,3,1) and is_shift=(0,0,0), a call to spg_get_ir_reciprocal_mesh >> gives me the expected output: >> >> >> number of irreducible k-points: 3 >> >> map: >> >> 0.0000000 0.0000000 0.0000000 0 >> 0.3333333 0.0000000 0.0000000 1 >> -0.3333333 0.0000000 0.0000000 1 >> 0.0000000 0.3333333 0.0000000 1 >> 0.3333333 0.3333333 0.0000000 1 >> -0.3333333 0.3333333 0.0000000 5 >> 0.0000000 -0.3333333 0.0000000 1 >> 0.3333333 -0.3333333 0.0000000 5 >> -0.3333333 -0.3333333 0.0000000 1 >> >> This agrees entirely with the output given by a CASTEP calculation for >> the same system: >> >> ------------------------------- >> k-Points For BZ Sampling >> ------------------------------- >> MP grid size for SCF calculation is 3 3 1 >> with an offset of 0.000 0.000 0.000 >> Number of kpoints used = 3 >> >> +++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> + Number Fractional coordinates Weight + >> +-----------------------------------------------------+ >> + 1 0.000000 -0.333333 0.000000 0.6666667 + >> + 2 0.000000 0.000000 0.000000 0.1111111 + >> + 3 0.333333 -0.333333 0.000000 0.2222222 + >> +++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> >> However, changing mesh=(3,5,1) now gives me: >> >> number of irreducible k-points: 3 >> >> map: >> 0.0000000 0.0000000 0.0000000 0 >> 0.3333333 0.0000000 0.0000000 1 >> -0.3333333 0.0000000 0.0000000 1 >> 0.0000000 0.2000000 0.0000000 1 >> 0.3333333 0.2000000 0.0000000 1 >> -0.3333333 0.2000000 0.0000000 5 >> 0.0000000 0.4000000 0.0000000 1 >> 0.3333333 0.4000000 0.0000000 5 >> -0.3333333 0.4000000 0.0000000 5 >> 0.0000000 -0.4000000 0.0000000 1 >> 0.3333333 -0.4000000 0.0000000 5 >> -0.3333333 -0.4000000 0.0000000 5 >> 0.0000000 -0.2000000 0.0000000 1 >> 0.3333333 -0.2000000 0.0000000 5 >> -0.3333333 -0.2000000 0.0000000 1 >> >> This does not seem to me to be correct, and indeed CASTEP gives a larger >> irreducible wedge: >> >> >> ------------------------------- >> k-Points For BZ Sampling >> ------------------------------- >> MP grid size for SCF calculation is 3 5 1 >> with an offset of 0.000 0.000 0.000 >> Number of kpoints used = 8 >> >> +++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> + Number Fractional coordinates Weight + >> +-----------------------------------------------------+ >> + 1 -0.333333 -0.200000 0.000000 0.1333333 + >> + 2 -0.333333 0.200000 0.000000 0.1333333 + >> + 3 -0.333333 0.400000 0.000000 0.1333333 + >> + 4 0.000000 -0.400000 0.000000 0.1333333 + >> + 5 0.000000 0.000000 0.000000 0.0666667 + >> + 6 0.000000 0.200000 0.000000 0.1333333 + >> + 7 0.333333 0.000000 0.000000 0.1333333 + >> + 8 0.333333 0.400000 0.000000 0.1333333 + >> +++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> >> >> Is somebody able to advise me whether this is indeed a bug in spglib, or >> if I have done something wrong? I should also mention that the list of >> symmetry operations found with spglib agree with CASTEP. >> >> >> Many thanks in advance! >> >> >> Kind regards, >> >> >> Fabiano Corsetti >> >> >> ------------------------------------------------------------ >> ------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >> _______________________________________________ >> Spglib-users mailing list >> Spg...@li... >> https://lists.sourceforge.net/lists/listinfo/spglib-users >> >> > > > -- > Atsushi Togo > Elements Strategy Initiative for Structural Materials, Kyoto university > E-mail: atz...@gm... > -- Atsushi Togo Elements Strategy Initiative for Structural Materials, Kyoto university E-mail: atz...@gm... |