Dear Kwant developers, I am having a error with "gauge" when I am adding 1D leads (Chains) to my 3D system. (I have both Chain leads, where I do not need gauge, of course, and nirmal leads, where I do need gauge) The call: gauge = kwant.physics.magnetic_gauge(sys) returns a error: 'not enough values to unpack (expected 2, got 0)', coming from the rows, cols = np.array([(i, j)for i, jin syst.graph if i < nand j < n]).transpose() in _check_infinite_syst(syst) in gauge.py In my case, n = 1 for a simple chain and so rows, cols are empty. Best wishes, Sergey
Sergey Slizovskiy wrote:
I am having a error with "gauge" when I am adding 1D leads (Chains) to my 3D system. (I have both Chain leads, where I do not need gauge, of course,
Could you please provide a minimal self-contained script that allows to reproduce the problem? Christoph
Dear Christoph, Here is the minimal example giving a error I described. The system is a 3-layer graphene and I add a couple of vertical 1D chains with small hopping to the main sample to model the STS tip. Thank you, Sergey On 23/09/2020 15:52, Christoph Groth wrote:
Sergey Slizovskiy wrote:
I am having a error with "gauge" when I am adding 1D leads (Chains) to my 3D system. (I have both Chain leads, where I do not need gauge, of course, Could you please provide a minimal self-contained script that allows to reproduce the problem?
Christoph
Dear Sergey, That seems to be a bug in gauge that occurs when there are no hoppings within the lead unit cell. As a workaround I recommend to add hoppings connecting different 1D leads that have a magnitude of 0. I've opened an issue to track that: https://gitlab.kwant-project.org/kwant/kwant/-/issues/388 Best, Anton On Wed, 23 Sep 2020 at 17:44, Sergey Slizovskiy <sereza@gmail.com> wrote:
Dear Christoph, Here is the minimal example giving a error I described. The system is a 3-layer graphene and I add a couple of vertical 1D chains with small hopping to the main sample to model the STS tip. Thank you, Sergey
On 23/09/2020 15:52, Christoph Groth wrote:
Sergey Slizovskiy wrote:
I am having a error with "gauge" when I am adding 1D leads (Chains) to my 3D system. (I have both Chain leads, where I do not need gauge, of course, Could you please provide a minimal self-contained script that allows to reproduce the problem?
Christoph
Dear Anton, Thank you for your reply! I am unsure how to add hoppings between different leads. I am even surprised that this is possible to do. Or, did you mean adding extra fake "thickness" to a lead? Best wishes, Sergey On 23/09/2020 18:05, Anton Akhmerov wrote:
Dear Sergey,
That seems to be a bug in gauge that occurs when there are no hoppings within the lead unit cell. As a workaround I recommend to add hoppings connecting different 1D leads that have a magnitude of 0. I've opened an issue to track that: https://gitlab.kwant-project.org/kwant/kwant/-/issues/388
Best, Anton
On Wed, 23 Sep 2020 at 17:44, Sergey Slizovskiy <sereza@gmail.com> wrote:
Dear Christoph, Here is the minimal example giving a error I described. The system is a 3-layer graphene and I add a couple of vertical 1D chains with small hopping to the main sample to model the STS tip. Thank you, Sergey
On 23/09/2020 15:52, Christoph Groth wrote:
Sergey Slizovskiy wrote:
I am having a error with "gauge" when I am adding 1D leads (Chains) to my 3D system. (I have both Chain leads, where I do not need gauge, of course,
Could you please provide a minimal self-contained script that allows to reproduce the problem?
Christoph
You can make those different leads into a single one. Or add an extra site to each unit cell which has no hoppings to the next one, but a hopping within the unit cell. On Wed, 23 Sep 2020 at 20:21, Sergey Slizovskiy <sereza@gmail.com> wrote:
Dear Anton, Thank you for your reply! I am unsure how to add hoppings between different leads. I am even surprised that this is possible to do. Or, did you mean adding extra fake "thickness" to a lead? Best wishes, Sergey
On 23/09/2020 18:05, Anton Akhmerov wrote:
Dear Sergey,
That seems to be a bug in gauge that occurs when there are no hoppings within the lead unit cell. As a workaround I recommend to add hoppings connecting different 1D leads that have a magnitude of 0. I've opened an issue to track that: https://gitlab.kwant-project.org/kwant/kwant/-/issues/388
Best, Anton
On Wed, 23 Sep 2020 at 17:44, Sergey Slizovskiy <sereza@gmail.com> wrote:
Dear Christoph, Here is the minimal example giving a error I described. The system is a 3-layer graphene and I add a couple of vertical 1D chains with small hopping to the main sample to model the STS tip. Thank you, Sergey
On 23/09/2020 15:52, Christoph Groth wrote:
Sergey Slizovskiy wrote:
I am having a error with "gauge" when I am adding 1D leads (Chains) to my 3D system. (I have both Chain leads, where I do not need gauge, of course,
Could you please provide a minimal self-contained script that allows to reproduce the problem?
Christoph
Hi Anton and Christoph, I find a performance issue: for 6 leads with around 600 sites, and the scattering region with around 5000 sites the call gauge = kwant.physics.magnetic_gauge(sys) takes many minutes to run. So, the above command takes more time than the actual calculation that follows and more time than required to set up and plot the system. What is the expected size scaling of magnetic_gauge calculation? Best wishes, Sergey
Hi Sergey, I don’t know what’s the scaling of the magnetic_gauge. Dijkstra’s algorithm that is used internally has (for sparse graphs) something like O(N log N), but since that part is implemented in Cython it could well be that runtime is dominated by O(N) parts that are written in pure Python. Would you mind profiling your real-world-use example? If it’s a standalone script, just run it with python3 -m cProfile -o <script>.prof <script>.py And send the resulting <script>.prof file to this list, but please compress it first using ’xz -9’ and check that it’s not too big (not bigger than 250 k say). Thanks Christoph
Hi Christoph, Something strange happens... I have tried to reduce my system size to make a profiling run shorter, but still it's taking too long. I have only retained a call to "gauge" in the main code. Attached is profile 7z arxiv for a really small system with graphene trilayer of radius 5 with 6 leads attached. It still takes around a minute to run. Best wishes, Sergey On 24/09/2020 15:16, Christoph Groth wrote:
python3 -m cProfile -o <script>.prof <script>.py
Sergey, I’m a bit puzzled by the fact that your profile contains traces of Cython cdef functions. They shouldn’t be visible to the Cython profiler. Would you mind sharing the script that you profiled (or something equivalent, but then with another profile)? Cheers Christoph
Hi Christoph, Here is my code. I did all as you described, you may try to run it yourself. Must take around a minute. Best wishes, Sergey On 25/09/2020 10:51, Christoph Groth wrote:
Sergey,
I’m a bit puzzled by the fact that your profile contains traces of Cython cdef functions. They shouldn’t be visible to the Cython profiler. Would you mind sharing the script that you profiled (or something equivalent, but then with another profile)?
Cheers Christoph
Sergey Slizovskiy wrote:
Something strange happens... I have tried to reduce my system size to make a profiling run shorter, but still it's taking too long. I have only retained a call to "gauge" in the main code. Attached is profile 7z arxiv for a really small system with graphene trilayer of radius 5 with 6 leads attached. It still takes around a minute to run.
It’s normal that a program runs longer with profiling enabled. The slowdown is more pronounced if the inner loop(s) involve calls to short-running functions. However, in the case of your script, the amount of slowdown when profiling is enabled is indeed extreme. The inner loop (‘gauge’) consists of Cython code. I was surprised to see the individual cython-only functions of the ‘kwant.graph.dijkstra’ module appear in the profile. I now understand the reason for this: some time in 2016 I changed [1] the way that line tracing (a more precise form of profiling) can be enabled in Kwant build configuration. Due to an oversight, this permanently enabled regular profiling of Cython functions. To get more meaningful results I changed the value of ‘size’ in the call to ‘make_system’ at the bottom of your script to 8. With regular Kwant I measure a runtime of 77.7 s. With Cython profiling disabled by changing compiler_directives={'linetrace': True} to compiler_directives={'linetrace': False} in line 428 of setup.py and rebuilding Kwant, I measure 46.4 s. That’s nice to have, however it’s not yet the dramatic speedup that would enable you to treat much bigger systems. I have profiled your script (with ‘size=8’) and Kwant with disabled Cython profiling. The runtime of the script is now unchanged by the profiling. 97% of the runtime is now spent in the gauge submodule that appears as a monolithic block. So, it seems to me, that further speed up of gauge calculations will be difficult to obtain, unless there were some (unlikely, I believe) glitches in its implementation. It looks like automatic gauge calculation has a price and should be certainly avoided for big systems and simple magnetic fields. If you are unable to build your own Kwant with the above modification to setup.py, you will have to wait for a bugfix release that will correct this problem for everybody. I guess that we will make one in the next few weeks or so. Hope this was useful to you Christoph [1] https://gitlab.kwant-project.org/kwant/kwant/-/commit/10faf93a16bee7c596283d...
Thank you, Christoph, I have changed to two leads along x, which does not requre a use of "gauge" functionality in kwant. This has allowed me to go sizes of 30 with no problems. Probably, I need to account for Coulomb blockade physics to reach a better agreement with experiment. Anyway, it might be a tast for future development to improve the gauge algorithm, or, create a new, less general, but faster gauge procedure. Best wishes, Sergey On 28/09/2020 17:51, Christoph Groth wrote:
Sergey Slizovskiy wrote:
Something strange happens... I have tried to reduce my system size to make a profiling run shorter, but still it's taking too long. I have only retained a call to "gauge" in the main code. Attached is profile 7z arxiv for a really small system with graphene trilayer of radius 5 with 6 leads attached. It still takes around a minute to run. It’s normal that a program runs longer with profiling enabled. The slowdown is more pronounced if the inner loop(s) involve calls to short-running functions.
However, in the case of your script, the amount of slowdown when profiling is enabled is indeed extreme. The inner loop (‘gauge’) consists of Cython code. I was surprised to see the individual cython-only functions of the ‘kwant.graph.dijkstra’ module appear in the profile.
I now understand the reason for this: some time in 2016 I changed [1] the way that line tracing (a more precise form of profiling) can be enabled in Kwant build configuration. Due to an oversight, this permanently enabled regular profiling of Cython functions.
To get more meaningful results I changed the value of ‘size’ in the call to ‘make_system’ at the bottom of your script to 8. With regular Kwant I measure a runtime of 77.7 s. With Cython profiling disabled by changing
compiler_directives={'linetrace': True}
to
compiler_directives={'linetrace': False}
in line 428 of setup.py and rebuilding Kwant, I measure 46.4 s.
That’s nice to have, however it’s not yet the dramatic speedup that would enable you to treat much bigger systems.
I have profiled your script (with ‘size=8’) and Kwant with disabled Cython profiling. The runtime of the script is now unchanged by the profiling. 97% of the runtime is now spent in the gauge submodule that appears as a monolithic block.
So, it seems to me, that further speed up of gauge calculations will be difficult to obtain, unless there were some (unlikely, I believe) glitches in its implementation.
It looks like automatic gauge calculation has a price and should be certainly avoided for big systems and simple magnetic fields.
If you are unable to build your own Kwant with the above modification to setup.py, you will have to wait for a bugfix release that will correct this problem for everybody. I guess that we will make one in the next few weeks or so.
Hope this was useful to you Christoph
[1] https://gitlab.kwant-project.org/kwant/kwant/-/commit/10faf93a16bee7c596283d...
participants (3)
-
Anton Akhmerov
-
Christoph Groth
-
Sergey Slizovskiy