TIMES-Macro-MSA and gdx behaviour

[Enya]

Hi!

I have been exploring the TIMES-Macro-MSA module recently and came across some odd behavior regarding the gdx file:

• When I do a TIMES-Macro run without fixing a GDX file, the demand values (EQ_Combal) change a bit from the COM_PROJ due to the Macro interaction. (That is what I expected to see) However, for all demand commodities, the values only start to differ after 5 periods and I don't see what would cause this.
  

• When I do the exact same TIMES-Macro run with a GDX file fixing the first 5 periods, the demand values remain identical to the COM_PROJ values for all periods after as well... as if there is no impact from the Macro interaction on the demands anymore.
  

I am curious if anyone has some more insights for me.
Thanks in advance!

[Antti-L]

> When I do the exact same TIMES-Macro run with a GDX file fixing the first 5 periods, the demand values remain identical to the COM_PROJ values for all periods after as well... as if there is no impact from the Macro interaction on the demands anymore.

I just tested fixing five initial periods with the advanced demo MSA case I tested earlier for you. And I am seeing the demands changing under a policy scenario, for all unfixed periods. So, I was not able to confirm your findings.  Of course, to see the demands changing, you must impose some kind of a policy, for example a CO2 tax as I did.

[Enya]

Thank you for the reply.

Upon reflection, I should reformulate my question:

I am indeed not looking at the policy scenario (yet).
I was investigating the baseline scenario in the MSA to check if the calibration was successful, as I would expect the demand profiles to match the original COM_PROJ.
I ran two cases:
1) When running the MSA procedure on the baseline scenario, the demand does not match the original COM_PROJ
2) When running the MSA procedure on the baseline scenario with fixing the GDX file for the first five periods, the demand matches the original COM_PROJ
In short, it seems the calibration fails without fixing the GDX file.

Could it be that the calibration is somehow an iterative procedure, and the number of loops is not high enough for the first case to reach convergence? (since case 1 has more variable periods) If this is the case, I suspect it won't be visible in a demo model.
Can I increase the number of loops manually? Or do you think something else might be going on?

Thanks again!

[Antti-L]

Yes, the calibration is an iterative process. 
There is some reporting showing the convergence in the listing file of a CSA run.  Could you post it here to see? In addition, the *.vd file includes the Var_Macro results for the calibration.  Can you post them as well?

What kind of a model is this that you are using now with MSA?  I hope you have disabled dummy imports, because they are a major source of problems when using Macro, can you confirm?

[Enya]

[Antti-L]

It is hard to conclude much about it with so little information, other than that there seems to be some severe issue, because the system costs are falling so weirdly. Interestingly, the convergence looks ok.

Anyway, a few questions:
   • I don't see how the listing file could be confidential, are you sure you cannot provide it?
   • Could you perhaps provide the DD file containing the Macro-specific parameters, and/or the MSADDF.DD file?
   • Are you sure dummy imports are fully disabled (e.g. by NCAP_START(reg,'IMP*Z')=2200) in both runs (CSA & MSA)?

[Antti-L]

Note that there is also the experimental Macro MLF Formulation available in TIMES, which may actually be more robust than the highly decomposed MSA algorithm (and is definitely faster).

I just tested MLF once again with the advanced Demo, using a CO2 tax in the policy scenario, and it produced results quite well matching with the full NLP solution (no decomposition). One leftover issue with the MLF option turned out to be that it did not yet support fixing initial periods to a previous solution, but I now made a fix for that. I will try and prepare a new TIMES release over the weekend where that fix is included.

Therefore, if you cannot provide more information about your issue, I can suggest trying also with the MLF formulation. There is a user note about it which you should read first. Using MLF requires a Baseline run using the TIMESED NO setting (to produce the demand prices for MLF), and those base prices should be used in the policy runs (the elastic demands setting in the VEDA GDX References). Dummy imports should be again disabled in both the Baseline run and policy runs.

[Antti-L]

@Enya: Returning to that results table shown above, is the "MSA-Baseline" just the same Baseline scenario used for CSA, but run with MSA?  If that is so, it makes it even more clear that there is a severe problem. Running MSA with the the Baseline scenario used in the calibration should reproduce closely the reference results from the calibration. But without the model it is hard to see where the problem stems from.

