CaloTower hash off by one?

[nsmith-]

In checking data/emulator comparisons for Layer1, I noticed that the requested indexing hash CaloTools::caloTowerHash() seems to skip an entry at 4032.
It also seems to include ieta +/- 29 between 4896 and 5041.
Is this expected?

Calo hash ieta -41 iphi 1 = 4033
... (sequential)
Calo hash ieta -30 iphi 72 = 4896
Calo hash ieta -28 iphi 1 = 0
... (sequential)
Calo hash ieta 28 iphi 72 = 4031
Calo hash ieta 30 iphi 1 = 5041
... (sequential)
Calo hash ieta 41 iphi 72 = 5904

This means that caloTowerHash(41, 72) == caloTowerHashMax()

[nsmith-]

Also, is this the preferred sort condition for l1t::CaloTowerBxCollection ?

[nsmith-]

Also, BXVector::resize(bx, n) actually resizes to n+1 elements.

For now I will use the underlying std::vector::reserve function to preallocate

[jimbrooke]

Just to confirm - the intention is to set the calo tower at (ieta, iphi) to be at vector index caloTowerHash(ieta, iphi). Example in the dummy producer here
https://github.com/cms-l1t-offline/cmssw/blob/l1t-integration-CMSSW_8_0_2/L1Trigger/L1TCalorimeter/plugins/L1TStage2Layer1Producer.cc#L208

I see the unpacker in l1t-integration-802 does not behave like this. Looks like this is due to a fix being forgotten in the old days before we submitted PRs to l1t-integration. I'll make a new PR correcting this.