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:
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=YESalso 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 INVCOSTinput 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
>Is my reading of the trapezoidal-vs-rectangular distinction correct, and is there a documentation reference (rather than just the source) that describes it?
Yes. The trapezoidal investment accounting method causes economic inconsistencies in the model, because the activities (and available capacities) are indeed assumed rectangular (under OBJ=AUTO/STD/MOD), and therefore the trapezoidal incremental investments would not result in the investment costing being "in sync" with the activities or available capacities in each period. For example, with the trapezoidal method (which is applied when NCAP_ILED is not used) you would be often assumed to have parts of the new investments occurring even before the base year, increasing gradually up to the milestone year, even though the investment costs should in that case represent the lump-sum investment costs at the commissioning year (including interest during constriction). Similarly, the corresponding salvage value accounting fails to be consistent without using OBLONG, again due to the trapezoidal method. These inconsistencies are avoided when using NCAP_ILED, but then you will be missing the smooth cost trajectory (based on assuming incremental investments). OBLONG thus takes care of both: it results in consistent investment cost accounting and still uses a smooth cost trajectory over the assumed investment spread.
>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?
I am not sure which kind of issues you see about "exact reconciliation between reported lump-sum investment cost and INVCOST" (and neither been able to verify such). So yes, a small test model reproducing and demonstrating the issue(s) you are seeing would indeed be very helpful, together with some notes pinpointing them ("there's a small but systematic discrepancy"), so that I can better respond to the question.
>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)?
As explained in the document, the downside is that the model solutions may be economically somewhat inconsistent, with those distortions occurring according to the lifetimes of technologies and the related periods definition over that lifetime, and can thus be different for each technology and may easily distort the true competitiveness of technologies. The document referred to above gives some illustrations about those distortions. The effect of OBLONG is in the objective function formulation, and not just reporting.
08-07-2026, 06:56 PM (This post was last modified: 08-07-2026, 07:27 PM by Antti-L.)
> 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.
I think you are misreading the code. Those lines after 80 are executed when using the alternative objective formulations ALT or LIN without OBLONG (basically meant for the experimental LIN option). With the standard OBJ=AUTO, OBJ=STD or OBJ=MOD without OBLONG, they are not executed at all.
I just tested myself using OBLONG=YES, I am myself seeing LUMPINV (lump-sum investment cost) being reported exactly according to NCAP_COST (if not using NCAP_ILED), and so I cannot confirm your findings. Therefore, a reproducible test case demonstrating the issue would really be helpful.
Returning to your question again, because I found it confusing:
> 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?
As far as I can tell, agreement between the reported LUMPINV lump-sum investment cost and NCAP_COST is guaranteed if you are neither using NCAP_ILED nor NCAP_DISC for the technology. If you use NCAP_ILED, then the IDC will be included both in the objective function and in the reported LUMPINV value. And if you use NCAP_DISC, also the risk premium is included both in the objective function and in the reported LUMPINV value(s) (optionally split in two values, the second being the risk premium). But if you use neither, you should be seeing that LUMPINV = NCAP_COST × INSTCAP, regardless of any OBLONG setting.
(08-07-2026, 11:27 PM)Antti-L Wrote: Returning to your question again, because I found it confusing:
> 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?
As far as I can tell, agreement between the reported LUMPINV lump-sum investment cost and NCAP_COST is guaranteed if you are neither using NCAP_ILED nor NCAP_DISC for the technology. If you use NCAP_ILED, then the IDC will be included both in the objective function and in the reported LUMPINV value. And if you use NCAP_DISC, also the risk premium is included both in the objective function and in the reported LUMPINV value(s) (optionally split in two values, the second being the risk premium). But if you use neither, you should be seeing that LUMPINV = NCAP_COST × INSTCAP, regardless of any OBLONG setting.
Hello Antti, Thanks for the detailed replies — and fair correction on the code reading. Thank you also for the the pointer to the ObjVariants.pdf — that's exactly the kind of documentation reference I was missing.
I've attached a small demo model (zip) that isolates the effect. It has a single investment decision, no NCAP_ILED, no NCAP_DRATE, integer NCAP_TLIFE, and fully contiguous periods — so per your reply, LUMPINV should equal NCAP_COST × INSTCAP regardless of OBLONG.
The CAP_NEW/INSTCAP is identical in both runs (100, 20, 20, 20, 20, 20 GW for 2025–2030 under both oblong_false and oblong_true). However, the LUMPINV differs by a constant ~1.976% uplift in every period, independent of the amount of capacity added (NCAP_COST = 100/unit here, so LUMPINV reconciles exactly under OBLONG=NO but not under OBLONG=YES).
Here's the part I think narrows this down: I also pulled Cost_Inv (annualized/levelized investment cost) for the same runs, and it is essentially unchanged between the two settings, with the small residual differences (~0.004%). So the actual annualized cost stream that enters the objective function, and presumably drives the optimal investment decision, is virtually unaffected by OBLONG. It's specifically the back-calculated LUMPINV figure that picks up the ~2% gap. Is there somewhere I can see what exactly is driving this gap?
If I want a lump-sum figure that ties out to INVCOST for external cash-flow work, would you recommend just computing NCAP_COST × INSTCAP directly from the input assumptions rather than relying on LUMPINV when OBLONG=YES? Thanks for your patience with this, Kristoffer
09-07-2026, 03:58 PM (This post was last modified: 09-07-2026, 08:09 PM by Antti-L.
Edit Reason: typo
)
Ok, thanks.
>Is there somewhere I can see what exactly is driving this gap?
Yes. See the file VT_OBLONG_DEM.xlsx, sheet DMDDemands, cell H4. There you specifically define a Zero value for NCAP_ILED. Using NCAP_ILED causes the technology to be modeled according to 2.a/2.b, i.e. with interest during construction included. You can see half year's interest being added to the objective function, which is in fact consistent accounting (although reporting it with/without it may be debatable). The difference between OBLONG YES/NO is that without OBLONG, the original standard assumptions are used, where NCAP_ILED has also a thershold before being applied, and therefore it falls back to cases 1.a/1.b if zero.
For an immediate remedy, I suggest to remove the NCAP_ILED(s), either directly or by TS filtering.
>Is there somewhere I can see what exactly is driving this gap?
Yes. See the file VT_OBLONG_DEM.xlsx, sheet DMDDemands, cell H4. There you specifically define a Zero value for NCAP_ILED. Using NCAP_ILED causes the technology to be modeled according to 2.a/2.b, i.e. with interest during construction included. You can see half year's interest being added to the objective function, which is in fact consistent accounting (although reporting it with/without it may be debatable). The difference between OBLONG YES/NO is that without OBLONG, the original standard assumptions are used, where NCAP_ILED has also a thershold before being applied, and therefore it falls back to cases 1.a/1.b if zero.
For an immediate remedy, I suggest to remove the NCAP_ILED(s), either directly of by TS filtering.
That's it exactly, thank you. The devil is in the detail. For my minimal demo I'd set NCAP_ILED to 0 explicitly rather than leaving it undefined, not realizing that distinction mattered, removing it resolves the reconciliation there.
For the original model, though, the situation is slightly different: here my subres file defines NCAP_ILED>0 for most technologies, and I was overriding it with NCAP_ILED = 0 in a scenario file, assuming that would have the same effect as leaving it undefined. Do you know if there is a way to achieve "undefined" state for NCAP_ILED via a scenario-file override, or is removing NCAP_ILED from the subres file the only immediate remedy (and then define NCAP_ILED in a scenario file if needed)?
09-07-2026, 05:35 PM (This post was last modified: 09-07-2026, 05:36 PM by KristofferEML.)
(09-07-2026, 04:29 PM)Antti-L Wrote: As I mentioned, with TS filtering: in TFM_INS, define a dummy IE option 0 for all those ILEDs, and use a column TS_Filter and set 1 below it.
Thank you, based on your suggestion I set up the ~TFM_INS shown in the first image. This removes NCAP_ILED for periods after 2025, but 2025 itself is still active. Sorry if I've misunderstood the intended approach.
As an alternative, I found that a ~TFM_DINS-AT table with a raw NCAP_ILED(REG,ALLYEAR,PRC) = NO; statement via SFCmd_bot also solves the problem; including for 2025.
Ok, fine, you found another way.
I cannot see the TS_Filter column in your first screenshot, which I specifically suggested to use for Filtering out the Time Series (TS_Filter), and that explains why you get no filtering, but you are just defining an IE option for the NCAP_ILED.
When the MID_YEAR option is used, the accounting of the investment costs is changed basically only for Cases 1.a and 1.b, because Cases 2.a and 2.b were already compliant with the MID_YEAR assumption. However, with this option one may be inclined to adopt the interpretation that the centers of gravity of the construction costs should also be located in the middle of each year over the lead time, equivalent to moving the commissioning year half a year backwards, in the same way as it is done for Cases 1.a and 1.b. This would effectively be simply meaning that the reported LUMPINV values should be reduced accordingly, by the half year's interest, which are currently included in the LUMPINV values. The objective function (and the raw model solution) would remain unchanged.
If there is a common agreement over this refined interpretation, I could submit this change into the LUMPINV reporting for the next release.
09-07-2026, 08:50 PM (This post was last modified: 09-07-2026, 08:52 PM by KristofferEML.)
(09-07-2026, 07:09 PM)Antti-L Wrote: When the MID_YEAR option is used, the accounting of the investment costs is changed basically only for Cases 1.a and 1.b, because Cases 2.a and 2.b were already compliant with the MID_YEAR assumption. However, with this option one may be inclined to adopt the interpretation that the centers of gravity of the construction costs should also be located in the middle of each year over the lead time, equivalent to moving the commissioning year half a year backwards, in the same way as it is done for Cases 1.a and 1.b. This would effectively be simply meaning that the reported LUMPINV values should be reduced accordingly, by the half year's interest, which are currently included in the LUMPINV values. The objective function (and the raw model solution) would remain unchanged.
If there is a common agreement over this refined interpretation, I could submit this change into the LUMPINV reporting for the next release.
Hello Antti,
The way I use LUMPINV it should ideally be a measure of the total lumpsum payment related to investment within the milestone period (i.e., it should always be possible to validate the lumpsum investment cost by ncap_cost x var_ncap.l). I would hence prefer it not to be influenced by the choice of discount rates and midyear discounting. This is also why I really like the option to separate the impact of hurdle rate from the lumpsum investment cost (i.e., RPT_OPT = OBJ~1).
Sorry for not understanding what you meant by TS_Filter. I found some more guidance on two of your old post on VEDA-forum. I can confirm that adding the TS_filter like below works in terms of filtering out NCAP_ILED without defining any new value(s):
09-07-2026, 09:25 PM (This post was last modified: 09-07-2026, 09:44 PM by Antti-L.)
Thanks for confirming about TS_Filter.
Ok, I see your preference of LUMPINV not getting changed due to MID_YEAR.
As I see it, there is a discrepancy in the original design and mid-year discounting even for Cases 2.a and 2.b, when interpreting the results. And so, if we should fully extend mid-year discounting consistently also to the LUMPINV reporting, there is an inevitable difference in the interest during construction calculated, and thereby in the LUMPINV values, even though the objective function is equivalent with and without MID_YEAR for Cases 2.a/b. Thus far I have chosen to keep the reporting of LUMPINV (with IDC) consistent with the original design, but your issue prompted me to reconsider that choice.
However, as you did not like my suggestion of improving it, I leave it to you or anyone else to propose how the reporting could be improved in a consistent way. One possibility would be to always use the interpretation according to mid-year discounting, but that might then be considered inconsistent with the original design.
I really appreciate you taking the time to work through the investment cases 1.a/1.b vs. 2.a/2.b, and the TS_Filter mechanics, with me. I'll leave the LUMPINV/mid-year question as something to revisit only if others hit the same issue and a clearer consensus emerges. If that discussion arises, I would be on the side arguing that the user should be able to access different version of lumpsum, i.e., with and without mid year discounting just like with the hurdle rate.
