https://forum.iea-etsap.org/ Fri, 23 Oct 2026 10:26:13 +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-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-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-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) ]]> https://forum.iea-etsap.org/thread-239.html Fri, 09 Feb 2024 06:31:15 -0500 demar]]> https://forum.iea-etsap.org/thread-239.html
  TIMESFORUM.PNG (Size: 32.65 KB / Downloads: 6) ]]>
  TIMESFORUM.PNG (Size: 32.65 KB / Downloads: 6) ]]> https://forum.iea-etsap.org/thread-237.html Fri, 26 Jan 2024 03:30:31 -0500 anik_ier]]> https://forum.iea-etsap.org/thread-237.html https://forum.iea-etsap.org/thread-236.html Fri, 19 Jan 2024 05:41:02 -0500 Ansh_02]]> https://forum.iea-etsap.org/thread-236.html Hello Dr. Antti Happy New Year. I hope you are doing well. I am developing a standalone power model for India and want to add pumped hydro energy storage technology. I have the following data to define my technology. Overall Plant Efficiency           74% full load operation in generating mode  6 hrs/day CYCLE EFFICIENCY              76% AUXILIARY CONSUMPTION   1% PLANNED OUTAGE          10 days Total Potential                97 GW Capacity till 2020            3 GW Technical lifetime            40 years Construction time           8 years Charging efficiency         80% Ramp Up Rate             50% of Full Load/Minute Ramp Down Rate            50% of Full Load/Minute Capital Cost        935 USD/PJ Fixed O&M         23 USD/PJ/yr So, I have added a process where I have defined the following parameters. Parameter         Item 5/6             2020      2030 CAP_BND           FX                         2.6        CAP_BND           UP                                        20 NCAP_AFC          DAYNITE             0.33         0.33 NCAP_BND         UP                                        20 NCAP_COST                                 935           935 NCAP_FOM                                   23              23 NCAP_ILED                                   -8              -8 NCAP_TLIFE                                  40             40 STG_CHRG                                   0.95        0.95 STG_EFF                                       0.9          0.9 STG_LOSS                                    0.03        0.03 The model horizon is extended till 2070, and I have the following queries:

1.  I wanted to add cycle efficiency with STG_MAXCYC, but I couldn't find that in my parameter list (my TIMES version 6.9.24)
2. How could I model ramp up and down rate for this process, and what are the parameters?
3. How could I add 'full load operation in the generating mode' and overall plant efficiency? 
4. With the above parameters, I was able to run the model, and in the results, I only got capacity numbers for this process but NO Activity nor VAR FLO OUT. Why is the process not generating even if it has capacity?

]]> Hello Dr. Antti Happy New Year. I hope you are doing well. I am developing a standalone power model for India and want to add pumped hydro energy storage technology. I have the following data to define my technology. Overall Plant Efficiency           74% full load operation in generating mode  6 hrs/day CYCLE EFFICIENCY              76% AUXILIARY CONSUMPTION   1% PLANNED OUTAGE          10 days Total Potential                97 GW Capacity till 2020            3 GW Technical lifetime            40 years Construction time           8 years Charging efficiency         80% Ramp Up Rate             50% of Full Load/Minute Ramp Down Rate            50% of Full Load/Minute Capital Cost        935 USD/PJ Fixed O&M         23 USD/PJ/yr So, I have added a process where I have defined the following parameters. Parameter         Item 5/6             2020      2030 CAP_BND           FX                         2.6        CAP_BND           UP                                        20 NCAP_AFC          DAYNITE             0.33         0.33 NCAP_BND         UP                                        20 NCAP_COST                                 935           935 NCAP_FOM                                   23              23 NCAP_ILED                                   -8              -8 NCAP_TLIFE                                  40             40 STG_CHRG                                   0.95        0.95 STG_EFF                                       0.9          0.9 STG_LOSS                                    0.03        0.03 The model horizon is extended till 2070, and I have the following queries:

1.  I wanted to add cycle efficiency with STG_MAXCYC, but I couldn't find that in my parameter list (my TIMES version 6.9.24)
2. How could I model ramp up and down rate for this process, and what are the parameters?
3. How could I add 'full load operation in the generating mode' and overall plant efficiency? 
4. With the above parameters, I was able to run the model, and in the results, I only got capacity numbers for this process but NO Activity nor VAR FLO OUT. Why is the process not generating even if it has capacity?

]]> https://forum.iea-etsap.org/thread-235.html Thu, 30 Nov 2023 10:41:49 -0500 lukas]]> https://forum.iea-etsap.org/thread-235.html
  EQ_CombalM_ELCHIGG_TRAELC.xlsx (Size: 13.31 KB / Downloads: 4) ]]>
  EQ_CombalM_ELCHIGG_TRAELC.xlsx (Size: 13.31 KB / Downloads: 4) ]]> https://forum.iea-etsap.org/thread-234.html Thu, 16 Nov 2023 03:34:07 -0500 VictorG]]> https://forum.iea-etsap.org/thread-234.html
  Gams_Wrk_DEBUG.zip (Size: 1.55 MB / Downloads: 1) ]]>
  Gams_Wrk_DEBUG.zip (Size: 1.55 MB / Downloads: 1) ]]>