The new TIMES version v4.8.7 is now available, with some improvements into the Macro MLF formulation, should you want to try that instead.

[Enya]

Thanks for all the input!

Some updates:
- After revision with my colleagues, we decided we could indeed post the *LST files. (see attached)
- I made sure to fully disable all dummies in an additional scenario file -> nothing changed
- I tested another run with fixing the gdx file up to 2025 and now the MSA_Baseline does seem to reproduce the demands as it should (as I mentioned in the beginning of this thread), but the MSA_Policy scenario still shows rapidly declining TM_ESCOST which is distorting the MACRO results.
- I would like to try out the MACRO MLF, could you point me to the user note?

[Antti-L]

Thanks for the listing files.  They revealed that the CSA run is working fine, and with just a single master iteration, which is indeed as expected, because the model has only a single region and the discount factor harmonization is not requested.  However, the MSA run appears to require several master iterations, even though it appears to be the same Baseline (which I guess is explained by having no discount factor harmonization).  That would be still ok, but it appears that the algorithm fails due to LP model being infeasible in the fourth master iteration. That failure indicates that the LP model may bee too tightly formulated in terms of demand flexibility. In the master iterations, the demands of the LP model are adjusted (exogenously) according to how the NLP solution suggests the demands should be changing. And these adjustments should normally be small enough for the LP model to cope with them, but in this case the LP model turns out to become infeasible, even if it is just the same Baseline as what was used for calibration, which is indeed quite unusual.

However, although what I describe above about model tightness seems the plausible, without any deeper knowledge of the model it is not possible for me to make any firm conclusions about the reasons for the LP model becoming infeasible during the algorithm.

Nonetheless, the Macro MLF algorithm works differently in this respect, as it does not adjust the demands of the LP model at all exogenously, but it is done endogenously (like it would be in a full NLP Macro model).  Therefore, I think there is a good chance that the Macro MLF algorithm would work successfully for your model.

Using the Macro MLF algorithm expects basically the same macro input parameters as the MSA algorithm (e.g. TM_GR, TM_GDP0, TM_ESUB etc.), plus it has some optional additional parameters (not required).  The main differences are in the calibration, where the Baseline must be run with the switches $SET ANNCOST LEV and $SET TIMESED NO (but no Macro switch), and the policy runs (or a Baseline replication run) must have the $SET MACRO MLF and the $SET TIMESED YES settings (or under VEDA, the Elestic Demand GDX file reference).
See additional details in the user note: TIMES-Macro-MLF-Note.pdf

[Antti-L]

Additional note: I see you were using TIMES v.4.6.8, which was released back in 2022.
If you try Macro MLF, I strongly suggest using the latest version, TIMES v4.8.7.

[Enya]

Hi again,

Following up after some time:

Good news:
After some thought, indeed there was a scenario file in the model that is fixing the output to match historic data, which was holding back the demand variation from MACRO-MSA! This also explains why fixing the gdx file solved this weird behaviour, as it was overwriting the periods where this constraint was active. (I assume)

Bad news:
I updates the TIMES version and tried the MLF procedure but I seem to be doing something wrong. I retried the procedure in a dummy model to speed up testing, but it is not working. (see *LST files attached) My tests seems to be solving a classic TIMES problem as I don't see any MACRO variables in the results... (See files attached) Am I overlooking something?

Theoretical question:
Conceptually, I was wondering how the original TIMES-MACRO works. As the MACRO equations are integrated in the TIMES model, is the objective function of the mathematical problem completely replaced with the MACRO objective? (As I think MACRO still has incentive to minimize the total system cost?) Or is it based on a combined objective? 

Once again, thank you for the input!

[Antti-L]

Yes, I can see the MLF option is not enabled in your (second) run. 
I guess the first run is the Baseline run, which should have the run switches as instructed in the user note (MLF not enabled there). And the second run should have the run switches for the MLF run, again those that were instructed in the user note. Apparently you have somehow failed to define the switches correctly, maybe you could show how you defined them?

