add_atom/remove_atom functions, example with mutability?

[rkurchin]

Nothing should stop someone from having a subtype of AbstractSystem that's mutable, and it could be useful for setting up geometries for simulations, especially if they're rather large and the overhead of rebuilding a copy with one atom added/removed could be large.

I was thinking a few related things:

1. It would be nice to have an example (see Library of examples #50) for using AtomsBase for building geometries for, e.g., MD or DFT simulations.
2. For that purpose, having functions like add_atom and remove_atom that just return a copy of the system with an atom added/removed, would be useful. Or, if we make an example subtype of AbstractSystem that's actually itself mutable, we could also have add_atom! and remove_atom!, which could be nice for a larger system where the overhead of making the copy might be large.
3. This would also serve as another example of how easy interoperability is, since you'd presumably want to convert back to some immutable and package-specific system type to run your actual calculation.

I'm happy to mock up a basic version of this, but thought I'd open an issue for discussion in case people had other thoughts about it.

My main question is, do add_atom/remove_atom belong in AtomsBase itself, or should they (like, e.g. visualization-related functionality that's being worked on in Sclera) rather live in a separate package that people can depend on if they need it?

[cortner]

could this go into AtomsBuilder

[rkurchin]

Yes!