Dear Christoph, Anton and Xavier, I also like to chime in and vote with Anton on this. What I try to do with Kwant is to build nanographene or polycyclic aromatic hydrocarbon (PAH) molecular structures by combining smaller structures/molecules, sometimes in a hierarchical way. With overwrite, when I fuse two benzene rings together I know I’ll get the 10-carbon naphthalene, instead of some 12-carbon beast with overlapping carbon atoms (and their hoppings). This is handy in the sense that it allows me to quickly build up any benzoic (i.e 6-membered rings) PAH molecular structures starting with benzene, say, without ever worrying about overlapped carbon atoms. Another aspect of it is that I usually plot the structure I build and make sure it looks OK, before I do anything with it. Now if we allow overlapped atoms (by default or choice), how would I tell which one it is from the plot (i.e. naphthalene vs. the 12-C structure)? Thanks. Chagaan
On Feb 4, 2016, at 5:26 PM, WAINTAL Xavier <xavier.waintal@cea.fr> wrote:
I'd tend to vote with Anton : until it actually proves dangerous can't we suppose it is safe? I can see many places where it can be very handy to overwrite. For instance is you use a system constructed by someone else and want to see the effect of modifying this and that.
________________________________________ De : Kwant-discuss [kwant-discuss-bounces@kwant-project.org] de la part de GROTH Christoph Envoyé : jeudi 4 février 2016 17:43 À : kwant-discuss@kwant-project.org Objet : [PROVENANCE INTERNET] Re: [Kwant] Should we disable implicit overwriting in Builder?
Anton Akhmerov wrote:
Firstly, overwriting hoppings is handy, and we even use it in Kwant tutorial: http://kwant-project.org/doc/1/tutorial/tutorial2#nontrivial-shapes
Sure it is handy. That’s why I don’t want to disallow it, only to make it explicit in order to avoid things getting overwritten by accident. The relevant line in the tutorial would become something like:
sys.rewrite(hops_across_cut, hopping_phase)
One could argue that this is more explicit, though perhaps a bit ugly. The question is whether the gain in security outweighs the loss in simplicity. I think it could, especially with complex symmetries.
Second aspect of the problem I wanted to mention is that we anyway discussed that the new low level system format would allow to associate more than a single value with a site or a hopping. That change would require a corresponding modification of the builder interface, however not sure in which fashion.
I actually encountered this problem today with Mathieu when we were writing a routine to wrap-around some hoppings (due to limitations of current Kwant low-level systems).
An updated builder could behave (always?) as a mapping of sequences of values, perhaps similar to a collections.defaultdict(list). Then, adding a new value would work like this:
sys[key].append(value)
or
sys[key] += [value]
We could still accept values that are not sequences, so that sys[key] = number/function would be possible. But that might be problematic since matrices are sequences, too.
I think a sequence is better than a set since it doesn’t leave the order of addition undefined. The order of addition doesn’t matter algebraically, but numerically it does.
The above looks a bit unmathematical, but it has the advantage of being consistent with the rest of Python. One could also make
sys[key] += value
work, but that would necessitate twisting the semantics in rather ugly ways:
sys[key] = value assert sys[key] is value # This would fail.
What do you think? (Comments by people outside of the Kwant team are especially welcome!)
Christoph