I feel like there should still be a way to resize a vector to the exact capacity that is asked for. Only if the vector is used in a particle container with multiple tiles where particles are exchanged using a thermal process is this a good strategy. If there is only one tile or if the vector is used to store a grid or metadata, the extra capacity is not needed.

What's the downside?

Just a waste of (a little bit of) memory. It also could get very confusing when trying to implement custom allocation size strategies on top of PODVector.

Because it scales as sqrt(n), the extra memory cost is not an issue. As for implementing other growth strategies such as what are in #4735 , here is what I think. push_back and insert are rarely used and should not be used for GPU codes anyway. We probably do not care about constructors either. So our focus should be on just resize and reserve. In this PR, the growth strategy is implemented in function grow_podvector_capacity. It should not be hard at all to allow other strategies. In the current PR, grow_podvector_capacity is being used in 4 places. All we need is to have an extra parameter to the function, and the parameter can be obtained from the resize and reserve function as it's already being done in #4735. Re: ParmParse parameters in #4735, I think it's better to have them in particle containers, not in the vector class. I think that would be much more flexible and less confusing by having a fixed default in the vector and the change needs to be explicit. I think the default in vector should be that we have a little bit extra that scales as sqrt(n), because that cost is really not that much.

Sounds good. I am fine with merging this PR as is, and after that I will make a follow-up to add exact and geometric strategies to resize and reserve only, using grow_podvector_capacity. I also agree that those are the most important functions, and insert/push_back shouldn't really be used. Should the interface for resize and reserve include an optional argument or add new funcitons?

Option 1:

vec.reserve(n, amrex::GrowthStrategy::Geometric);
vec.resize(n, amrex::GrowthStrategy::Exact);
vec.resize(n /*, amrex::GrowthStrategy::Poisson*/); // Poisson is the default

Option 2:

vec.reserve_geometric_grow(n);
vec.resize_exact_grow(n);
vec.resize(n); // uses Poisson grow

Option 3:

vec.reserve_geometric(n);
vec.resize_exact(n);
vec.resize(n); // uses Poisson grow

I prefer Option 1. It's easier for the users.