arbrandt / OPGEE

Oil Production Greenhouse Gas Emissions Estimator
18 stars 3 forks source link

Gas consumption goes negative when lifting gas requirement exceeds production #277

Closed qlangfitt closed 3 years ago

qlangfitt commented 3 years ago

EDIT: See later comments. Looks like this was on our radar before, but the previous fix appears to not be working now.

When fields using gas lifting require more gas than what the field produces (total gas, not just CH4), the total amount going to "consumption, sales, and reinjection" (stream 41) can go negative. This is controlled on the Gas Partition A sheet.

For the field that I discovered this, it wasn't CH4 that was the problem, but actually C2H6 and C3H8. What's happening is the demethanizer is pulling off the C2+ constituents, but then the lifting gas stream is based on requiring higher mol fractions of C2+ components (composition as defined on Fuel Specs sheet). If the CH4 balance is close enough, the shortfall in C2+ components can cause the whole stream to go negative.

This carries through to the fraction of fuel gas consumed (Fuel Gas Consumed M62), which turns it negative causes the model to break. I think a good solution would be to use the composition of stream 38 (or 67 in the case of Ryan-Holmes) to set the needs for gas lifting (stream 40). Basically, use CH4 as the basis of comparison and then scale all of the other constituents proportionally. Not sure if this would cause problems elsewhere in the model.

qlangfitt commented 3 years ago

My solution above won't work because the lifting gas stream is recycled into produced gas stream. I see now why the lifting gas needed a static composition. Will need to put more thought into an acceptable solution.

qlangfitt commented 3 years ago

I can also see that this problem has been encountered before as there's a section to the right of the streams on the Gas Partition A sheet that references this. Perhaps whatever solution that was implemented has broken?

qlangfitt commented 3 years ago

Closing this issue. The macro is working fine to adjust. Something else had caused the field to break prior to the spot in the code where this issue is adjusted. There is nothing wrong here.