[Wien] small bug in sgroup

[Peter Blaha]

I'm not sure if I would classify this as bug, it is more a (safety) 
feature.

One of the very basic rules is, that you should not change RMTs or use
different RMTs for the same elements.

In addition, since sgroup may split or combine positions, what should it
do when it combines a RMT=1.6 with a RMT=2.0 position ?

If sgroup does NOT change the lattice / equivalent positions, it is not
necessary to accept the struct file from sgroup.

Regards

> we found a small bug in the program sgroup.
> We are performing a calculations with a Ringwoodite crystal Fe2SiO4. The cell 
> has 56 atoms: 8 Si, 16 Fe and 32 O. We chose the following RMT for them: 
> Si=1.55, Fe = 1.8, O = 1.5.
> Then we simulated a non-stoichiometric crystal by substituting one Si with one 
> Fe. Since the Si atoms occupy smaller sites, we decided to change the radius of 
> the substituted Iron ONLY to 1.55. However, after running sgroup, the .struct 
> file generated by the program has all Iron atoms again with the same RMT (and 
> that gives an error in nn).
> It is not a big problem because then RMT in the .struct file can be manually 
> changed back to 1.55. However, one could difficultly notice it if nn doesn’t 
> give an error afterward. 
> 
> Stefano Rubino,
> Institute for Solid State Physics,
> Vienna University of Technology
> 
> -------------------------------------------------
> This mail sent through IMP: http://horde.org/imp/
> 
> _______________________________________________
> Wien mailing list
> Wien at zeus.theochem.tuwien.ac.at
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
> 


                                      P.Blaha
--------------------------------------------------------------------------
Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
Phone: +43-1-58801-15671             FAX: +43-1-58801-15698
Email: blaha at theochem.tuwien.ac.at    WWW: http://info.tuwien.ac.at/theochem/
--------------------------------------------------------------------------