Allow non-zero ALQ without vfp tables (may be used in UDQs) #4324
Conversation
|
jenkins build this please |
There was a problem hiding this comment.
Just to be clear, this is trying to support the case of an ALQ being used in the defining expression of a UDQ, right? It's not the other way around–i.e., a UDQ being used as a UDA for the ALQ?
If so, then this looks mostly good to me although there are a couple of potential issues in the low-level details here. It's not ideal that glir() returns two different units of measurement though. The output system will perfom the correct unit conversion–i.e., no conversion at all–but the parameter will still be recorded in the SMSPEC and therefore labeled as a surface flow rate for gas in any production curve plots.
opm/output/eclipse/Summary.cpp
Outdated
| return {alq_rate, measure::identity }; | ||
| continue; |
There was a problem hiding this comment.
The return statement here means that the continue statement is redundant.
There was a problem hiding this comment.
Ah.. should be continue, see below.
opm/output/eclipse/Summary.cpp
Outdated
| const double eff_fac = efac(args.eff_factors, well->name()); | ||
| alq_rate += eff_fac * xwPos->second.rates.get(rt::alq, production.alq_value); |
There was a problem hiding this comment.
Are you sure you want to add the values here? Please keep in mind that function glir() is the backend for the field level vector FGLIR, the group level vector GGLIR, and the well level vector WGLIR. The only difference between these cases is the contents of args.schedule_wells. Might it make sense to have special case handling of WGLIR for this purpose?
There was a problem hiding this comment.
I think it makes sense to add, but instead of 'return' above it should be 'continue' (with rates converted according to unit).
Right.
No.
Good point, and didn't think of GGLIR/FGLIR.. Updated now. |
|
jenkins build this please |
No description provided.