Please request review from me once both #2663 is in and all merge conflicts are resolved.

All fixed up after Jonathon round 1 review.

long int? Why not just size_t which is quite literally the size type.

long int? Why not just size_t which is quite literally the size type.

No reason, I guess. Some modules used long int before we went on a size_t fest a few years ago. I can switch them (and update the printouts from MB to GB) if folks concur. It would be shorter.

long int? Why not just size_t which is quite literally the size type.

Sure, size_t would work equally well. Having a Fortran background, i chose long long int as it is guaranteed to have 64 bits on any platform. Feel free to change.

Edit: OTOH, as naoccA, naoccB, nQ etc. are all signed integers, it is guaranteed that there will be no representation problems is someone assigns negative values to these (OK, why would you do so, but still) when long long is used as opposed to size_t.

My one request is that variables that are obviously used for indexing/lengths be size_t.

Just be super careful if there are any subtractions; the result of subtracting two unsigned quantities is itself unsigned and, if negative, it'll wrap around and give garbage. Therefore things like if (A - B > tol) should be if (A > B + tol). Probably not relevant for this case, but keep in mind that OpenMP loop iteration variables must be signed.

Ideally, I suppose, the variables should become size_t from the start. As already touched upon here #1764 (comment)

After wading into size_t guidance, the dangers of mixed signed/unsigned, and the deeper troubles of #1764 that need changes to the tensor classes, not just the dfocc.h ints, and not just the memory estimates, I think the long long int serves nicely for now.