@pgbrodrick and @evan-greenbrg I walked through the two-albedo method and updated variable names. Also, I'm pretty sure that we can safely remove all the pi operations and simply calculate in radiance space. However, it'd be great if you could review the changes I introduced with commit 6fa4b6f.

Things execute through, and in radiance mode the solution space looks decent - but something in the initial guess is still off. In the figure below, early iterations of the state vector (red) show a terrible initial guess, and consequently a poor x_a, which then progress towards a better solution (blue), for this vegetated pixel. This suggests the calc_rdn function is working, but the something in the initial guess (when in radiance mode) is still off...just haven't tracked down what yet.

I think this is actually just because we're adjusting to transmittance, even if the units are in radiance. I think this if-wrapper will solve things

    if my_RT.rt_mode != "rdn":
        rdn_solrfl = units.rdn_to_transm(rdn_solrfl, coszen, solar_irr)

Testing....

Confirmed the above fix works:

Ah good catch, @pgbrodrick! We actually had that check in there before (see here), but accidentally removed it during our working session on Monday.

4 tests need to happen:

• radiance 1c
• radiance 4c
• transm 1c
• transm 4c
  Technically, repeat for different RTMs, but we can probably assume that one is sufficent.

Confirmed working on 1c - transmittance case.

Confirmed working on 4c - radiance case (with the KF emulator, technically a 2c model).

Reconfirmed 1c transm and rdn modes both work with new updates.

After troubleshooting and fixing the missing upwards transm in the invert_algebraic. Confirmed working on 4c transm.

Through consensus, and with discussion with the broader team, this is good to go.