27-06-2025, 06:26 PM (This post was last modified: 27-06-2025, 06:28 PM by LuisPDias.)
Hi, I recently updated to VEDA 2.0 (version 4.1.1.1) in an attempt to resolve a persistent error (“C/perflog”) that was preventing VEDA from running. However, after the update, I’m now encountering the following issues: Problem writing symbol: IRE_PRICE *** Domain violation *** Problem writing symbol: UC_FLO *** Domain violation *** Problem writing symbol: FLO_EMIS *** Domain violation *** GDX File failed C:\VEDA\GAMS_WrkTIMES\GAMSSAVE\wam_cap45jun_test.gdx *** Msg: Domain violation I attach the associated .lst file.
I understand that some of these can occur due to domain violations (and as Antti-L has in previous queries explained, to correct for these errors, you should make sure all the commodities and processes that are referred are defined in the model. However, this issue did not occur in the previous version. So I’m woundering if I’m overlooking something. PS: With te help of Ravinder I adjusted the Source TIMES mapping coherence Any insights or suggestions would be greatly appreciated
27-06-2025, 07:00 PM (This post was last modified: 27-06-2025, 09:08 PM by Antti-L.)
Thanks for this post; it looks like it could be important info for the VEDA developers.
>However, this issue did not occur in the previous version.
This is very interesting. I have thus far not tested the latest v4.1.1.1, and thus cannot confirm the issue, but it looks it could potentially be serious. However, based on the listing file, the new domain violations are appearing from e.g. the following issues:
• VEDA seems to be accepting NRGI as a commodity for UC_FLO, causing domain violation
• VEDA seems to be accepting wildcard masks as a commodity group for FLO_EMIS, causing domain violation
I don't know in which kind of data tables these parameters have been defined, but if they are in DINS tables, they would actually be user errors: NRGI cannot be used for a commodity index, and as far as know, wildcards are not supported at all for CG indexes. However, a DINS table would in a way explain that VEDA may have passed them through to the DD files. But if the previous versions did not pass them out, while the latest version does, I am very puzzled!
So, lets hope the VEDA developers can have a closer look why these issues arise for you.
Hi Antti, thank you so much for the prompt reply and advices! We started some potential user error corrections but, due to time limitation for necessary results generation, we are now downgrading the veda 2.0 version to at leats run the model.
We'll also look forward for VEDA developers support team insights on this.
Thank you again!
01-07-2025, 06:12 PM (This post was last modified: 01-07-2025, 06:14 PM by AKanudia.)
Apologies for the delay Luis. We were distracted by a working retreat that just ended.
I would be surprised if you don't face the same issues in any previous version of Veda. The only possibility I see is that you have inadvertently used a different scenario group with the new version of Veda.
The most efficient route will be to have a small demo specification that behaves differently in two versions. Else let's schedule a web meeting to look at this.
(01-07-2025, 06:12 PM)AKanudia Wrote: Apologies for the delay Luis. We were distracted by a working retreat that just ended.
I would be surprised if you don't face the same issues in any previous version of Veda. The only possibility I see is that you have inadvertently used a different scenario group with the new version of Veda.
The most efficient route will be to have a small demo specification that behaves differently in two versions. Else let's schedule a web meeting to look at this.
Hi Amit!
No problem at all! 1 working day is not even considered a delay!
Ok, if you're available we can schedule a quick meeting to check this. Now we're facing similar issue in other Veda locations and maybe this a user error from my side.