CUM

[mc]

Hello everybodey,

my question concerns the CUM resp. ACT_CUM Attribute.
With VEDA3 we had no problems getting this bound on reserves implemented.
Now, with VEDA4 we find, that the bound is well recongised by VEDA ( visible in TIMES view) but that
the model results do not represent the bnd (mining exceeds the bnd).

Now, I have tried to use CUM, ACT_CUM, CUM~UP, CUM~UP~2050, as we have seen that
the equation is generated differntly than the one in VEDA 3 runs.
Specifically, the model horizon EOH is now 2200 and the type of equation is different (=E=).
I have read the release notes "New Features in  TIMES v2.1-v3.1" but I cannot find where the problem might be.

Your response is very much appreciated,
greetings
mc

[Antti-L]

As far as I know, the meaning of CUM has not been changed in VEDA, but in the later versions it is just being converted into ACT_CUM(reg,prc,Year1,EOH,'UP') instead of a cumulative user constraint. The resulting equations should be mathematically fully equivalent to each other (well, at least if the first milestone year equals to BOH).

From your description, it is very difficult to see why it does not seem to work in your case. Therefore, could you please reproduce the problem (mining exceeding the bound) with the DEMO model, and then upload that small model and the listing file here.  It will be very easy to resolve the problem if you can provide such a reproducible test case.

[Antti-L]

Some additional remarks to your problem description: 

The GAMS equation type of the cumulative process bound constraints is always =E= , because these constraints include a variable representing the cumulative amount, which is then bounded by the bound value. The label "2200" that you are seeing does not mean that the model horizon EOH would now be 2200. This label represents the "End-of-Time" in TIMES (i.e. the largest year that can be referred to), and it does not mean that the cumulative amount would be summed up to 2200.

You also mentioned that you have tried using CUM~UP~2050. However, this would correspond to a completely different constraint, saying that the cumulative amount between 2050 and EOH should be bounded. If that's what you are trying to accomplish, then you should not compare your bound constraints with the original CUM constraints in VEDA v3.

But if you still have the problem, reproducing it in the small DEMO model should take only ~15 minutes of your time. Therefore, I think that doing so and then uploading the model and listing files would be an easy way for you to resolve your problem.

[mc]

Many thanks for your reply.
We are trying to reproduce the problem with the demo model.

But as the demo model is pretty different from our model, so we need some time to get a hold of the differences. However, it is helpful that you clarified the bound definition with ~2050 for me, thanks.

[Antti-L]

Ok, if you cannot reproduce the problem in the DEMO model, I can think of one condition that might cause the problem: 

I you are using the FIXBOH feature (fixing initial periods to a previous solution), and you have recently updated your TIMES code from some old version to the latest version, there could be a compatibility problem between the old solution in the GDX file and the new TIMES version. In that case you should just make initial Baseline run again using the new version, and the problem should go away.

Could you thus tell me what is your current TIMES version and whether you are using the FIXBOH feature using an older GDX file, when the problem occurs?

[mc]

Hello,
thanks again for your replies.
It seems we have an issue of version compatibility here:

we see the problem when combining "old" veda versions with TIMES 320 resp. TIMES304
and when combining "new" (4.3.44) Veda Versions with TIMESv290.

As to our knowledge the problem does not seem to appear when Veda & TIMES versions are up-to-date. We do understand that the newer versions of TIMES and VEDA provide new freatures, we just weren't aware that some bnd's (all CUM-bnd's) are not generated correctly when combining the software.

Many thanks for your help indeed.

[Antti-L]

Very good, I am glad you found out the culprit.

However, I am astounded that you are using such old versions of TIMES. There should be no reason whatsoever to use TIMES v2.9.0 or v3.2.0 with VEDA v4.3.44, but you should use the latest version instead (currently v3.3.7). Note also that any bug fixes will always be only made to the latest version.

And, even if the problem was occurring when using such a combination, I think you should have been able to reproduce the problem also in the DEMO model (by using the same combination). So, I am still confused that you could not reproduce it.

[mc]

Oh, we were able to reproduce it, but since it became clear that it is a version-dependent problem we have decided not to bother you with it. Just wanted to let you know, what the problem was. Maybe it is of any help for other users too.