Bug in 1D CPM Discretization for MCC3

I am looking over the code for running MCC-3 with "detailed" heterogeneous treatment, and I am finding some inconsistencies with how the 1D geometry is defined. Looking at the following code in get_1d_geometry_opt2, all radial regions go from outside in and then inside out, where the equivalent radius from half of the current region's area is computed:

for sub_pin_rad in reversed(sorted(subpin_rad.keys())):
    mat = subpin_rad[sub_pin_rad][0]
    inner_rad = subpin_rad[sub_pin_rad][1]
    outer_rad = sub_pin_rad

    if ring_index ==0 :
        new_area = nb_pins * math.pi * outer_rad**2
        area.append([new_area, mat])
    else:
        new_area = area[-1][0] + nb_pins * math.pi * (outer_rad**2 - inner_rad**2) / 2
        area.append([new_area, mat])
for sub_pin_rad in sorted(subpin_rad.keys()):
    mat = subpin_rad[sub_pin_rad][0]
    inner_rad = subpin_rad[sub_pin_rad][1]
    outer_rad = sub_pin_rad
    if ring_index > 0:
        new_area = area[-1][0] + nb_pins * math.pi * (outer_rad**2 - inner_rad**2) / 2
        area.append([new_area, mat])

Then at the end of each for loop looping over all rings in the pin lattice, the following code is added on:

area.append([(1+3*ring_index*(ring_index+1)) * self.user_object.get_section_surf(sub_assembly.hex_lattice.pitch.value),mat_outer])  # At each ring, we add the outer material.

This would imply that if we had a fuel pin with "fuel clad sodium", the order of the regions would be

Ring 1 - fuel clad sodium

which is expected, but for Ring 2 onwards, each ring would have

Ring 2 onwards - clad fuel fuel clad sodium,

where all regions would have half the equivalent volume except for the sodium, which has the full equivalent volume. Talking this over with Changho and Hansol, who have run similar models with MCC3 directly, it seems as though the correct order should be

Ring 2 onwards - sodium clad fuel fuel clad sodium

where half of the sodium volume is also added at the beginning and end of the regions

@nstauff can you confirm this is indeed incorrectly coded?