Significant changes in fuel consumption results after VEDA updates

[aurora]

We're experiencing unexpected differences in model outputs after updating VEDA. When rerunning identical input files that worked previously (early 2025), we're seeing drastically different results for fuel consumption—specifically oil, natural gas, and steam.

Key details:

• No changes made to our input files
  


• Last successful run was in early 2025
  


• Current VEDA version: 4.2.1.0
  


• Previous VEDA version: unknown, but likely 3._
  

What we've tried:

• Changing selections in Tools -> User Options (Checking different combinations of "Fill-R update check", "NRG", "MAT", "DEM", "User Constraints", "Run GDX2VEDA"
  

Questions:

1. Are there known default setting changes in recent VEDA updates that could affect fuel consumption calculations?
   


2. What specific areas within VEDA should we investigate first?
   


3. Could the 2025 updates alone account for such significant differences, or should we be looking for other issues?
   

Any guidance on where to start troubleshooting would be greatly appreciated. Happy to provide additional details about our setup if helpful.

[AKanudia]

The most efficient way to resolve will be to send us the model. The best way to troubleshoot such cases is GDXDiff of the input. See view mode option on the Browse screen - select the same case from the old and new versions.

Check dummy imports and prices of major commodities.

   

[Antti-L]

Possibly the introduction of IMPDUCZ might be one possible explanation here.
That change made the UC constraints completely free, if one had UC dummies enabled but no costs were defined for the new IMPDUCZ process in SysSettings.  I noticed it affecting e.g. the JRC-EU-TIMES model, i.e. all UC constraints did indeed become "free" in that model, due to the model using dummies for UC constraints, but with zero costs because of that change in the handling of UC dummies.

[aurora]

Here is a link to download our model: https://we.tl/t-XYVp26txdx

[Antti-L]

Based on looking at SysSettings, you seem to be affected by that IMPDUCZ issue: I cannot see any costs defined for IMPDUCZ, only for IMPNRGZ, IMPMATZ and IMPDEMZ (in SysSettings).  Maybe you could first try defining such costs?  For example by making a copy of the row for IMPNRGZ and change the process filter on the new row to IMPDUCZ.

I also tried with the s1_nyc_ref case, and indeed those costs were missing from the TIMES input.

[Antti-L]

I imported the model with VEDA 3.2 and 4.2, and I did get some unexpected differences:

COM_TSL (set) Differences
dim1 dim2 dim3 dim4
R2 ELC DAYNITE ins1
R5 ELC DAYNITE ins1

PRC_TSL (set) Differences
dim1 dim2 dim3 dim4
R1 TU_ELCR1_R1_R2_01 DAYNITE ins1
R1 TU_ELCR1_R1_R3_01 DAYNITE ins1
R1 TU_ELCR1_R1_R4_01 DAYNITE ins1
R1 TU_ELCR1_R1_R5_01 DAYNITE ins1
R1 TU_ELCR1_R1_R6_01 DAYNITE ins1
R1 TU_ELCR2_R2_R1_01 DAYNITE ins2
R1 TU_ELCR3_R3_R1_01 DAYNITE ins1
R1 TU_ELCR6_R6_R1_01 DAYNITE ins2
R2 TU_ELCR3_R3_R2_01 DAYNITE ins2
R3 TU_ELCR3_R3_R2_01 DAYNITE ins2
R3 TU_ELCR5_R5_R3_01 DAYNITE ins1
R4 TU_ELCR1_R1_R4_01 DAYNITE ins1
R4 TU_ELCR2_R2_R4_01 DAYNITE ins1
R4 TU_ELCR3_R3_R4_01 DAYNITE ins2
R4 TU_ELCR4_R4_R1_01 DAYNITE ins1
R4 TU_ELCR4_R4_R3_01 DAYNITE ins1
R5 TU_ELCR2_R2_R5_01 DAYNITE ins1
R5 TU_ELCR5_R5_R1_01 DAYNITE ins1
R5 TU_ELCR5_R5_R2_01 DAYNITE ins2
R5 TU_ELCR5_R5_R3_01 DAYNITE ins2
R5 TU_ELCR5_R5_R6_01 DAYNITE ins1


Here 3.2 is (1) and 4.2 is (2).
This does not look right to me, but maybe I am missing something...
I hope Amit could explain why there are these differences!

[AKanudia]

Thanks, Antti, for the initiative.

There is severe duplication in commodity/process declaration in this model. For example, ELC is defined in the VT file with TSlvl and PeakTS, but in the SubRES with null values in these cols, which makes it default to ANNUAL timeslice. Veda lists all such duplication under Information -- Model -- Manage Duplicates, and it expects the user to remove the duplication. This episode tells me that inconsistent duplication should be flagged as a fatal error at the end of Sync.

I have now added prominent warnings in the documentation.

[Antti-L]

Thanks, Amit!
But I am also a bit confused here, because leaving COM_TSL empty should not cause any COM_TSL definition, and indeed VEDA does not write out any COM_TSL for the commodity in such case, and so I think it should therefore be harmless (because a null value in a Subres would not cause any COM_TSL to be written out in the Subres DD file). But in this model, some COM_TSL(DAYNITE) defined in Base seem to disappearing because of this, is that correct? I think that such did not happen in VEDA-FE.

Anyway, if this is indeed inevitably fatal in VEDA2, I agree that it should be flagged as such.

Are the missing PRC_TSL also related to this same issue with duplicate (or empty) Commodity TSL?  Because I think the trade processes are not declared in any Process table.

[AKanudia]

You are right. There might be some hardcoding for ELC that crept in from the legacy version. We are investigating.

PRC_TSL is simply because IRE inherit the TSLVL of the PCG by default.

[Antti-L]

Ok, thanks Amit.
Anyway, @aurora, in addition to the IMPDUCZ issue, those shown above were the only differences I got when comparing the resulting TIMES input files between those two VEDA versions (3.2 and 4.2).  In other words, by adding the IMPDUCZ costs and by making the ELC* commodity declarations consistent, you should no longer see differences between those VEDA versions. However, because the earlier VEDA version did also manifest those consistency issues, after fixing these issues the results may unfortunately still be a bit different from your earlier runs.

Happy new year to you both!