Import/export process flows

[Antti-L]

I have encountered some peculiarities about the VEDA2 handling of import / export processes and in the related Items Detail display, which are illustrated in the Figure below.  The resulting TOP_IRE entries written in the DD file (for the import process illustrated) are also shown below.

I can see a few unexpected issues in this test example:

  • The commodities SUPCO2N and SUPOIL are shown as auxiliary commodities in the RES diagram, and indeed auxiliary flows have been defined for them with IRE_FLOSUM, as one can see in the figure. Notwithstanding, when looking at the DD file generated, one can surprisingly find a trade link also being defined for SUPCO2N. I think this inconsistency can be considered a bug, because the RES display misleads the user into believing that the SUPCO2N flow is indeed just an auxiliary flow (as intended), while it is actually not. Moreover, because the trade link is created behind the scenes, the user might easily get confused by seeing arbitrary amounts of SUPCO2N output in the model results (I just recently tried to help a user who had been facing this very issue, but I was at first completely clueless, due to being mislead by the VEDA RES diagram).

  • The commodity SUPCO2P is shown as an imported (i.e. traded) commodity in the RES diagram (and in the DD file), despite that fact that it has not been explicitly defined in the process topology at all, but an ENV_ACT parameter has only been defined for it.  I think this is not as one would expect:  I think emission flows defined only by an ENV_ACT parameter should not be automatically defined to have also (free) import flows.

The first issue appears also for export processes, but now only for flows defined with the Input attribute:  Shown again as an auxiliary flow but export trade links are nonetheless also defined by VEDA.

I hope the VEDA developers could comment on these issues, and give their judgement as to whether the illustrated behaviour is by design and reasonable.

   

SET TOP_IRE /
MINRNW.OIL.REG1.OIL.MINOIL1
MINRNW.SUPCO2N.REG1.SUPCO2N.MINOIL1
MINRNW.SUPCO2P.REG1.SUPCO2P.MINOIL1
/;

[AKanudia]

Thanks for identifying this bug and the detailed description. We will fix it in the next day or two.

[Antti-L]

Thanks, Amit.
Could you also tell me which of the issues described are fixed, and how things will be different with the fix?

[AKanudia]

Dear Antti, if we restrict the TOP_IRE entries for exogenous trade processes to the PCG flows, will it resolve the issue?

[Antti-L]

Dear Amit,

> if we restrict the TOP_IRE entries for exogenous trade processes to the PCG flows, will it resolve the issue?

Yes, that would certainly resolve the issues I described, but if you mean that such should be done regardless of how the user explicitly defines the process topology, it would create new issues. Like until now, the user should still be able to define trade links also for non-PCG flows. 

So, I would suggest to refine that condition as follows:
"Restrict the TOP_IRE entries for exogenous trade processes to the flows that are explicitly defined in the process topology as Main flows (i.e. with Comm-IN / Comm-OUT, whereas Auxiliary flows are either with Comm-In-A / Comm-Out-A or not at all explicitly in the topology)."

Would that condition be possible to implement in VEDA2?  I guess TFM_TOPINS also supports Main vs. Auxiliary flows?

But ok, I realize that some legacy models may be using just Input / Output attributes without Comm-IN / Comm-OUT? Then the condition should perhaps be "either PCG flows or explicit Main flows"?

[AKanudia]

Can you please send me use case for the "new issues"?

Import process with C1 and C2 as Comm-OUT; C1 defined as the PCG; Should this create a TOP_IRE entry for C2?

[Antti-L]

> Import process with C1 and C2 as Comm-OUT; C1 defined as the PCG; Should this create a TOP_IRE entry for C2?

Yes it should.  Defining such has been creating the link in VEDA until now, and it is a valid use (I have been using such myself in my models).  How else would we be able to define non-PCG trade links? Ah, yes, in TradeLinks we would also be able to do so...

[AKanudia]

OK, we will implement "either PCG flows or explicit Main flows".

But can you please send me the file that you used to create the case used in the first post of this thread? We managed to generate the SUPCO2P entry, but not the one for SUPCO2N.

[Antti-L]

Great, thanks a lot! 
I think the fix may eliminate some errors and user confusion in many beginner models.

My example is attached. 
Remark:  Note that my figure was for region REG1 (the RES diagram is different for REG2).


  VT_REG_PRI_V1.xlsx (Size: 19.73 KB / Downloads: 1)

[AKanudia]

Thanks for the file(s). We have made two changes:
1. Any topology that Veda creates based on emission or input/output parameters will be marked as Aux for IRE processes.
2. Aux flows will not get TOP_IRE entries.

An updated version will be released later this week.

[Antti-L]

> Any topology that Veda creates based on emission or input/output parameters will be marked as Aux for IRE processes.

Hmm...  I have the feeling that many legacy models may have been relying on just using input/output parameters, without Comm-IN / Comm-OUT.  So, would you then really mark even PCG flows as Aux for IRE processes, if those flows are just defined by using input/output parameters, without explicit topology specification by Comm-IN / Comm-OUT?  I would personally think that would not be such a good idea...

[AKanudia]

Great point. Would it work if we exclude PCG members from #1?

[Antti-L]

Yes, it would.  I guess both an explicitly defined PCG and VEDA-determined default PCG members might need to be excluded (because in many models the PCG may have been left for VEDA to determine).

[AKanudia]

Yes, that's how it would be.

Thanks for helping in identifying and resolving this BUG

[AKanudia]

https://www.dropbox.com/scl/fi/lpf1whlhw226edzen3pmr/Veda2.0_localhost_2.18.1.9.7z?rlkey=fxb4sw549bkcw60hr16kctk6b&dl=0

Please let us know if this EXE resolves the issues identified above.