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 <[email protected]> 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 [[email protected]] de la part de > GROTH Christoph > Envoyé : jeudi 4 février 2016 17:43 > À : [email protected] > 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
