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!
22-01-2025, 03:50 PM (This post was last modified: 22-01-2025, 04:20 PM by 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.
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?
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?
10-04-2025, 11:38 PM (This post was last modified: 11-04-2025, 05:03 PM by 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)?
11-04-2025, 04:55 PM (This post was last modified: 11-04-2025, 04:57 PM by 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.
@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.
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?
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
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.
