Change EmuTN default sampling rate

[lvignoli]

The default sampling rate, inherited from EmulatorConfig defaults, is 1.

If I am not mistaken, this translates to dt=1 for the EmuTN job runned by cloud services, which is not a viable value.

I open this MR not for a blind merge, but rather to make sure the above interpretation of sampling_rate for EmuTnBackend is right, and reflect on a good default value.

[awennersteen]

Actually this might not be sufficient, EmuTN does not use a sampling rate but rather dt, so I think maybe this interface isn't correct. I've not really reviewed or used it so not sure.

EmuTN uses a dt value which is the time in nanoseconds of the timestep used during integration. the default value is 10, and indeed 1 is very low for most purposes. a value < 1 is also not permitted (it must be a a positive integer)

[HGSilveri]

There is an internal conversion from sampling_rate to dt: dt = 1/ sampling_rate. So, dt is never < 1. If having dt=10 is a better default than dt=1, then I'm okay with changing the default sampling rate to 0.1, as this PR suggests.

[lvignoli]

The default value for for dt in EmuTN (the -t flag) is 10.0, so I would say sampling_rate=0.1 is a saner default.

[HGSilveri]

@awennersteen Can dt assume a non-integer value?

[lvignoli]

The docstring should be updated to reflect the fact that sampling_rate must be quite small for EmuTNBackend (<= 1e-1) to use the backend properly.

[HGSilveri]

The default value for for dt in EmuTN (the -t flag) is 10.0, so I would say sampling_rate=0.1 is a saner default.

My original intention with EmulatorConfig was to uniformize all the emulator configs as much as possible (with the rationale that switching the EmulatorBackend while keeping the default config should introduce as few changes as possible).

That being said, I'm not opposed to this change, I'll defer to your judgement on it.

[HGSilveri]

The docstring should be updated to reflect the fact that sampling_rate must be quite small for EmuTNBackend (≥ 1e-1) to use the backend properly.

Do you mean <= 1e-1? And what do you mean by "properly"?

[lvignoli]

Yes, smaller than, I edited the comment.

Properly here meaning with acceptable default runtime.

[lvignoli]

I understand the original motivation for having some homogeneity in the parameters across the backends.

But since different backends serve different purposes, one cannot expect parameters to have the same impact. So it is not a huge loss—to me, at least!

[HGSilveri]

Yes, smaller than, I edited the comment.

Properly here meaning with acceptable default runtime.

Ok, gotcha, feel free to add this info to the docstring.

[awennersteen]

@awennersteen Can dt assume a non-integer value?
apparently yes. I was speaking out of habit way in the past when it was an integer. I just checked and we expect a float.

as Louis says setting sampling_rate so that dt=10 is much better, and most uses cases will want such a timestep. dt=1 would be quite exceptional

[lvignoli]

@HGSilveri some test are failing about "good arguments", I am not sure how to fix them.

[HGSilveri]

@HGSilveri some test are failing about "good arguments", I am not sure how to fix them.

You have to change this line:

Pulser/tests/test_pasqal.py

Line 324 in 2315989

sdk_config = EmuTNConfig(dt=1.0)

[HGSilveri]

LGTM, thanks!

[HGSilveri]

Oh damn, the new matplotlib release has type hints 😨