** Thinking about owning_ptr:

-- good for things like:

	 my_ptr = passed_in_class.clone()

	 where we need to copy some external data

	 and of course to hold returns from factory classes...

	 perhaps big, shared data like atomsets, residuesets, and etables
	 shouldn't be held in smart pointers?



** Setting things:

	 pose.set_jump( 3, jump ) vs atom.jump( jump )

	 since pose has multiple jumps, atom only one

	 same goes for xyz,dof,etc...



** Think: what is the role of the fold_tree?? This is where the information
	 on jump numbers is... no jump numbers in the atomtree, just indexed
	 by AtomID's of the downstream atom... This is a useful short-hand for
	 describing	an AtomTree, can even specify anchor and root atoms for jump
	 connections. So will it always be the case that fold_tree --> atom_tree ?
	 not in the case of more complicated atomtrees, eg to handle backrub motion.
	 so maybe fold_tree plus a discrete additional set of information? Right,
	 and I guess the ResidueFolder class can hold the fold_tree plus the extra
	 info, making it possible to reconstitute the atom_tree if necessary...
	 
								




