Force on wall/lj93 does not change with time

Dear lammps users,
I was using f_fwall[*] to get the forces exerted on wall/lj93, but I found the value does not change with time.

Step c_t v_zdist v_zdrive v_pr1 v_pr2 v_pr3 f_fwall[1] f_fwall[2] f_fwall[3] f_fwall[4]
0 298 81.941047 103.09617 1136276 1447179.8 1369407.9 15.197814 -12.728382 50.703193 -56.326292
100 21199.473 81.941047 103.09617 241536.35 277215.14 255536.62 15.197814 -12.728382 50.703193 -56.326292
200 16758.428 81.941047 103.09617 187999.93 207400.36 204587.63 15.197814 -12.728382 50.703193 -56.326292
300 13372.057 81.941047 103.09617 159565.01 147590.48 160331.22 15.197814 -12.728382 50.703193 -56.326292
400 10739.595 81.941047 103.09617 125834.37 124951.71 129103.96 15.197814 -12.728382 50.703193 -56.326292

The lammps version was 8Apr2021-mpi on Windows Server 2016. After then I installed a serial version of 3March2020 on my laptop. I used the same input data except that the comm_style was changed from tiled to brick because this old version does not support tiled style with pppm. Then the output force on wall/lj93 changed.

Step c_t v_zdist v_zdrive v_pr1 v_pr2 v_pr3 f_fwall[1] f_fwall[2] f_fwall[3] f_fwall[4]
0 298 81.941047 103.09617 1136276 1447179.8 1369407.9 15.197814 -12.728382 50.703193 -56.326292
100 21199.473 81.941047 103.09617 241536.35 277215.14 255536.62 19.248163 -11.598518 -609.34976 11773.572
200 16758.428 81.941047 103.09617 187999.93 207400.36 204587.63 -28.650024 52.415455 -8152.5949 7377.634
300 13372.057 81.941047 103.09617 159565.01 147590.48 160331.22 -587.7561 239.23463 -4344.0942 6974.3868
400 10739.595 81.941047 103.09617 125834.37 124951.71 129103.96 -609.3452 755.80875 -2880.5104 7373.0567
500 8836.4187 81.941047 103.09617 103520.31 101744.64 98287.898 -119.89185 668.88305 -3139.0851 5791.9211

Can I infer that this is a bug on the new version or I just used it in a wrong way?

Please provide a minimal and fast to run input deck that reproduces the issue. It is impossible to tell if there is a bug or not without being able to reproduce it.

My origin system was a bit complex and I tried another simple one. The problem still exists.
in.opc.lmp (934 Bytes)
water.data (23.9 KB)
The box contains 64 water molecules. Two walls are set near the boundary in x direction.
With lammps version of 3Mar2020, the log file is

Step Temp Press Density Volume f_fleft[1] f_fright[1]
0 298 220803.55 0.59130737 3237.8718 4.5506766 -4.8530842
100 4646.3158 39963.554 0.59130737 3237.8718 2.0894892 -4.9156528
200 4078.5565 33180.164 0.59130737 3237.8718 -1.0359303 3.3687448
300 3074.9318 36917.188 0.59130737 3237.8718 -0.15238336 147.01295
400 2713.0527 28013.14 0.59130737 3237.8718 -32.533096 404.27385
500 2394.8211 23917.815 0.59130737 3237.8718 -206.13321 26.10915

With lammps version of 8Apr2021-mpi, the log file is

Step Temp Press Density Volume f_fleft[1] f_fright[1]
0 298 220803.55 0.59130737 3237.8718 4.5506766 -4.8530842
100 4646.3158 39963.554 0.59130737 3237.8718 4.5506766 -4.8530842
200 4078.5565 33180.164 0.59130737 3237.8718 4.5506766 -4.8530842
300 3074.9318 36917.188 0.59130737 3237.8718 4.5506766 -4.8530842
400 2713.0527 28013.14 0.59130737 3237.8718 4.5506766 -4.8530842
500 2394.8211 23917.815 0.59130737 3237.8718 4.5506766 -4.8530842

Thanks for the input deck. This is a legitimate bug. It must have been introduced in early 2021.
A bugfix will be included in the next patch release.