Commits on Oct 2, 2024

1. Workaround symengine serialization payload incompatibility (#13251) …

   * Workaround symengine serialization payload incompatibility
   
   In QPY we rely on symengine's internal serialization to represent the
   internal symbolic expression stored inside a ParameterExpression object.
   However, this format is nominally symengine version specific and will
   raise an error if there is a mismatch between the version used to
   generate the payload and what is trying to read it. This became an issue
   in the recent symengine 0.13 release which started to raise an error
   when people installed it and tried to load QPY payloads across the
   versions. This makes the symengine serialization unsuitable for use in
   QPY because it's supposed to be independent of these kind of concerns,
   especially when QPY is used in a server-client model where you don't
   necessarily control the installed environment of symengine.
   
   To correctly address this issue we'll need a new version of the QPY
   format that owns the serialization format of ParameterExpressions directly
   instead of relying on symengine which doesn't offer a compatibility
   guarantee on the format. However this won't be quick solution and users
   are encountering issues since the release of 0.13. This commit
   introduces a workaround for this specific instance of the mismatch. It
   turns out the payload format between 0.11 and 0.13 is completely
   unchanged except for the version number. So before passing the parameter
   expression payload to symengine for deserialization this commit checks
   the versions numbers are the same, if they're not it checks that we're
   dealing with 0.11 or 0.13, and if so it changes the version number in
   the payloads header appropriately. If the version number is outside
   those bounds it raises an exception because while this hack is known to
   be safe for translating between symengine 0.11 and 0.13, it's not
   possible to know for a future version whether the payload format changed
   or not.
   
   Longer term we will need a proper fix in qpy version 13 that introduces
   a qiskit native serialization format for parameter expression instead of
   relying on symengine or sympy to do it for us.
   
   * Handle schedules too
   
   This commit updates the schedule serialization path too, as it was also
   directly loading symengine expressions. The code handling the workaround
   is extracted to a standalone function which is used in both spots now
   instead of calling symengine directly.
   
   * Remove unused imports
   
   * Gracefully handle failure to parse historical symengine files
   
   During the discovery on the fix in this PR we discovered that setting
   the ``use_symengine`` flag from Qiskit 0.45.x and 0.46.x would result in
   newer versions of Qiskit being unable to parse the QPY file for the same
   issue as being addressed here. This commit expands the logic to account
   for this and raise a useful warning. It also updates the release notes
   and documentation to document these limitations.
   
   * Cap upper version of symengine in requirements list
   
   Out of an abundance of caution this commit places a cap on the allowed
   version of symengine users can install to be compatible with Qiskit.
   Due to the symengine version dependence discovered in QPY around
   serializing ParameterExpressions, we'll likely have a similar issue
   when symengine 0.14.0 releases. Pre-emptively capping this means we
   aren't going to be in this situation until we can confirm compatibility
   with QPY serialization. The real solution for this will come in #13252,
   although as this behavior is embedded in QPY formats 10, 11, and 12 at
   this point we'll have to handle this edge case moving forward regardless
   of whether we introduce a better solution in 1.3.0 or not. Although
   realistically in that case we will likely need to just document this as
   a limitation when exporting QPY payloads with Qiskit 0.45.0 through
   1.2.3 (and with the ``version`` flag set to >= 10 and < 13) and have
   explicit error checking around the symengine version (which this PR
   adds) when in that code path.
   
   * Fix release note upgrade section label
   
   * Rewrite support documentation
   
   * Fix mistakes in release note
   
   Co-authored-by: Matthew Treinish <mtreinish@kortar.org>
   
   ---------
   
   Co-authored-by: Jake Lishman <jake.lishman@ibm.com>
   Co-authored-by: Jake Lishman <jake@binhbar.com>
   (cherry picked from commit fee9f77)

   

   mtreinish authored and mergify[bot] committed Oct 2, 2024
   Configuration menu

   • View commit details
   • Copy full SHA for 5179fad
   • Browse repository at this point

   Copy the full SHA

   5179fad View commit details

   Browse the repository at this point in the history

2. Fix symengine typo

   

   jakelishman committed Oct 2, 2024
   Configuration menu

   • View commit details
   • Copy full SHA for a20ec98
   • Browse repository at this point

   Copy the full SHA

   a20ec98 View commit details

   Browse the repository at this point in the history