As explained in the energy usage model, developers gain energy either from freezing TRX to get dynamically-allocated energy (frozen / network total * total available, currently 100 billion), or from burning TRX directly to obtain fixed energy (currently 1 energy = 10 sun).
Under normal circumstances, both strategies should provide enough energy for smart contract deploy/execution. However, due to the way fee_limit is set up, if a developer freezes too much TRX for energy, this account's energy calculation is bound to the frozen model. The max energy this account can use is limited to fee_limit (up to 1000 TRX) / total network frozen TRX * 100 billion. If the upper bound is hit, an OUT_OF_ENERGY error will be thrown, without burning TRX. If the amount of energy frozen isn't too much, it is possible to combine both strategies to account for total used energy.
The specific formula is:
const R = Dynamic Energy Limit
const F = Daily account energy from freezing TRX
const E = Remaining daily account energy from freezing TRX
const L = Fee limit in TRX set in deploy/trigger call
const T = Remaining usable TRX in account
const C = Energy per TRX if purchased directly
// Calculate M, defined as maximum energy limit for deployment/trigger of smart contract
if F > L*R
let M = min(E+T*C, L*R)
let M = E+T*C
Developers can also use the user-friendly energy calculator to calculate the energy amount an account can use to deploy/execute smart contracts, and how much they will cost.
As general advice, developers are discouraged from freezing too much TRX (making it unfair for other developers). Otherwise, they are bound to the lower energy upper cap, rather than from burning TRX directly. If an account is in such a situation and a large contract needs to be deployed, try to either unfreeze some TRX or transfer TRX to a new account without frozen energy.
Updated about 5 years ago