Incorrect parasitic capacitance Calibre-QRC Flow

As Andrew said, you may wish to contact tech support.  But the big picture on how QRC tech files are developed is this.

1. You start with a physical stackup for your process.  This defines the dielectric and conductor layers, thicknesses, effects like spacing and width on resistance, etc.  This is fed to the techgen program in "-simulation" mode.  The simulation runs a field solver on a huge bunch of cases and stores the results.  The run time can be quite long.  For older, say 180nm, processes, this isn't too bad.  As you shrink the process to anything close to modern, the input file becomes quite complex as more and more effects become significant.
2. Next you need to map layers that are generated and saved during the LVS process to the physical layers in your process along with any blocking.  For example it might be METAL2 in your LVS layers but M2 in the physical stackup.  There are a lot of considerations in getting this right that have to do with what is considered interconnect and what is considered part of a device.  But once this is all figured out you run techgen again but in "-compilation" mode to produce the actual techfile that an end user can use.  

The reason these two steps are broken up are the -simulation step only cares about the actual process and not the LVS flow and it may take a lot of compute time to complete.  The second step is much more in the domain of the EDA engineer writing the LVS deck.  The -compilation step runs much much faster and so if things change in the LVS deck you end up recompiling.  Or if you happened to have different layer names in Calibre LVS output versus PVS LVS output, you could compile for each without the cost of re-running -simulation.

So when you're missing a lot of capacitors and maybe the deck hasn't been proven yet, I suspect an incorrect layer mapping.  But the other even less involved check is that many times a foundry will have an LVS flag/switch to enable LVS for parasitic extraction and it turns on different features in the LVS deck that are not needed for LVS but are needed to support later parasitic extraction.  So if you had a flow that has been proven for other users but isn't working for some users, that is a big suspect.

As Andrew said, you may wish to contact tech support.  But the big picture on how QRC tech files are developed is this.

1. You start with a physical stackup for your process.  This defines the dielectric and conductor layers, thicknesses, effects like spacing and width on resistance, etc.  This is fed to the techgen program in "-simulation" mode.  The simulation runs a field solver on a huge bunch of cases and stores the results.  The run time can be quite long.  For older, say 180nm, processes, this isn't too bad.  As you shrink the process to anything close to modern, the input file becomes quite complex as more and more effects become significant.
2. Next you need to map layers that are generated and saved during the LVS process to the physical layers in your process along with any blocking.  For example it might be METAL2 in your LVS layers but M2 in the physical stackup.  There are a lot of considerations in getting this right that have to do with what is considered interconnect and what is considered part of a device.  But once this is all figured out you run techgen again but in "-compilation" mode to produce the actual techfile that an end user can use.  

The reason these two steps are broken up are the -simulation step only cares about the actual process and not the LVS flow and it may take a lot of compute time to complete.  The second step is much more in the domain of the EDA engineer writing the LVS deck.  The -compilation step runs much much faster and so if things change in the LVS deck you end up recompiling.  Or if you happened to have different layer names in Calibre LVS output versus PVS LVS output, you could compile for each without the cost of re-running -simulation.

So when you're missing a lot of capacitors and maybe the deck hasn't been proven yet, I suspect an incorrect layer mapping.  But the other even less involved check is that many times a foundry will have an LVS flag/switch to enable LVS for parasitic extraction and it turns on different features in the LVS deck that are not needed for LVS but are needed to support later parasitic extraction.  So if you had a flow that has been proven for other users but isn't working for some users, that is a big suspect.