Inexplicable answer change

[samsrabin]

I'm having trouble understanding why this 3-line commit produces answer changes for the ERS_Ly5_P72x1.f10_f10_mg37.IHistClm45BgcCrop.cheyenne_intel.clm-cropMonthOutput test (as well as the gnu version). Does anyone have any ideas?

As a workaround, I can just get rid of repr_grainc_to_food_thispool, replacing it with (cpool_to_reproductivec(p,k) - repr_grainc_to_seed(p,k)) everywhere. This works but results in code duplication (not apparent in this commit, which I did while troubleshooting).

[billsacks]

It looks like an order of operations thing: algebraically equivalent code like this often leads to roundoff-level differences due to a different order of operations. In this case, I bet you could get bfb results if, in the baseline, you put parentheses around cpool_to_reproductivec(p,k) - repr_grainc_to_seed(p,k), forcing the compiler to evaluate that difference and then add the result to the first term, as opposed to executing this as (t1 * reproductivec(p,k) + cpool_to_reproductivec(p,k)) - repr_grainc_to_seed(p,k). However, if you have already done the work to verify that the answer changes in your branch are solely due to this commit, then I don't think you need to go to the trouble of looking further: I feel comfortable signing off on this as okay.