Veda2.0 Released!


Problem with database since installing new VEDA-BE
#1
Hello all,

Since I installed the new version of VEDA-BE last month I have had consistent problems with getting the results to look sensible - for example existing tables for fossil fuel consumption which have process sets for the main sectors (industry, residential, electricity generation, etc.) are showing up consumption levels way below what they should be (e.g. US gas consumption should be about 30,000 PJ in 2015 but is showing up as 2000). I presume there is some kind of bug which is preventing all the results from being read properly?

Last night I deleted the existing database I had in VEDA-BE and reloaded a copy from a shared drive. The results from the very same tables then looked absolutely fine. 

However this morning, after leaving the computer on to load some runs into VEDA-BE, the consumption results have gone back to being far too low. 

If I can avoid having to reload the database every time I turn the computer back on (and reload all the runs) that would obviously be very helpful but any help would be greatly appreciated.

Many Thanks,
Dan Welsby
Reply
#2
(15-12-2017, 05:05 PM)DanWelsby Wrote: Hello all,

Since I installed the new version of VEDA-BE last month I have had consistent problems with getting the results to look sensible - for example existing tables for fossil fuel consumption which have process sets for the main sectors (industry, residential, electricity generation, etc.) are showing up consumption levels way below what they should be (e.g. US gas consumption should be about 30,000 PJ in 2015 but is showing up as 2000). I presume there is some kind of bug which is preventing all the results from being read properly?

Last night I deleted the existing database I had in VEDA-BE and reloaded a copy from a shared drive. The results from the very same tables then looked absolutely fine. 

However this morning, after leaving the computer on to load some runs into VEDA-BE, the consumption results have gone back to being far too low. 

If I can avoid having to reload the database every time I turn the computer back on (and reload all the runs) that would obviously be very helpful but any help would be greatly appreciated.

Many Thanks,
Dan Welsby

Hi Dan,

Do you get the right result displayed when you hover over a number? Many students in the class I am teaching are experiencing a similar problem. I wonder what to do about it...

Best,
Olexandr
Reply
#3
Olex: I am sure you understand that without having more info than just such a brief description of the symptoms can make it quite difficult to reproduce and resolve the problem.

But now, as your students apparently have small BE databases (without any confidential data) that could be provided to Kanors to reproduce the problem, why don't you ask one of them to give a reproducible case?
Just ask the user to pack up all the files in that BE folder, make a note of the table and attribute in it not giving the right numbers, and state the BE version being used. And, even better, if you have the same BE version, check also that you can reproduce it yourself using that BE database on your computer. If you can reproduce it, I am sure Kanors would also be able to do so and the problem would be quickly solved. Helping them like that could save much time and effort...
Reply
#4
Thanks for the suggestion Antti. Dan and Olex, send us a small VBE database where we can reproduce this problem. You can also check if Tools - Reset database resolves the issue. This must come from set refresh/definition somehow. Have you checked that the process-level results are OK?

One possible explanation: If process set definitions are based on process descriptions, and if descriptions have changed in the runs that you imported in a healthy database, then the sets could get corrupted because VEDA will retain only one description for each process.
Reply
#5
(05-01-2018, 09:45 AM)AKanudia Wrote: Thanks for the suggestion Antti. Dan and Olex, send us a small VBE database where we can reproduce this problem. You can also check if Tools - Reset database resolves the issue. This must come from set refresh/definition somehow. Have you checked that the process-level results are OK?

One possible explanation: If process set definitions are based on process descriptions, and if descriptions have changed in the runs that you imported in a healthy database, then the sets could get corrupted because VEDA will retain only one description for each process.

Hi all,

Thanks for replying. 

I think my problem was a corruption of the process sets as Amit suggested. If I load a run of the model I'm working on into VEDA-BE the results are absolutely fine. However, I've been collaborating with some colleagues and when I tried to load some VD files which were put on a shared drive the results are completely wrong (even if I hover over them as you suggested Olex) - I've taken to only analysing results in VEDA-BE which I've loaded from runs I have done myself in the updated VEDA versions.

One thing which I am still having an issue with which I cannot get my head around is the value of the objective function which the new VEDA-BE is coming out with. For example, in an unconstrained run (i.e. no carbon budgets/temperature limits) I was doing before I updated, the Objective function was ~ $300,000,000 (i think the unit is million $), which is consistent with other peoples 'base' runs at UCL. However, with the exact same run the OBJz is now over $500,000,000. This is also the case for runs I have done with carbon budgets, where the OBJz is now much much higher. Given I haven't changed anything in the scenario files in VEDA-FE - certainly not to the point where an increase of this magnitude would make sense - does anyone have any suggestions as to what might be going on?

Any help would be greatly appreciated,

Dan W
Reply
#6
I remember you had been using some ancient version of TIMES earlier. So basically no wonder.
A big change in the objective is expected, if you had no G_DYEAR defined in the model.
But the effect is only a "scaling factor", and so the difference in the objective is merely cosmetic.

Many years ago, Gary Goldstein suggested a change in the default value for G_DYEAR, and that is what I suspect you see only now, after all these years...

Anyway, there is no longer any support for such old TIMES version you had been using.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)