Ordering of output of `external_indices`

[obackhouse]

Can I ask for clarification on the grouping in external_indices? The nested vector is constructed as

SeQuant/SeQuant/core/utility/indices.hpp

Lines 470 to 478 in e5543da

	for (std::size_t i = 0; i < groups.ket.size(); ++i) {
	cont.at(i).push_back(groups.ket[i]);
	}
	for (std::size_t i = 0; i < groups.bra.size(); ++i) {
	cont.at(i).push_back(groups.bra[i]);
	}
	for (std::size_t i = 0; i < groups.aux.size(); ++i) {
	cont.at(i).push_back(groups.aux[i]);
	}

Is there a reason this is not

for (std::size_t i = 0; i < groups.ket.size(); ++i) { 
  cont.at(0).push_back(groups.ket[i]); 
} 
for (std::size_t i = 0; i < groups.bra.size(); ++i) { 
  cont.at(1).push_back(groups.bra[i]); 
} 
for (std::size_t i = 0; i < groups.aux.size(); ++i) { 
   cont.at(2).push_back(groups.aux[i]); 
}

This would return [[bra0, bra1, ...], [ket0, ket1, ...], [aux0, aux1, ...]] rather than [[bra0, ket0, aux0], [bra1, ket1, aux1], ...]. The former implicitly carries the bra/ket/aux ranks, whereas the latter does not, which makes it difficult to construct an appropriate output tensor when the ranks are not equal.

EDIT: Just noticed it's also ket, bra, aux rather than bra, ket, aux too?

[evaleev]

I am sure this is not what should happen.

the purpose of external groups is to constrain indices to have same m_s/"spin". Most of the time bra and ket indices in same "column" (column bundle of slots) share spin (this is true for spin-conserving/free operators). But each aux indices is in its own bundle. so expect the default to produce [[bra0, ket0], [bra1, ket1], .... [aux0], [aux1] ...].

@Krzmbrzl looks like you last touched this, do you agree?

[obackhouse]

ah that would make sense -- but also then for e.g. EOM vectors you could have

[[bra0, ket0], [bra1]]

and

[[bra0, ket0], [ket1]]

which causes some ambiguity.

[Krzmbrzl]

looks like you last touched this, do you agree?

Yes, this currently doesn't do the right thing.

EDIT: Just noticed it's also ket, bra, aux rather than bra, ket, aux too?

Indeed - as long as the ordering is consistent (which it seems to be), that's not an issue but for us fellow humans it would probably be nicer to have the order bra, ket.
EDIT: The ordering does in fact end up being important (due to the way the result of this function is used throughout SeQuant).

For the non-covariant case, my assumption is that it simply hasn't been tested/used yet. @evaleev would have to comment on that. This might be in the regime of "we need better handling of external indices in expressions"