Download the latest version of VEDA-FE (45834) and VEDA-BE (492018)

Veda Application Installation guide


Problem with EV-charging modelling
#1
Hi,

We are trying to model EV charging by including three parameters:
1. EV efficiency - The energy efficiency of EV changes with season. 
2. Charging location - The charging can be done either at home, work or fast charging with a predefined share between them
3. Charging profile - Each charging location has its own specific DAYNITE charging profile

In our attempt to include all these parameters in the model we used following approach:
The EV efficiency is defined per season in the EFF parameter of the EV. The charging locations are defined as three distinct processes and the amount of the energy used by each process to charge the EV fleet is defined with FLO_MARK. The charging profile for each charging process is defined with help of FLO_FR.

The FLO_FRA is defined for DAYNITE, while we want to decide where energy is coming from on a seasonal level with help of FLO_MARK. To solve this difference in time resolution two processes are simulated for the charging where the first one have a DAYNITE time resolution and the second one SEASONAL resolution.

In attached you find a schematic over the modeled process.

When running this model the energy demand for TCAR-EL is variating between seasons and this variation is also presented in energy flow in and out (VAR-FIn/FOut) of the process (TCHARGE-XXX-Seasonal). BUT, the TCHARGE-XXX is for all seasons having the same energy flow corresponding the season with highest energy demand.

Our question is if it is possible to make the TCHARGE-XXX energy flow to variate over seasons so that it always match TCHARGE-XXX-Seasonal? Maybe there is a more simpel manner to model these charging characteristics? A simpler way in which we were thinking we could model was if there was a similar functionality of FLO-MARK that could be variable over DAYNITE timeslices, but we are not aware of such a functionality in TIMES-VEDA.

Kind regards
Janis


Attached Files Thumbnail(s)
   
Reply
#2
(05-02-2020, 08:56 PM)janisd Wrote: When running this model the energy demand for TCAR-EL is variating between seasons and this variation is also presented in energy flow in and out (VAR-FIn/FOut) of the process (TCHARGE-XXX-Seasonal). BUT, the TCHARGE-XXX is for all seasons having the same energy flow corresponding the season with highest energy demand.
Our question is if it is possible to make the TCHARGE-XXX energy flow to variate over seasons so that it always match TCHARGE-XXX-Seasonal?

Yes, indeed FLO_MARK defines market share constraints on the timeslice level of the commodity.  If you would like to define SEASON level constraints for a DAYNITE commodity, you could 1) define a dummy commodity on the SEASON level, which is also a UD-CG including the original commodity, and then define the FLO_MARK using that dummy commodity, or 2) you could use user constraints for defining these constraints.

I am having difficulties understanding the issue, which you describe by saying that TCHARGE-XXX-Seasonal has the seasonal variation, but TCHARGE-XXX does not have that variation.  As far as I can see, there is only a single process TCHARGE-XXX supplying each TCHARGE-XXX-Seasonal, and so TCHARGE-XXX should have the same seasonal variation, but I am obviously missing something. Can you clarify what is the reason for TCHARGE-XXX having the same energy flow for all seasons, and does it mean that you also have notable energy losses there?
Reply
#3
Dear Antti-L,

Thank you for you response. From the options you described, I made the dummy commodity as you described in option 1 with TCHARGE-XXX-Seasonal. I have also attached a printshot how it is defined in Excel sheet.

From the printshots from BE you can see that Var-Fout from TCHARGE-XXX is greater than Var-FIn in TCHARGE-XXX-Seasonal. It is also addittional screenshots where it is possible to see that winter time the energy flows matches while in summer time for the TCHARGE-XXX it is bigger than for TCHARGE-XXX-Seasonal.

It is unclear for us why the energy demand is constant between seasons for TCHARGE-XXX and does not follow the variation of TCHARGE-XXX-Seasonal. Maybe it is an idea to make an user-constrains instead, even if I for the moment dont have a clear idea how to construct one.


Attached Files Thumbnail(s)
               
Reply
#4
I am sorry, but I am not able to see well what you have been trying to do now. I can see you are defining FLO_MARK for TCHARGE-RES-S, TCHARGE-COM-S, TCHARGE-FAST-S, for the output commodity ELC-CAR.  But ELC-CAR is not a dummy commodity (it is in the topology). So, which one is the dummy commodity?

In your ~FI_COMM commodity table you have four commodities: ELC-CAR-RES, ELC-CAR-COM ELC-CAR-FAST and ELC-CAR.  But all of them are in the topology, and so none of them is a dummy commodity. I suggested a dummy commodity on the SEASON level, which is not in the topology, but contains the DAYNITE commodity (by being UD_CG).  And then to define the FLO_MARKs for that dummy, so that the constraint is on the SEASON level, instead of DAYNITE. That will work, if you want to define FLO_MARK constraints on the SEASON level, although the commodity in the topology is DAYNITE. But of course, I am not sure whether that is what you wanted...
Reply
#5
I tried to see if I can by any chance reproduce the issue you have described, but I couldn't reproduce it.

This is how I tested:
 • I created a tiny test model utilizing all the data you have provided;
 • I assumed 24 hourly timeslices in Summer and Winter;
 • I removed the TCHARGE-XXX-Seasonal processes, as they seemed unnecessary;
 • I assumed TCHARGE-XXX on DAYNITE level, but producing SEASON level ELC-CAR (so FLO_MARK is seasonal);
 • I used FLO_FR on the output of TCHARGE-XXX for defining charging constraints.

In the results I cannot see any such issue with the energy demand being constant between seasons. The energy demand varies according to season as defined by the COM_FR for the demand.  The picture below shows my results for the input and output flows of TCHARGE-COM in Winter and Summer (similar to your tables).

So, thus far I cannot confirm seeing any evidence of the problem you described.

   
Reply
#6
Hi Antti-L

Thank you for your support. I will try to look into your answer with my colleagues during the next days and come back to you if your input helped us to resolve the problem.

Kind regards
Janis
Reply
#7
Ok thanks!

However, I am sorry for my input not being of much help, as I cannot even reproduce the issue. If there had been a reproducible test case available, I would have been able to give much better input, because the reasons for the problem would have become clear ...
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)