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 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