Yes, the objective function of the mathematical model is completely replaced with the MACRO objective, which still has incentive to minimize also the total system cost while maximizing the utility.

[Enya]

runfile.run for the baseline scenario:

*

OPTION PROFILE=1, SOLVEOPT=REPLACE;
*

*

*--If you want to use an optimizer other than cplex/xpress, enter it here:
*OPTION LP=MyOptimizer;

$OFFLISTING
*$ONLISTING

* activate validation to force VAR_CAP/COMPRD
$SET VALIDATE 'NO'
* reduction of equation system
$SET REDUCE  'YES'
*--------------------------------------------------------------*
* BATINCLUDE calls should all be with lower case file names!!! *
*--------------------------------------------------------------*

* initialize the environment variables
$ SET DSCAUTO YES
$  SET VDA YES
$  SET DEBUG                          'NO'
$  SET DUMPSOL                        'NO'
$  SET SOLVE_NOW                      'YES'
$  SET MODEL_NAME                    'TIMES'
$  IF DECLARED REG      $SET STARTRUN 'RESTART'
$  IF NOT DECLARED REG  $SET STARTRUN 'SCRATCH'
$SET XTQA YES
* VAR_UC being set so that non-binding constraints appear in results
$SET VAR_UC YES
$  SET TIMESED              NO
$  SET ANNCOST              LEV
$  SET OBLONG                YES
*

* merge declarations & data
$  ONMULTI

* the times-slices MUST come 1st to ensure ordering OK
*

*
$  BATINCLUDE initsys.mod

* declare the (system/user) empties
$  BATINCLUDE initmty.mod
*$  BATINCLUDE initmty.mod DSC
$IF NOT DECLARED REG_BNDCST $Abort "You need to use TIMES v2.3.1 or higher"

*

*

$ SET VEDAVDD 'YES'

* do the rest
$ BATINCLUDE maindrv.mod mod

runfile.run for the baseline recuperation scenario:

*

OPTION PROFILE=1, SOLVEOPT=REPLACE;
*

*

*--If you want to use an optimizer other than cplex/xpress, enter it here:
*OPTION LP=MyOptimizer;

$OFFLISTING
*$ONLISTING

* activate validation to force VAR_CAP/COMPRD
$SET VALIDATE 'NO'
* reduction of equation system
$SET REDUCE  'YES'
*--------------------------------------------------------------*
* BATINCLUDE calls should all be with lower case file names!!! *
*--------------------------------------------------------------*

* initialize the environment variables
$ SET DSCAUTO YES
$  SET VDA YES
$  SET DEBUG                          'NO'
$  SET DUMPSOL                        'NO'
$  SET SOLVE_NOW                      'YES'
$  SET MODEL_NAME                    'TIMES'
$  IF DECLARED REG      $SET STARTRUN 'RESTART'
$  IF NOT DECLARED REG  $SET STARTRUN 'SCRATCH'
$SET XTQA YES
* VAR_UC being set so that non-binding constraints appear in results
$SET VAR_UC YES
$  SET TIMESED              YES
$  SET ANNCOST              LEV
$  SET MACRO                MLF
$  SET OBLONG                YES
*

* merge declarations & data
$  ONMULTI

* the times-slices MUST come 1st to ensure ordering OK
*

*
$  BATINCLUDE initsys.mod

* declare the (system/user) empties
$  BATINCLUDE initmty.mod
*$  BATINCLUDE initmty.mod DSC
$IF NOT DECLARED REG_BNDCST $Abort "You need to use TIMES v2.3.1 or higher"

*

*

$ SET VEDAVDD 'YES'

* do the rest
$ BATINCLUDE maindrv.mod mod

[Antti-L]

Hmm... very interesting.  I am not able to see what the problem is here. 

But I see that the model is very small indeed:

MODEL STATISTICS

BLOCKS OF EQUATIONS        106    SINGLE EQUATIONS          71
BLOCKS OF VARIABLES          27    SINGLE VARIABLES          53
NON ZERO ELEMENTS          176

So, maybe you could post this whole test model here so that I could (hopefully) reproduce the issue and tell you why it did not work?  I mean the *.DD and *.RUN files for both runs.