Unexpected result after CKKS-to-FHEW switching with multiplicativeDepth=1 and FIXEDAUTO

Bug Reports
1

”Unexpected result after CKKS-to-FHEW switching with multiplicativeDepth=1 and FIXEDAUTO”

Hello OpenFHE developers,

I am testing CKKS-to-FHEW scheme switching with the following configuration:

  • OpenFHE version/commit: OpenFHE 1.5.1, commit ed361af22049007db2107e7c69bcff209e8c420d (git describe: v1.5.1-1-ged361af2)

  • OS and compiler: Ubuntu 24.04.4 LTS (x86_64, Linux kernel 6.8.0-138-generic), GCC/G++ 13.3.0

  • CKKS security level: HEStd_128_classic

  • FHEW security level: STD128

  • multiplicativeDepth = 1

  • scalingTechnique = FIXEDAUTO

  • firstModSize = 40

  • scalingModSize = 20

  • Actual ring dimension: 8192

  • Batch size: 4096

  • Number of converted slots: 900

  • logQ_ccLWE = 15

  • LWE plaintext modulus: pLWE = 128

  • CKKS-to-FHEW precomputation scale: 1.0 / pLWE

As a minimal test, I pack 10.0 into 900 slots of each of two CKKS ciphertexts and add them using EvalAdd. The expected value in each slot is therefore 20.0.

CKKS decryption immediately after the addition gives approximately 20.0004. However, after EvalCKKStoFHEW and FHEW decryption modulo 128, all 900 converted values in this run are 19 rather than 20.

I have the following questions:

  1. Is CKKS-to-FHEW scheme switching expected to support multiplicativeDepth = 1 with FIXEDAUTO when the CKKS computation before switching contains only an addition?

  2. Is a one-unit difference such as 19 instead of 20 an expected approximation or rounding effect, or does it indicate a scaling or modulus configuration problem?

  3. Are there documented compatibility constraints or recommended ranges involving firstModSize, scalingModSize, the CKKS modulus, logQ_ccLWE, and pLWE?

  4. If this result is not expected, which part of the configuration should I investigate first?

Thank you.