marek-iiasa / cn_ptl Goto Github PK

The currently used units result in values of variables reaching large orders of magnitude, e.g., 10^15 (total cost), 10^9 CO2 emission. This likely causes numerical problems, see e.g., popular explanation of scaling issue in GAMS user guide at https://www.gams.com/mccarlGuide/user_defined_data_scaling.htm . We shall consider at least two approaches to reaching appropriate model scaling:

• use of scaling implemented in message_ix, if it is available, or
• scale model parameters, e.g., use Gt (10^9) for demand, capacities, and all other related entities; additionally scale all costs by 10^3 (i.e., the cost would be in trillions CNY (10^12 CNY).

MM shall explore, if scaling options provided by message_ix are available for adequately address this issue. Then JZ+MM will discuss how to proceed.

Analyze the model instance actually generated and solved (both symbolic relations, and the instance with the values of coefficients).

As discussed last week: the SMS (documented in specs03.pdf) is incomplete and inconsistent. Therefore, it needs to be verified and improved. The names (of parameters, variables, sets, indices) used in SMS should be the same as those predefined in message_ix, but otherwise (i.e., those not predefined) short and in lower-case.

This is the most urgent issue because it blocks the model verification.

The results in the criteria space are easily available from mcma. However, analysis of the results in the decision (and model state variables) cannot be supported by mcma because it is problem-specific. For message/gams models the results are stored in the GDX files located in working dirs (separately for each mcma iteration) on the unix file-system. Thus a two stage process needs to be organized:

1. The GDX files of selected iters need to be transferred to a location where the analysis can be performed, and
2. The analysis should be designed and implemented.

For the second step one should explore if/how to use the message_ix reporting utility. This may include also an option of storing the results, possibly in addition to GDX file, in a DB (Oracle or Postgress) for each iteration by a dedicated application executed after the mcma iteration.

The results of the initial mcma analysis (id=945) composed of 23 iterations are in .../prototype/945 dir. The cost_co2.png chart shows the values of two criteria for 23 iters sorted by increasing cost. Since only two criteria were defined, all solutions should be efficient (non-dominated, Pareto); therefore the values of the other criterion, i.e., CO2 should define a piece-wise increasing function. However, the CO2 is clearly non-monotonic. The cause of this non-monotonicity needs to be explained.

First, JZ shall justify his hypothesis that the results can be justified by the PTL model property. MM does not agree with this hypothesis; he is convinced that the results indicate errors in the model specification or its implementation; the latter may include also problems with the model scaling.

While waiting for JZ's justification of his hypothesis, the model specs (see issue #21) should be completed.