Pol Febrer Calabozo

> And then you still need to really convince that this package is better than doing packagea - > ase - > packageb. Ase is already standard in DFT codes...

Nice, that would definitely be the best scenario. It would be helpful for plots to make animations too (I already implemented it with my own approach, but if there is...

Hi Nick, there's not much I can add to the discussion because I have very little experience, sorry :) But I think it would be great that in general you...

I like the `sp2` constructor in the Hubbard code. Perhaps it (or something like it) could be available in sisl and return a function that you can pass to `Hamiltonian.construct()`....

Hmm I guess if `orbitals` accepts categories, there would already be a `OrbitalAtoms` category or something like that which would be used with the `atoms` keyword. So you should be...

If you have an `atoms` argument, would you accept orbital indices in `orbitals`? What would these indices represent? I.e. would you first do a `geometry.sub(atoms)` and then get the orbitals,...

Hmm I'm not sure I understand the issues completely. I still don't understand the advantages of having `atoms` as a prefilter instead of just having an `OrbitalCategory` that can filter...

I think there would just be an `OrbitalCategory` called `OrbitalAtoms`, which accepts the `atoms` argument and on categorize just sanitizes it with `Geometry._sanitize_atoms`. Then you could combine this one with...

> But the internal algorithm will the need to distinguish the two arguments... No, why? Just as you can do `atoms={"fx": (0, 0.5)}` because there's an `AtomCategory` called `AtomFx`, you...

It would be nice indeed, well played hahah. These two would probably ease some operations, because I've had some trouble trying to relate orbitals with atoms in my code.