 but stefano baroni tell me 'never trust a truth, unless you can give by yourself a correct answer to a legitimate question'. so i'll try 2x2x1 and make a energy and geometry comparison with the gamma point only. > if you do gamma point only, than you can exploit the parallelization over > g-space only. if you wanna use the g-space parallelization over the whole > cluster than as i mentioned you need a fast interconnect (infiniband, > myrinet, sci, quadrics and so on). |
|
| gigabit lan is just too slow for that > (except for insanely large supercells). thank you so much for the detail discussion. by the way, are you a german? i like german football team. i tried to fit u_co in such a way that the caluclated co-d projected dos to fit experiment (j. the problem is that the optimal u for pwscf and vasp differ quite a lot. if i use their value, i get a co-d projected dos far deep into the valence (completely non sense). any idea why the optimal u values for co in this case are so different? unfortunately, their value is more common (most transition metals around 5ev). i include a typical input file with just 8 k points. there is not a unique u value - our tests in molecules show that different pseudos give different u but the same chemistry - in solids the situations is less clear cut, and not fully clear to me at this stage. | |
| does it have a significant effect with respect to u=0 ? if it has, there must be something very subtle going on. the problem is that the optimal u for pwscf and vasp differ > quite a lot. > is it the different implementations for vasp and pwscf? pseudopotential? > > i have already tried to publish our results but the referees can not > accept the publication > based on such a small u_co value. very reasonable value and no referee would ever object. thanks in advance and also to nicola for his previous reply. very reasonable value and no referee would ever object. > > thanks in advance and also to nicola for his previous reply. nicola is right: probably the reason why "ortho-atomic" and "norm-atomic" produce similar results is that the atomic wavefunctions in the co pp are not normalized. | |
| try to check the occupations in the "atomic" case. atomic: wfcs are orthogonal (by construction) only to those belonging to the same atom (there are overlap regions in between atoms) norm-atomic: quick and dirty fix added to use pps whose wfcs are not normalized. when these wfcs are normalized it gives the same results as atomic". in general i would suggest to not look at the value of u itself but rather to the results it produces. very reasonable value and no referee would >> ever object. nicola is right: probably the reason why "ortho-atomic" and "norm-atomic" produce similar results is that the atomic wavefunctions in the co pp are not normalized. try to check the occupations in the "atomic" case. atomic: wfcs are orthogonal only to those belonging to the same atom (there are overlap regions in between atoms) norm-atomic: quick and dirty fix added to use pps whose wfcs are not normalized. when these wfcs are normalized it gives the same results as "atomic". in general i would suggest to not look at the value of u itself but rather to the results it produces. | |
| very reasonable value and no referee would ever > object. > > thanks in advance and also to nicola for his previous reply. vl> the network between my cluster is only 1gbit ethernet using tcp/ip. it is not the bandwidth of gige networking that is limiting, but the overhead of tcp/ip networking. for g-space parallelization you have a lot of messages (k-point parallelization is more of the embarrassingly parallel type of problem) and the high latency time of sending tcp/ip encoded data is killing the performance. | |
| you would see a similar behavior with with running tcp/ip over myrinet or infiniband. otoh, there are attempts to mpi libraries that gige hardware, but bypass the tcp/ip encoding (you need a second set of card and a second switch for that), but those are generally only working for a specific hardware/software combination due to of .. .. |