Redundant assignments in WSM6 v7

[cponder]

The file

src/core_atmosphere/physics/physics_wrf/module_mp_wsm6.F

has some assignments that get re-assigned without being used in between.

In the case of redundant or inactive control-flow statements, I'm inclined to assume that the developers intend to fill in additional cases in the future.
But with assignments I suspect that this is an oversight from when the code was updated from an earlier version.

[cponder]

These 2nd- & 3rd- order interpolations here

   1959 ! plm is 2nd order, we can use 2nd order wi or 3rd order wi
   1960 ! 2nd order interpolation to get wi
   1961       wi(1) = ww(1)
   1962       wi(km+1) = ww(km)
   1963       do k=2,km
   1964         wi(k) = (ww(k)*dz(k-1)+ww(k-1)*dz(k))/(dz(k-1)+dz(k))
   1965       enddo
   1966 ! 3rd order interpolation to get wi
   1967       fa1 = 9./16.
   1968       fa2 = 1./16.
   1969       wi(1) = ww(1)
   1970       wi(2) = 0.5*(ww(2)+ww(1))
   1971       do k=3,km-1
   1972         wi(k) = fa1*(ww(k)+ww(k-1))-fa2*(ww(k+1)+ww(k-2))
   1973       enddo
   1974       wi(km) = 0.5*(ww(km)+ww(km-1))
   1975       wi(km+1) = ww(km)

and here

  2202 ! plm is 2nd order, we can use 2nd order wi or 3rd order wi
   2203 ! 2nd order interpolation to get wi
   2204       wi(1) = ww(1)
   2205       wi(km+1) = ww(km)
   2206       do k=2,km
   2207         wi(k) = (ww(k)*dz(k-1)+ww(k-1)*dz(k))/(dz(k-1)+dz(k))
   2208       enddo
   2209 ! 3rd order interpolation to get wi
   2210       fa1 = 9./16.
   2211       fa2 = 1./16.
   2212       wi(1) = ww(1)
   2213       wi(2) = 0.5*(ww(2)+ww(1))
   2214       do k=3,km-1
   2215         wi(k) = fa1*(ww(k)+ww(k-1))-fa2*(ww(k+1)+ww(k-2))
   2216       enddo
   2217       wi(km) = 0.5*(ww(km)+ww(km-1))
   2218       wi(km+1) = ww(km)

It looks like the wi array gets written and then gets completely over-written.
It is never used as an Rval in any expression in between.

[cponder]

In the refl10cm_wsm6 subroutine this array is assigned at the top

   2434       do k = kts, kte
   2435          dBZ(k) = -35.0
   2436       enddo

and then re-assigned at the bottom

   2569       do k = kte, kts, -1
   2570          dBZ(k) = 10.*log10((ze_rain(k)+ze_snow(k)+ze_graupel(k))*1.d18)
   2571       enddo

across the same index-range, and it doesn't appear in any expression in between.
This array is being passed as a parameter to the refl10cm_wsm6 subroutine so it may be visible under different names, though.
There are these two subroutine-calls

   2535               call rayleigh_soak_wetgraupel (x,DBLE(xocms),DBLE(xobms), &
   2536                     fmelt_s, melt_outside_s, m_w_0, m_i_0, lamda_radar, &
   2537                     CBACK, mixingrulestring_s, matrixstring_s,          &
   2538                     inclusionstring_s, hoststring_s,                    &
   2539                     hostmatrixstring_s, hostinclusionstring_s)

and

   2555               call rayleigh_soak_wetgraupel (x,DBLE(xocmg),DBLE(xobmg), &
   2556                     fmelt_g, melt_outside_g, m_w_0, m_i_0, lamda_radar, &
   2557                     CBACK, mixingrulestring_g, matrixstring_g,          &
   2558                     inclusionstring_g, hoststring_g,                    &
   2559                     hostmatrixstring_g, hostinclusionstring_g)

I can't easily tell if one of the parameters is an indirect reference to the dBZ array or if the body of the rayleigh_soak_wetgraupel can access it as a module variable somehow.