search

arbrandt / OPGEE

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

9000 fields Errors #327

Closed smasnadi closed 3 years ago

smasnadi commented 3 years ago

I am helping Zhan by running OPGEE with updated flaring data. Zhan and I planned to share results with @arbrandt and @JSRuthe afterwards to work on a paper. OPGEE 2.0 runs are successful. I ran all fields few months ago in 3.0 and it went well. However, I got lots of Errors using the recent version. We probably are going to have the same problem for global gas project. The main issue is Mass Balance. One example is attached. Seems that the "transport to market" is the main source of discrepancy between Total inputs and Total outputs.

OPGEE_3.0a_BETA_ERRORS.xlsm.zip

smasnadi commented 3 years ago

Exploring this step-by-step if time allows: seems that the error is related to all those fields where we put -1 for fraction of NG re-injected (in order to set the export gas to 0). This affects the gas mass balance.

JSRuthe commented 3 years ago

Looks like its possible issue #244 might not be properly fixed

JSRuthe commented 3 years ago

There are also calculation refresh issues as we've shown in issue #262

arbrandt commented 3 years ago

I believe we re-worked the definition there, so that we don't use the -1 formulation any more. 100% gas reinjected is now 1, I believe. Quinn? @qlangfitt

qlangfitt commented 3 years ago

Yes - Adam is right. See Issue #216 for more details, but basically, the definition of fraction of natural gas reinjection changed from the fraction available after gas processing to the fraction available after onsite uses. This means that what used to necessitate a -1 tag now just requires a 1. The change was made to prevent the default injection scenario from injecting a bunch of gas and then importing new gas for onsite use (as was happening in some of my trial runs where there is a lot of onsite use).

I think this might give you trouble though for using inputs developed for 2.0 for anything with a fraction other than 0 or 1 since the basis of that fraction is now different. I've struggled with this disconnect a lot and have suggested an enhancement to deal with this in another issue (#324), but that hasn't been implemented. Reach back out if any of this doesn't make sense - happy to explain further.

arbrandt commented 3 years ago

@smasnadi I think this new approach is better. The fraction of gas reinjected after self-consumption is more intuitive and to prevent the strange default behavior Quinn was seeing.

Fractions defined using the old definition for 2.0 will not be that much different, given that self use is generally not a major fraction. You should just be able to use the existing fractions except -1 fields (switch to 1), at least as a first start.

As Quinn notes, this may introduce issues where gross gas reinjected is reported. An approach was suggested in #324, but I am of a mixed opinions about bringing back the negative fractions. At first pass I would rather have the user compute the fraction, then increase it a bit to account for self use.

Closing this for now. Re-open if there is a new issue or if switching to +1 doesn't work.