Veda2.0 Released!


Myopic Run
#1
Hi,

I have read through the documentation on implementing myopic foresight, but I’m still unclear on how to actually set it up and run it in practice. Could you point me to a demo or provide a simple example that shows how to create and use the relevant components in the Excel file?

Best,
-Behzad
Reply
#2
The TIMESTEP control variable specifies the amount of years that should be optimized in each solution step in the times-stepped solution option.  The total model horizon will then be solved by successive steps, so that in each step the periods to be optimized are advanced further in the future, and all periods before them are fixed to the solution of the previous step.

The amount of overlapping years between successive steps is by default half of the active step length (the value of TIMESTEP), but it can be controlled by the user by using the TIMES G_OVERLAP parameter. Consequently, the specifications that can be used to control a stepped TIMES solution are the following:

$SET TIMESTEP 20  (specified in the run file)
 PARAMETER G_OVERLAP / 10  /; (specified in a DD file)


In this example, the TIMESTEP control variable specifies the active step length of each successive solution step (20 years), and the G_OVERLAP parameter specifies the amount of years, by which the successive steps should overlap (10 years).

Because the time periods used in the model may be variable and may not always exactly match with the step-length and overlap, the actual active step-lengths and overlaps may somewhat differ from the values specified. However, at each step at least one of the previously solved periods is fixed, and at least one remaining new period is taken into the active optimization in the current step.

Under VEDA, the TIMESTEP control variable can be set in the Run Manager.  The G_OVERLAP parameter can be defined in any scenario file. That's basically all that is needed for setting it up. One can also use the FIXBOH option with it.

However, you should also be aware that depending on the model, there may be some constraints implemented (mainly UCs) in the model that do not work well with the time-stepped option. For example, the JRC-EU-TIMES model has lots of various UC  constraints, some of which I have seen causing problems for time-stepped solution. And positive NCAP_ILEDs may likewise cause problems, and so it is recommended to use only negative ILEDs when using the time-stepped option (it should be easy to convert them all with a UPD table).
[+] 2 users Like Antti-L's post
Reply
#3
(01-04-2026, 04:10 PM)Antti-L Wrote: The TIMESTEP control variable specifies the amount of years that should be optimized in each solution step in the times-stepped solution option.  The total model horizon will then be solved by successive steps, so that in each step the periods to be optimized are advanced further in the future, and all periods before them are fixed to the solution of the previous step.

The amount of overlapping years between successive steps is by default half of the active step length (the value of TIMESTEP), but it can be controlled by the user by using the TIMES G_OVERLAP parameter. Consequently, the specifications that can be used to control a stepped TIMES solution are the following:

$SET TIMESTEP 20  (specified in the run file)
 PARAMETER G_OVERLAP / 10  /; (specified in a DD file)


In this example, the TIMESTEP control variable specifies the active step length of each successive solution step (20 years), and the G_OVERLAP parameter specifies the amount of years, by which the successive steps should overlap (10 years).

Because the time periods used in the model may be variable and may not always exactly match with the step-length and overlap, the actual active step-lengths and overlaps may somewhat differ from the values specified. However, at each step at least one of the previously solved periods is fixed, and at least one remaining new period is taken into the active optimization in the current step.

Under VEDA, the TIMESTEP control variable can be set in the Run Manager.  The G_OVERLAP parameter can be defined in any scenario file. That's basically all that is needed for setting it up. One can also use the FIXBOH option with it.

However, you should also be aware that depending on the model, there may be some constraints implemented (mainly UCs) in the model that do not work well with the time-stepped option. For example, the JRC-EU-TIMES model has lots of various UC  constraints, some of which I have seen causing problems for time-stepped solution. And positive NCAP_ILEDs may likewise cause problems, and so it is recommended to use only negative ILEDs when using the time-stepped option (it should be easy to convert them all with a UPD table).

Thanks a lot, Antti!
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)