08-07-2026, 04:56 PM
(This post was last modified: 08-07-2026, 04:58 PM by KristofferEML.)
Hello Antti,
I'm looking for the documentation on the OBLONG control switch, and would like to sanity-check an observation about its effect on lump-sum investment cost reporting.
What I can't find
I haven't been able to locate a section in the TIMES documentation (Part I or II) that names OBLONG explicitly and explains what it does in plain terms. The only concrete statement I've found is from a previous post on VEDA forum:
"$SET OBLONG YES changes the objective function formulation, correcting a few inconsistencies, and so it is in fact always recommended if using OBJ=STD, MOD or AUTO."
That tells me it matters, but not precisely what it corrects.
What I've pieced together from the source
Digging into the GAMS source (ppmain.mod, coef_alt.lin, eqobjinv.mod, initmty.mod), my understanding is:
My observation
In my model, with OBLONG=NO, the reported lump-sum investment cost reconciles exactly with NCAP_COST × VAR_NCAP, i.e., the raw INVCOST input assumption. With OBLONG=YES, the same reconciliation no longer holds exactly; there's a small but systematic discrepancy. I've confirmed this isn't a fractional-lifetime artifact, all NCAP_TLIFE values in the affected processes are whole numbers.
Given the code above, my working hypothesis is that RTP_CAPVL is what keeps OBJ_DIVI consistent with a straightforward annuitisation of INVCOST, so that back-calculating a lump sum from the objective coefficients reproduces INVCOST exactly only when that correction is applied. Under OBLONG=YES, the simplified divisor no longer carries this correction, introducing a wedge relative to INVCOST, even though OBLONG=YES is the generally-recommended, "more consistent" formulation overall. Does this match your understanding, or is there a more precise explanation for why the lump-sum figure and INVCOST reconcile exactly only under OBLONG=NO?
Note I am not using NCAP_ILED or NCAP_DRATE in my model.
My actual question
For most purposes I understand OBLONG=YES is recommended because it corrects certain inconsistencies in the objective function and is numerically more robust. My use case is different, though: I want to do discounted cash-flow analysis outside TIMES, using the model's reported investment cost as an input, so I specifically need the reported lump-sum cost to reconcile exactly with the INVCOST fed into the model.
Concretely:
Happy to share a minimal reproducible demo model if useful, although it might take me a day or so to prepare such a demo.
Thanks in advance, Kristoffer
I'm looking for the documentation on the OBLONG control switch, and would like to sanity-check an observation about its effect on lump-sum investment cost reporting.
What I can't find
I haven't been able to locate a section in the TIMES documentation (Part I or II) that names OBLONG explicitly and explains what it does in plain terms. The only concrete statement I've found is from a previous post on VEDA forum:
"$SET OBLONG YES changes the objective function formulation, correcting a few inconsistencies, and so it is in fact always recommended if using OBJ=STD, MOD or AUTO."
That tells me it matters, but not precisely what it corrects.
What I've pieced together from the source
Digging into the GAMS source (ppmain.mod, coef_alt.lin, eqobjinv.mod, initmty.mod), my understanding is:
- With OBLONG=NO (the default trapezoidal treatment), TIMES computes a correction term RTP_CAPVL labelled in the code as the cost adjustment "due to trapezoidal periods" — that adjusts the objective-function divisors OBJ_DIVI, OBJ_DIVIII, OBJ_DIVIV (coef_alt.lin, ~lines 82–86 and 96). As far as I can tell this corrects for the fact that the divisor formulas are a linear approximation, while actual discounting over a technology's life is geometric, i.e., it's a discount-curvature correction.
- With OBLONG=YES, this correction block is skipped entirely (coef_alt.lin jumps past it to $LABEL DONE/$LABEL UPDATE at lines 80 and 148), and the divisors are left at their uncorrected, uniform ("oblong") values.
- OBLONG=YES also imposes a strict contiguity requirement on periods - ppmain.mod (~line 159) aborts with "Inconsistent periods - cannot use OBLONG" if the milestone years and period spans aren't perfectly contiguous.
- It's forced on whenever OBJ=MOD is used (initmty.mod: $IFI %OBJ%==MOD $SETGLOBAL OBLONG YES).
My observation
In my model, with OBLONG=NO, the reported lump-sum investment cost reconciles exactly with NCAP_COST × VAR_NCAP, i.e., the raw INVCOST input assumption. With OBLONG=YES, the same reconciliation no longer holds exactly; there's a small but systematic discrepancy. I've confirmed this isn't a fractional-lifetime artifact, all NCAP_TLIFE values in the affected processes are whole numbers.
Given the code above, my working hypothesis is that RTP_CAPVL is what keeps OBJ_DIVI consistent with a straightforward annuitisation of INVCOST, so that back-calculating a lump sum from the objective coefficients reproduces INVCOST exactly only when that correction is applied. Under OBLONG=YES, the simplified divisor no longer carries this correction, introducing a wedge relative to INVCOST, even though OBLONG=YES is the generally-recommended, "more consistent" formulation overall. Does this match your understanding, or is there a more precise explanation for why the lump-sum figure and INVCOST reconcile exactly only under OBLONG=NO?
Note I am not using NCAP_ILED or NCAP_DRATE in my model.
My actual question
For most purposes I understand OBLONG=YES is recommended because it corrects certain inconsistencies in the objective function and is numerically more robust. My use case is different, though: I want to do discounted cash-flow analysis outside TIMES, using the model's reported investment cost as an input, so I specifically need the reported lump-sum cost to reconcile exactly with the INVCOST fed into the model.
Concretely:
- Is my reading of the trapezoidal-vs-rectangular distinction correct, and is there a documentation reference (rather than just the source) that describes it?
- Is exact reconciliation between reported lump-sum investment cost and INVCOST only guaranteed under OBLONG=NO, or is there a different switch/reporting option that lets me keep the recommended OBLONG=YES formulation while still getting a lump-sum figure that ties out cleanly to INVCOST?
- Aside from the "few inconsistencies" that OBLONG=YES corrects, is there a downside to sticking with OBLONG=NO for this purpose, does it materially change the optimal solution itself (not just the reporting)?
Happy to share a minimal reproducible demo model if useful, although it might take me a day or so to prepare such a demo.
Thanks in advance, Kristoffer