An observation and perhaps a question if any have solved this?
Anyone what have worked with using the FLO_SUB attribute for one process with serveral input commodities. I have had the experience that when using the attribute this way the subsidy is one applied for one of the commodities, eventhough the process consume different commodities. I was in the believe that the FLO_SUB is working similar to FLO_TAX just with opposite effect on the objective function, however this is not the case.
What i for now have done, is applying a negative FLO_TAX. This solution just comes with some problems if the model is used to show tax and subsidies to politicians and a commodity for some reason have both, as it is not the most logic solution.
I cannot confirm your findings.
I just ran a test model with a process having two input fuels, and both having a FLO_SUB defined.
The results show both of them getting the subsidy, and both in the OBJ and in the annual cost reporting parameter Cost_Flox (when both inputs are used).
Therefore, more info would be needed to see why you are having some problem with it.
Could you provide a reproducible example?
(30-01-2018, 07:07 PM)Antti-L Wrote: I cannot confirm your findings.
I just ran a test model with a process having two input fuels, and both having a FLO_SUB defined.
The results show both of them getting the subsidy, and both in the OBJ and in the annual cost reporting parameter Cost_Flox (when both inputs are used).
Therefore, more info would be needed to see why you are having some problem with it.
Could you provide a reproducible example?
Hi Antti
Thanks for the reply
I have added a screen-shot of how it has been inserted (note: there are no empty rows in the excel file) and the results that show no subsidies for the process when consuming the fuel as it should have. If I instead use the FLO_TAX attribute and apply a negativ cost it works with the exact same table.
31-01-2018, 01:03 AM (This post was last modified: 31-01-2018, 01:05 AM by Antti-L.)
The *.DD files and the *.RUN file for the run case that reproduces the issue shown by Mikkel would be great.
You could e.g. send me a download link via Dropbox or Google Drive in a private message.
(31-01-2018, 01:03 AM)Antti-L Wrote: The *.DD files and the *.RUN file for the run case that reproduces the issue shown by Mikkel would be great.
You could e.g. send me a download link via Dropbox or Google Drive in a private message.
31-01-2018, 04:51 PM (This post was last modified: 31-01-2018, 04:55 PM by Antti-L.
Edit Reason: typo
)
Thanks for providing me the test case. One of the DD files was missing (elc_windmaxgrowth.dd), but I managed to run the model by commenting it out in the RUN file.
I found out that in the TIMES pre-processing there was indeed a bug, which manifested only when defining both taxes and subsidies on the same process flow at the same time. And you had defined also zero taxes on these input flows. I have fixed the issue now in the code, and tested the model again, and the subsidies were now taken into account correctly even when both taxes and subsidies are defined at the same time.
The fix will be in the next version, but meanwhile, you could just remove the zero taxes from these flows.
In addition, I would also suggest using top_check flags in the TFM_INS table when defining these subsidies with wildcard commodity filters. You are now defining also lots of spurious subsidy parameters on process flows that do not exist in the model.
(31-01-2018, 04:51 PM)Antti-L Wrote: Thanks for providing me the test case. One of the DD files was missing (elc_windmaxgrowth.dd), but I managed to run the model by commenting it out in the RUN file.
I found out that in the TIMES pre-processing there was indeed a bug, which manifested only when defining both taxes and subsidies on the same process flow at the same time. And you had defined also zero taxes on these input flows. I have fixed the issue now in the code, and tested the model again, and the subsidies were now taken into account correctly even when both taxes and subsidies are defined at the same time.
The fix will be in the next version, but meanwhile, you could just remove the zero taxes from these flows.
In addition, I would also suggest using top_check flags in the TFM_INS table when defining these subsidies with wildcard commodity filters. You are now defining also lots of spurious subsidy parameters on process flows that do not exist in the model.
Hi Antti
Thanks a lot for the help looking forward to the update, for now i will use your suggestion and remove the tax.
I will take your suggestion into account and try implement it into your model, thanks.
Then it is no problem for me we are trying to show the danish politicians, how to possible use TIMES for a near (2-3 months) energy agreement for Denmark.
That is in fact quiet interesting, i installed TIMES on this computer in October and thought i had a fairly new update. Time for an update then.
31-01-2018, 07:09 PM (This post was last modified: 31-01-2018, 07:17 PM by olexandr.)
(31-01-2018, 07:05 PM)MikkelBosack Wrote: Then it is no problem for me we are trying to show the danish politicians, how to possible use TIMES for a near (2-3 months) energy agreement for Denmark.
That is in fact quiet interesting, i installed TIMES on this computer in October and thought i had a fairly new update. Time for an update then.
Thanks for the help once again
Actually, we are centralising the update process internally in DTU, as a way to make sure that everyone is using an up-to-date version of the source code. One person puts it on a git server and everyone pulls it from there. :-)
