Currently this is just the code that does the check, but is not integrated.

Great!
I was wondering if it's more realistic to take into account actual available memory (MemAvailable) instead of all physical memory, this way we can void intense swapping or being killed by the Out Of Memory killer... I guess that at the end the difference will be 1 qubit.

@nonhermitian is the intention of this PR to integrate it within QISKit? or just the tool and have an integration later, in another PR.

Actually, can we explore already existing options for retrieving system information before going with a custom implementation? There seem to be a number of popular ones that might be suited for our purposes (psutil, for example), and would most likely provide a more robust implementation (plus avoiding the burden of having to maintain platform-specific code ourselves).

On an unrelated note - pinging @ajavadia to make sure the licensing for the current file in the PR is fine (I wouldn't expect it to be an issue, but just in case)!

This is new BSD license (clause 3), which is compatible with our Apache 2.

It is waiting for other things to be finished, and then likely added to the validation part of the local simulators.

The code itself is from QuTiP, and has been used for a number of years now without many issues.

And indeed, you could drop the qubit count by one, but at least at the moment, I think that is probably unnecessary as the reported total memory is always just below a cutoff. In your case, 31.3 Gb rather than 32.

@atilag the intention is to make the local simulators check the size they can run rather than just have it hardcore to 30. This way if the user puts it on a bigger computer it can work.

The backends are now in aer, so this should be done there.

i agree