https://forum.iea-etsap.org/ Thu, 05 Nov 2026 06:46:19 +0000 MyBB https://forum.iea-etsap.org/thread-255.html Wed, 08 Jul 2026 07:26:53 -0400 KristofferEML]]> https://forum.iea-etsap.org/thread-255.html 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=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:

1. Is my reading of the trapezoidal-vs-rectangular distinction correct, and is there a documentation reference (rather than just the source) that describes it?
2. 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?
3. 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 ]]> 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=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:

1. Is my reading of the trapezoidal-vs-rectangular distinction correct, and is there a documentation reference (rather than just the source) that describes it?
2. 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?
3. 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 ]]> https://forum.iea-etsap.org/thread-254.html Wed, 15 Apr 2026 01:58:03 -0400 mahmoudmobir]]> https://forum.iea-etsap.org/thread-254.html https://github.com/MMobir/times-data The main motivation is simple: I enjoy Python-first workflows and wanted a scriptable, transparent, version-control-friendly data layer for TIMES modeling. A few points to be fully clear: * This is complementary to established TIMES workflows and tools. * This is not a UI product (yet) — it is currently Python + CLI. * It is open source (MIT) and intended to stay open source. times-data currently supports two entry paths: 1. Build from scratch in Python, or 2. Import existing DD files and edit/validate/re-export. Current capabilities include: * typed model graph (commodities/processes/parameters) * schema + structural validation * DD export/compile for standard TIMES/GAMS runs Verification so far: * tested on all 12 official DemoS models * on models within my active GAMS community license limits, round-trip tests gave exact objective value matches * larger demos compile successfully but exceed solve-size limits in my current license environment I’m using this experimentally in my own global model workflow at Rhodium Group, and I’d really value community testing and feedback. If there is interest, I’m happy to record a short walkthrough video showing: * build-from-scratch path * DD import/edit/re-export path * validation and solve flow Issues, criticism, and contributions are all welcome:
https://github.com/MMobir/times-data Best,
Mahmoud Mobir]]> https://github.com/MMobir/times-data The main motivation is simple: I enjoy Python-first workflows and wanted a scriptable, transparent, version-control-friendly data layer for TIMES modeling. A few points to be fully clear: * This is complementary to established TIMES workflows and tools. * This is not a UI product (yet) — it is currently Python + CLI. * It is open source (MIT) and intended to stay open source. times-data currently supports two entry paths: 1. Build from scratch in Python, or 2. Import existing DD files and edit/validate/re-export. Current capabilities include: * typed model graph (commodities/processes/parameters) * schema + structural validation * DD export/compile for standard TIMES/GAMS runs Verification so far: * tested on all 12 official DemoS models * on models within my active GAMS community license limits, round-trip tests gave exact objective value matches * larger demos compile successfully but exceed solve-size limits in my current license environment I’m using this experimentally in my own global model workflow at Rhodium Group, and I’d really value community testing and feedback. If there is interest, I’m happy to record a short walkthrough video showing: * build-from-scratch path * DD import/edit/re-export path * validation and solve flow Issues, criticism, and contributions are all welcome:
https://github.com/MMobir/times-data Best,
Mahmoud Mobir]]> https://forum.iea-etsap.org/thread-253.html Wed, 11 Feb 2026 01:51:46 -0500 IESR_Dhifan]]> https://forum.iea-etsap.org/thread-253.html Browse tab displays MINRNW and IMPEXP in addition to REG1 (which is the only region I specified in the SysSettings tab). Meanwhile, the Attributes tab only shows COM_PROJ and G_DYEAR. I have reviewed the BaseYear, SubRes, and SysSettings tabs to the best of my understanding, but I am still uncertain about the source of the issue. Previously, before I added several process technologies in an earlier version, the model functioned correctly. I have since deleted those process technologies - but the issue still persists. Please find the screenshot and my project folder attached for reference. Thank you.
  IIDOA3.2 Error.PNG (Size: 206.27 KB / Downloads: 3)

  IIDOA3.2.zip (Size: 238.7 KB / Downloads: 1) ]]> Browse tab displays MINRNW and IMPEXP in addition to REG1 (which is the only region I specified in the SysSettings tab). Meanwhile, the Attributes tab only shows COM_PROJ and G_DYEAR. I have reviewed the BaseYear, SubRes, and SysSettings tabs to the best of my understanding, but I am still uncertain about the source of the issue. Previously, before I added several process technologies in an earlier version, the model functioned correctly. I have since deleted those process technologies - but the issue still persists. Please find the screenshot and my project folder attached for reference. Thank you.
  IIDOA3.2 Error.PNG (Size: 206.27 KB / Downloads: 3)

  IIDOA3.2.zip (Size: 238.7 KB / Downloads: 1) ]]> https://forum.iea-etsap.org/thread-252.html Wed, 24 Sep 2025 04:16:23 -0400 NicoK]]> https://forum.iea-etsap.org/thread-252.html ]]> ]]> https://forum.iea-etsap.org/thread-251.html Tue, 21 Jan 2025 08:58:17 -0500 demar]]> https://forum.iea-etsap.org/thread-251.html
  ERRORTIMES.PNG (Size: 1.1 MB / Downloads: 6) ]]>
  ERRORTIMES.PNG (Size: 1.1 MB / Downloads: 6) ]]> https://forum.iea-etsap.org/thread-250.html Wed, 15 Jan 2025 09:10:26 -0500 demar]]> https://forum.iea-etsap.org/thread-250.html
  error.png (Size: 141.4 KB / Downloads: 0) ]]>
  error.png (Size: 141.4 KB / Downloads: 0) ]]> https://forum.iea-etsap.org/thread-249.html Wed, 15 Jan 2025 04:47:47 -0500 myhan]]> https://forum.iea-etsap.org/thread-249.html ]]> ]]> https://forum.iea-etsap.org/thread-248.html Sun, 05 Jan 2025 03:13:53 -0500 myhan]]> https://forum.iea-etsap.org/thread-248.html https://forum.iea-etsap.org/thread-247.html Sat, 07 Dec 2024 13:46:36 -0500 demar]]> https://forum.iea-etsap.org/thread-247.html
  carboncontent.PNG (Size: 34.75 KB / Downloads: 16) ]]>
  carboncontent.PNG (Size: 34.75 KB / Downloads: 16) ]]> https://forum.iea-etsap.org/thread-246.html Mon, 05 Aug 2024 21:00:01 -0400 willcattoneeca]]> https://forum.iea-etsap.org/thread-246.html kea-v2_1_2  VEDA (GAMS/CPLEX solver) running kea-v2_1_2    :  76 seconds * 7 threads Julia (HiGHS solver) running kea-v2_1_2        :  242 seconds * 6 threads Python (HiGHS solver) running kea-v2_1_2      :  405 seconds Open-source solver relative slowdown :    3 to 5 times longer (approx) ===================================  Memory usage for TIMES-NZ scenario kea-v2_1_2 On-disk kea-v2_1_2, saved as an mps file        :  85 MB VEDA (GAMS/CPLEX solver) running kea-v2_1_2    :    8 MB  # used by GAMS process. How can this be? Am I missing some of the memory usage? Julia (HiGHS solver) running kea-v2_1_2        : 2426 MB  # total memory used by julia process. Not clear how much of this is due to the model. The size of the model object in memory is 159 MB according to Julia. Python (HiGHS solver) running kea-v2_1_2      :  400 MB  # total memory used by python process. Open-source memory usage increase          :  50 to 300 times more (approx) =================================== I'm a bit confused by how much less memory is being used by GAMS / CPLEX while solving the problem. First thought was perhaps the CPLEX solver does a more effective presolve? But from the logging it looks like Highs is just as successful. Presolved Problem Specifications: GAMS/CPLEX: Rows: 166,606 Columns: 139,519 Nonzeros: 1,192,044 HiGHS: Rows: 166,922 Columns: 140,319 Nonzeros: 1,196,177 A few things I tried made little difference to the results: - Pulled out the Matrix representation of the LP and create a new JuMP model, attempting to suppress variable naming (result: same size and solve time) - Implemented the model as a Convex.jl optimization problem and tried solving it with SCS (Bad idea. Way too slow!) Will PS - in case anyone else wants to try profiling their TIMES model in other languages, here's a crude way: the following steps are one way to ensure a "writelp" line gets added at the bottom of the cplex.opt file when you run TIMES using VEDA. The "writelp" line tells cplex to dump the LP to disk. In my case the line that gets added is "writelp TIMES_kea-v2_1_2.lp", because my scenario is called kea-v2_1_2.     1) Go to the latest TIMES model file directory (GAMS_SrcTIMES.vA.B.C) present in your VEDA directory     2) Open the file solve.mod using a text editor like VSCode.     3) Find a line (e.g. for TIMES v4.8.1, it's line 33) that looks like:     $  IF    %METHOD% == P    $SETLOCAL METHOD LP     4) Immediately below it, insert the following six lines:     DISPLAY "Configure cpex to export an MPS file for use with other solvers.";     $onecho >> cplex.opt     * Keep the line empty above this one - it puts a newline where it's needed!     writelp %MODEL_NAME%_%RUN_NAME%.lp     $offecho     5) Run your TIMES scenarios using VEDA as usual.     6) After running TIMES, in the relevant scenario directory e.g. GAMS_WrkTIMES\kea-v2_1_2, you should find a new ".lp" file that contains the full model problem. In my case it's called TIMES_kea-v2_1_2.lp]]> kea-v2_1_2  VEDA (GAMS/CPLEX solver) running kea-v2_1_2    :  76 seconds * 7 threads Julia (HiGHS solver) running kea-v2_1_2        :  242 seconds * 6 threads Python (HiGHS solver) running kea-v2_1_2      :  405 seconds Open-source solver relative slowdown :    3 to 5 times longer (approx) ===================================  Memory usage for TIMES-NZ scenario kea-v2_1_2 On-disk kea-v2_1_2, saved as an mps file        :  85 MB VEDA (GAMS/CPLEX solver) running kea-v2_1_2    :    8 MB  # used by GAMS process. How can this be? Am I missing some of the memory usage? Julia (HiGHS solver) running kea-v2_1_2        : 2426 MB  # total memory used by julia process. Not clear how much of this is due to the model. The size of the model object in memory is 159 MB according to Julia. Python (HiGHS solver) running kea-v2_1_2      :  400 MB  # total memory used by python process. Open-source memory usage increase          :  50 to 300 times more (approx) =================================== I'm a bit confused by how much less memory is being used by GAMS / CPLEX while solving the problem. First thought was perhaps the CPLEX solver does a more effective presolve? But from the logging it looks like Highs is just as successful. Presolved Problem Specifications: GAMS/CPLEX: Rows: 166,606 Columns: 139,519 Nonzeros: 1,192,044 HiGHS: Rows: 166,922 Columns: 140,319 Nonzeros: 1,196,177 A few things I tried made little difference to the results: - Pulled out the Matrix representation of the LP and create a new JuMP model, attempting to suppress variable naming (result: same size and solve time) - Implemented the model as a Convex.jl optimization problem and tried solving it with SCS (Bad idea. Way too slow!) Will PS - in case anyone else wants to try profiling their TIMES model in other languages, here's a crude way: the following steps are one way to ensure a "writelp" line gets added at the bottom of the cplex.opt file when you run TIMES using VEDA. The "writelp" line tells cplex to dump the LP to disk. In my case the line that gets added is "writelp TIMES_kea-v2_1_2.lp", because my scenario is called kea-v2_1_2.     1) Go to the latest TIMES model file directory (GAMS_SrcTIMES.vA.B.C) present in your VEDA directory     2) Open the file solve.mod using a text editor like VSCode.     3) Find a line (e.g. for TIMES v4.8.1, it's line 33) that looks like:     $  IF    %METHOD% == P    $SETLOCAL METHOD LP     4) Immediately below it, insert the following six lines:     DISPLAY "Configure cpex to export an MPS file for use with other solvers.";     $onecho >> cplex.opt     * Keep the line empty above this one - it puts a newline where it's needed!     writelp %MODEL_NAME%_%RUN_NAME%.lp     $offecho     5) Run your TIMES scenarios using VEDA as usual.     6) After running TIMES, in the relevant scenario directory e.g. GAMS_WrkTIMES\kea-v2_1_2, you should find a new ".lp" file that contains the full model problem. In my case it's called TIMES_kea-v2_1_2.lp]]> https://forum.iea-etsap.org/thread-245.html Tue, 21 May 2024 05:16:33 -0400 demar]]> https://forum.iea-etsap.org/thread-245.html for the first three years after the purchase data the taxes are higher. After those three years, the taxes are then lower. Thanks]]> for the first three years after the purchase data the taxes are higher. After those three years, the taxes are then lower. Thanks]]> https://forum.iea-etsap.org/thread-244.html Tue, 23 Apr 2024 09:24:02 -0400 Saika Anjum]]> https://forum.iea-etsap.org/thread-244.html https://forum.iea-etsap.org/thread-243.html Fri, 05 Apr 2024 10:19:05 -0400 AkramS]]> https://forum.iea-etsap.org/thread-243.html PRC_REFIT(reg,prc,p)" for the modeling of RF/LE options has been introduced.   For one of our new investment technologies in a SUBRES file a "re-investment" (meaning additional investment cost) after a specified number of years is needed. Could you please provide me with an example, showing how to do this in a TIMES table? Thank you in advance. //AkramS]]> PRC_REFIT(reg,prc,p)" for the modeling of RF/LE options has been introduced.   For one of our new investment technologies in a SUBRES file a "re-investment" (meaning additional investment cost) after a specified number of years is needed. Could you please provide me with an example, showing how to do this in a TIMES table? Thank you in advance. //AkramS]]> https://forum.iea-etsap.org/thread-241.html Tue, 27 Feb 2024 17:17:12 -0500 demar]]> https://forum.iea-etsap.org/thread-241.html
  selfsuf.PNG (Size: 64.54 KB / Downloads: 11) ]]>
  selfsuf.PNG (Size: 64.54 KB / Downloads: 11) ]]> https://forum.iea-etsap.org/thread-240.html Mon, 19 Feb 2024 13:02:44 -0500 demar]]> https://forum.iea-etsap.org/thread-240.html
  Existing Stock.PNG (Size: 53.31 KB / Downloads: 7)

  NewInvestmentOptions.PNG (Size: 36.26 KB / Downloads: 4)

  AFA Scenario.PNG (Size: 45.22 KB / Downloads: 3)

  Results.PNG (Size: 23.16 KB / Downloads: 5) ]]>
  Existing Stock.PNG (Size: 53.31 KB / Downloads: 7)

  NewInvestmentOptions.PNG (Size: 36.26 KB / Downloads: 4)

  AFA Scenario.PNG (Size: 45.22 KB / Downloads: 3)

  Results.PNG (Size: 23.16 KB / Downloads: 5) ]]>