Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Interesting issue. some notes if I may:
- Everything looks fine if you run the two calculations (Graphene1.py and Graphene2.py) including the BS analysis. The two BS objects are thus exactly the same. No errors here.
- Instead something is going wrong when you read one of the two BulkConfiguration (nlread part). The possible bug seems somewhere there, we will investigate.
- Because it seems that the problem is not related to k-points, by using 3x3 k-points and SZP basis set allows you to run on a laptop in less then one minute and makes everything faster.
- I noticed you use UnitCell for your bulk configuration. Why not hexagonal?
, for I do not have the source code can be used to debug.
I really just changed 1 line - the k-points, compared to yours.
Attached is also the corresponding band structure plot.
I didn't evaluate the total energy.
bulk_configuration = nlread('scf.nc',BulkConfiguration)[0]
bandstructure = Bandstructure(
configuration=bulk_configuration,
kpoints=[[0.,0.,0.],[1./3,2./3,0.],[2./3,1./3,0.]],
bands_above_fermi_level=All
)
nlsave('band1.nc', bandstructure)
I re-ran your Graphene1.py script with 27x27 k-points and I then get a perfect match to the expected result.
First of all, thanks a lot for providing simple scripts for debugging. It makes a world of difference for us.
Now, you wouldn't save any memory by storing this information, because you would still have to read it back into memory from the NC file. And doing so takes about as much time as recomputing it. So if anything we do save space doing it the way we do - the NC file becomes smaller.
So, graphene is tricky. I re-ran your Graphene1.py script with 27x27 k-points and I then get a perfect match to the expected result. Probably you can get away with fewer but I wanted to be sure.
If you also only use 3 k-points for the self-consistent loop, this may be the reason - try 9x9 for the main calculation instead. I don't have time to look at the details but I agree something needs to be checked.
Right, those parts are not stored in the NC file because they are fast to recalculate, even for a large system.
numerical_accuracy_parameters = NumericalAccuracyParameters(
k_point_sampling=(9, 9, 1),
)
bandstructure = Bandstructure(
configuration=bulk_configuration,
kpoints=[[0.,0.,0.],[1./3,2./3,0.],[2./3,1./3,0.]],
bands_above_fermi_level=All
)
grep "E =" Graphene1.log
| 0 E = -209.947 dE = 1.000000e+00 dH = 1.262869e-01 |
| 1 E = -184.423 dE = 2.552412e+01 dH = 1.085114e-01 |
| 2 E = -191.404 dE = 6.980547e+00 dH = 2.408157e-03 |
| 3 E = -185.399 dE = 6.004406e+00 dH = 2.498466e-02 |
| 4 E = -185.413 dE = 1.391652e-02 dH = 8.107498e-05 |
| 5 E = -185.383 dE = 2.998789e-02 dH = 1.288588e-04 |
| 6 E = -185.385 dE = 2.034424e-03 dH = 1.304958e-05 |
| 7 E = -185.385 dE = 2.128451e-05 dH = 1.905362e-06 |
grep "E =" Graphene2.log
| 0 E = -209.947 dE = 1.000000e+00 dH = 1.262857e-01 |
| 1 E = -184.423 dE = 2.552401e+01 dH = 1.085104e-01 |
| 2 E = -191.403 dE = 6.980123e+00 dH = 2.408149e-03 |
| 3 E = -185.399 dE = 6.004017e+00 dH = 2.498361e-02 |
| 4 E = -185.413 dE = 1.390191e-02 dH = 8.113542e-05 |
| 5 E = -185.383 dE = 3.011765e-02 dH = 1.296259e-04 |
| 6 E = -185.385 dE = 2.236028e-03 dH = 1.403214e-05 |
| 7 E = -185.385 dE = 3.237228e-05 dH = 1.753595e-06 |
I apologize, I was not looking carefully enough. You are probably right, and the easiest way is to use the "Close neighbors" tools in the VNL Builder to verify it!
So in that case we are back to your first question, which I don't quite understand. Your scripts are very advanced which make them difficult to understand for anyone else. For a bug report, you will need to prepare two simple scripts that show the issue. The scripts need to be without "code" - just a simple version without options or loops or variables, and without custom plotting too - because after all there is a small possibility the error is in your code and not in ATK, and it will take us too long to troubleshoot your code.
Maybe, simply, your translation is not correct...
1. There are definitely atoms overlapping.
2. No. If two atoms are in the same position (modulus a lattice translation vector) you will get wrong results (in any code).
3. The design of MPI - the way used in ATK - is to duplicate the memory per MPI process. If you instead do a multithreaded calculation, this is not the case. MPI was originally designed as a way to distribute calculation across separate nodes in a cluster environment. Using MPI on a multicore machine can provide some performance improvement, but it's in the nature of the problem that you need enough memory to use it in this way. Note however that you will most likely not get a good speed-up by putting say 4 MPIs on a single quadcore machine - there will be too much competition between the processes for RAM and cache access.
For your 1st question:
The lattice vectors defined in your script file correspond to those of a hexagonal supercell of graphene. But the coordinates of atoms defined in your script file are wrong, because they contain some atoms in a neighboring image of such supercell. It will cause some atoms being overlapped in the supercell calculation although no error message was reported during the running of job. So both of your calculations are wrong.
For your 2nd questions:
Please provide more detailed information instead of a rough claim. For a typical case of your calculation running in the serial manner and in the parallel one with multiple processes, you may type the command of "top" to check the use of memory. Also, if you can provide the details of your parallel jobs (that is, how did you run the job in parallel?), it will be much better.
Please check the manual for running ATK in:
http://www.quantumwise.com/documents/tutorials/latest/ParallelGuide/ParallelGuide.pdf
An important thing to note is that each MPI node uses the same amount of RAM. So if one assigns more than one MPI processes to the same node, the memory requirement goes up quickly on that node.I hope shared-memory should been used in ATK‘s python multiprocessing to save RAM.
This is possible for 1, but not for 2, today. We will consider 2 as a feature idea, although I think a more generic approach might be to take the real-space denstiy from the previous calculation and use that to initiate the scf loop instead.
