PCG Observation and question

[Antti-L]

I have observed that if I have a process with a single NRG output COM, VEDA usually by default sets the PCG=COM.

However, as soon as one defines a Share-O for such a process (like Ceas19 defined for EAUTELC00 in the TIAM model), the PCG is changed to be XXXX_NRGO.  As a subsequent side-effect, when the PCG is a genuine group, the process will no longer contribute to the peak by capacity.

Q: Is this a reasonable VEDA convention? Such that just defining a process parameter has the side effect that the PCG of the process and its peak contribution is changed?

[AKanudia]

Thanks a lot for this observation Antti.

Would this work?

If PCG is a Veda default CG with only one COM, PCG is replaced by COM.

[Antti-L]

I am not sure what you mean.  The VEDA default for PCG is already COM, if the PCG is not explicitly specified, and there is only a single output commodity COM.

What I don't understand is why this default is currently changed, if the user specifies a FLO_SHAR for the output. Is there some reasonable explanation to that, or can it be considered a bug? 

> Would this work? If PCG is a Veda default CG with only one COM, PCG is replaced by COM.

No, that does not seem reasonable.  If the user specifies NRGO as the PCG, it think it should definitely not be replaced by COM.  But I am not sure I understood you right: did you actually suggest such? Anyway, I don't think any replacing of the PCG would be needed here, but shouldn't the PCG default simply be independent of any FLO_SHAR parameters defined?

[Antti-L]

Small follow-up:

Now I tried also some other parameters:  PRC_ACTFLO~NRGO and ACT_EFF~NRGO (at the same time). I notice that these are also unexpectedly affecting the PCG:  The PCG suddenly changes from ELC to TESTPRC_NRGO (in this test process having ELC as the sole NRG output).

This does not make sense to me.  Why would the PCG change due to these parameters being defined?

BTW, I also tested with a process having two NRG outputs COM1 and COM2, of which COM2 is auxiliary.  In this case the PCG was correctly assigned COM1, despite the fact that the group TESTPRC_NRGO was also created.  So, the PCG default worked ok in that case. It thus seems that it is indeed those process parameters that have this unexpected side-effect, and it is not related to the TESTPRC_NRGO being created or not.

[AKanudia]

Thanks for these detailed tests and lucid reporting.

This entire PCG revision story was triggered by the case when you introduce COM2 in a process where PCG was COM1, where COM2 is *NOT* auxiliary. You would agree that in this case the PCG should be updated to NRGO, UNLESS it was explicitly defined as COM1 in the FI_Process table. Right now even an explicit definition is being overridden.

We will revisit this and propose a new logic in the next few days.

[Antti-L]

Thanks a lot for giving an explanation to it. 

I agree that if the user adds COM2 in a scenario via TFM_TOPINS, AND that scenario is included in the run, AND the PCG is not explicitly specified, then the PCG may be automatically defined as *_NRGO. But not otherwise.

> Right now even an explicit definition is being overridden.

Uh, really?  I'd consider that very undesirable!  I think VEDA should respect what the user explicitly wants, and not override it.

If there is indeed a need for changing the PCG according to scenario, I think there should best be an explicit mechanism for that.  Also changing the process/commodity timeslice levels could be supported (I guess it is now only supported in SysSettings).

[Antti-L]

> We will revisit this and propose a new logic in the next few days.

It's now been a week.  Any news about this problem? 

Some follow-up questions:  ~TFM_TOPINS-A was some years ago mentioned on the Forum, for adding auxiliary flows, but under VEDA2, Information → VEDA Tags does not mention it.  Is it still available, or some other mechanism to instruct VEDA about the type of flow?

~TFM_INS-txt does not seem to be mentioned under VEDA2, Information → VEDA Tags.  Which are the attributes that can be redefined there?  Do they include some mechanism for changing the PCG?

[AKanudia]

Thanks for your patience. Our small team is busy with implementing licensing arrangements in Veda online. We will try to address the PCG allocation issues as soon as possible, but it might take another few days.

Thanks for pointing out the two tables that are missing from the VEDA Tags list. ~TFM_TOPINS-A supports the same columns as ~TFM_TOPINS.

Here are the attributes that can be used in ~TFM_INS-txt:

Commodity:

• COM_LIM: Commodity LimType (UP/LO/FX/N)
  


• COM_TSL: Commodity TimeSlice Level (ANNUAL/SEASON/WEEKLY/DAYNITE)
  


• COM_TYPE: Commodity Type (ELC or LTHEAT)
  

Process:

• PRC_PCG: Primary Commodity Group (C/CG/NRGO/NRGI/DEMO/DEMI/MAT…)
  


• PRC_TSL: Process TimeSlice Level (ANNUAL/SEASON/WEEKLY/DAYNITE)
  


• PRC_VINT: Process Vintaging (Yes/No)
  

[Antti-L]

Thanks for this info Amit.

Ok, so as the PCG can be easily redefined by the user in SysSettings, I think there is basically no need for redefining it by VEDA.
In other words: If a process originally has only a single NRG output, but the user wants to add new NRG commodities into the topology in some scenarios, such that those new flows should be included in the PCG, why wouldn't the user then just define the PCG as NRGO?

In particular, I would definitely not like to see any automatic overwriting of PCGs explicitly defined by the user on the basis of some process attributes.

> We will revisit this and propose a new logic in the next few days.

Any news about the proposed a new logic?

[AKanudia]

Thanks for your patience Antti. We will certainly get back to you by the end of this week, or over the weekend.

[AKanudia]

https://www.dropbox.com/s/njws6hbyxndvjq....7.7z?dl=0

The version above has the following logic for PCG allocation:

1. PRC_PCG declaration via SysSettings has the highest priority.
2. PCG declaration via the primary_cg col of ~FI_Process has the second priority.
3. Veda default PCG will be used only if no declarations are found from the above sources.
4. If a parameter declaration triggers the creation of a single-member CG, which is also the commodity that Veda has identified as the default primary commodity, then the CG will be used (instead of the commodity) as PCG - ONLY FOR DMD processes.

[Antti-L]

Thanks.

I find the description of the proposed new logic otherwise reasonable, but I am only a bit confused about the last point. Could you still explain the motivation for that exception? And would that override also a user-defined PCG (and not only the VEDA default)? According to the priority it should not override any user-defined PCG, but can you just confirm.

[AKanudia]

I confirm that any user-defined PCG - via an INS-txt table in SysSettings or FI_process table will not be overwritten in any case.

Here is a use case for the exception (#4 of my last post): process TCarElc produces DEM commodity TCar, which is the PCG by default. If one declares ACTFLO(cg = TCarElc_DEMO) for this process, then the PCG will be changed to TCarElc_DEMO, provided TCar was a Veda default.

[Antti-L]

Ok, thanks for confirming.

> 4. If a parameter declaration triggers the creation of a single-member CG, which is also the commodity that Veda has identified as the default primary commodity, then the CG will be used (instead of the commodity) as PCG - ONLY FOR DMD processes.

I tried to confirm this, but could not verify this. I am seeing the PCG being defined by VEDA as NRGO / DEMO / MATO, for any ELE, PRE, CHP, or even STG processes having a single OUT commodity.  Is this reasonable and intended?  What is the reasoning behind this?

[AKanudia]

https://www.dropbox.com/s/o22qonm4umdjgy....8.7z?dl=0

Thanks Antti, yet another time when you did the testing that we should have done.

Please see if this version works as expected.