data: fix eastern dfo prices (and floating point cruft)

[ghost]

This change fixes the dfo fuel prices in the Eastern interconnection, which had all previously been set at 0. Consequently, the cost curves for all dfo generators were also set to 0, leading to an unrealistic base-loading of these generators in any optimization run that includes eastern.

To fix this, I looked at 2016 average spot prices of 'Ultra-Low-Sulfur No. 2 Diesel Fuel' at the New York Harbor trading hub (I used ULS No. 2 Diesel rather than No. 2 Heating Oil with the assumption that large generators would be subject to SOx restrictions and would need to buy the low-sulfur fuel, but in either case it only adds ~5% to the price).
https://www.eia.gov/dnav/pet/pet_pri_spt_s1_d.htm

At an average price of $1.355/gallon and an average energy content of 137,381 Btu/gallon, the effective price per MMBtu is $9.8635.
https://www.eia.gov/energyexplained/units-and-calculators/

This price replaced the previous 0 price in the USAGenbus_aux.pkl file, and the heat-rate curve polynomial coefficients (MMBTu/MWh as a function of MW generated) in the aux file were used with this new fuel price to create new cost curve coefficients ($/MWh as a function of MW generated).

The new linear costs are universally $79.07/MWh, (due to universal linear heat rate coefficients in the original USAGenbus_aux.pkl file), which should limit these resources to peaker operation only, as they are typically used today.

In the process of writing these new cost curve coefficients to gencost_case.csv, some previous floating point cruft was inadvertently cleaned as well (e.g. '0.090000000002' -> '0.09').

[rouille]

I trust you

[BainanXia]

I've read through the notebook and checked the corresponding changes in the gencost.csv file. It looks good in general :). Some minor concerns as following:

1. 1.355/137,381*10^6 ~ 9.8631 not 9.8635. It's not a problem since 9.863 is used in the code.

2. All the c1s are the same implies all the dfo generators have same marginal cost after our linearization. This is different from our previous cost curve fix for coal and ng, in which we keep the relative differences between different generators and recalculate the absolute values based on new average fuel prices. However, in this case we can't proceed in the same manner given the original c1s are all 0. Probably, we may revisit this to consider the cost differences between dfo generators in the future.

3. Regarding the format mismatch, one straightforward way is to store 'dtype' of the dataframe right after read_csv, then do a 'astype' to fix the format changes due to the calculations when writing to csv file.

[ghost]

I've read through the notebook and checked the corresponding changes in the gencost.csv file. It looks good in general :). Some minor concerns as following:

1. 1.355/137,381*10^6 ~ 9.8631 not 9.8635. It's not a problem since 9.863 is used in the code.

2. All the c1s are the same implies all the dfo generators have same marginal cost after our linearization. This is different from our previous cost curve fix for coal and ng, in which we keep the relative differences between different generators and recalculate the absolute values based on new average fuel prices. However, in this case we can't proceed in the same manner given the original c1s are all 0. Probably, we may revisit this to consider the cost differences between dfo generators in the future.

3. Regarding the format mismatch, one straightforward way is to store 'dtype' of the dataframe right after read_csv, then do a 'astype' to fix the format changes due to the calculations when writing to csv file.

@BainanXia:

1. I truncated the trailing digits of the average fuel price in my writeup, but I used the full precision when calculating price per MMBtu. IIRC, it wound up being 9.86345 ish, but 9.863 should be accurate enough.

2. I used the c1 analog in the aux file (linear coefficient for the heat rate curve) and multiplied by 9.863 to get the c1 in our gencost. So we are still reflecting the original TAMU data, with a real fuel price instead of 0. The difference in c2 values should result in different linearized values in our model.

3. The current format for the gencost file is a bit odd. Values of 0 are sometimes written as '0' and sometimes as '0.0' (depending on column), and other floats are represented as up to 3 digits of decimal precision, but always at least 1 digit (e.g. '8.0'), except for the occasional floating point cruft. I opted to match our current format as best as possible so that viewing the diff between the two versions would be easier.