`lithosim.sim(image)` returns near-zero values instead of expected aerial/printed intensities

[thomashirtz]

Description

I cloned the lithobench repository, created a fresh virtual environment, installed all requirements, and ran the example script without modifying any code. While calling the module via lithosim(image) output low uniform values, calling lithosim.sim(image) produces what seems to be the right image, but with extremely low values (max aerial ≈2.5e-14, max printed ≈1.3e-5), which seems incorrect.

---

Inside \lithobench\pylitho\exact.py :

 if __name__ == "__main__":
     import pycommon.glp as glp

     lithosim = LithoSim("./config/lithosimple.txt")
     image = glp.Design("./benchmark/ICCAD2013/M1_test1.glp").image()
     image = torch.tensor(image > 0.0, dtype=REALTYPE, device=DEVICE)
     printed = lithosim.sim(image)

     aerialNom, aerialMax, aerialMin, printedNom, printedMax, printedMin = lithosim.sim(image)
     print(aerialNom.min(), aerialNom.max(), printedNom.max(), printedNom.min())
     # tensor(1.0319e-19) tensor(2.4753e-14) tensor(1.3007e-05) tensor(1.3007e-05)

     import matplotlib.pyplot as plt

     plt.subplot(1, 2, 1)
     plt.imshow(image.detach().cpu().numpy())
     plt.subplot(1, 2, 2)
     plt.imshow(printed[0].detach().cpu().numpy())
     plt.show()

---

Expected Behavior

• Both lithosim(image) and lithosim.sim(image) should return aerial and printed intensity maps with realistic dynamic range (e.g. values on the order of 0–1 after sigmoid for printed output, and non-zero aerial values). The aerial values do not seem to be high enough to trigger the sigmoid.

---

Actual Behavior

• lithosim(image) return uniform image of value ≈1.3e-5.
• lithosim.sim(image) returns the right shape but with values that are effectively zero.

Thank you for your help!

[thomashirtz]

Update: the code for the exact simulation is able to handle any size except 2048x2048. It can handle 1024, 2047, 2049, ... but not the standard resolution of the input image used for the test.

The issue seems to come from the computation of the fft, if I change the size 2047 to 2048, the magnitude of cmask_fft and tmp will drastically change in _computeImageMask when computing torch.fft.fft2 and torch.fft.ifft2. If I change the norm to None, it fixes the issue to this specific problem and seems to work. However, I am not sure what is the specific reason to have put a normalization in the first place, moreover there are other places in the code where the normalization occurs, and I am not sure if those places need to change as well. I suppose the same issue of colapse can happen in the backward pass when _computeImageMatrix is used.

def _computeImageMask(cmask, kernel, scale, kernelNum):
    # cmask: [2048, 2048], kernel: [24, 35, 35], scale: [24]
    if scale.device != cmask.device:
        scale = scale.to(cmask.device)
    cmask = torch.unsqueeze(cmask, len(cmask.shape) - 2)
    cmask_fft = torch.fft.fft2(cmask, norm=None) # issue here
    tmp = _kernelMult(kernel, cmask_fft, kernelNum)
    tmp = torch.fft.ifft2(tmp, norm=None) # issue here
    return tmp