I have a couple of examples where I would like to require that a commodity that is produced in one process must be used in a subsequent process.
For example a plant that produces and captures CO2 for CCS purposes must then go into the process for being stored underground (transport and injection to underground storage). Right now it seems my model is just making this intermediate compressed CO2 and I want to require that any CO2 that is made must go into the ground. I believe I could create a user constraint to make the total amount of CO2 out of the fuel and power plants equal to the CO2 into the transport/storage process, but I wasn't sure if there was a means inherent in the model to ensure that these sort commodities are not orphaned.
I have several other commodities like this so I want to make sure I'm using the most efficient means possible.
06-06-2012, 05:14 PM (This post was last modified: 06-06-2012, 05:19 PM by Antti-L.)
It seems to me that your question is not actually related to VEDA, is it? Note that there is also a Forum for ETSAP TIMES (http://www.iea-etsap.org/forum/default.asp), which might be more appropriate for generic modeling questions related to TIMES.
Anyway, if you want that all of the commodity produced must go into subsequent processes, you can simply set COM_BNDNET(UP/FX) to zero, which will ensure that whatever amount of the commodity is produced must be consumed by the downstream processes. Another (but less "firm") way to accomplish the same is to set the Lim_type of the commodity to FX. However, if you want that only the output of certain processes must be consumed by the subsequent processes, then you would need an additional constraint (e.g. a user constraint).
Thank you for your answer. That will be quite helpful. And apologies for the slightly inappropriate question. I will try to use the correct forum next time.
Dear Antti,
I have read this thread also the ETSAP forum, but I am not able to solve my problem with overproduction of a commodity.
If I introduce COM_BNDNET(UP) to zero, there is no overproduction of the commodity (TRAELCT) but there is a dummy import of this commodity - details are in the attachment. I do not see why. I cannot find the reason of the ooverproduction neither of the dummy import in case COM_BNDNET(UP) is set to zero. Do you have an idea where is the problem or how to find it, please?
Ok, if you have dummy imports when you force no overproduction, your model is in fact infeasible unless you let it have overproduction. But it is hard for me to say why that is so, without seeing the model. In other words, I have no idea where the problem is without seeing the model. Finding it would require some investigation with the model.
If you wish me to investigate why your model is infeasible unless overproduction is allowed, you should provide me the model input files (all *.DD, *.RUN files for the case DEMO_T0). Because the model seems to be just some demo model, I think you could just upload those files here (zipped).
(20-09-2019, 02:30 PM)Antti-L Wrote: Ok, if you have dummy imports when you force no overproduction, your model is in fact infeasible unless you let it have overproduction. But it is hard for me to say why that is so, without seeing the model. In other words, I have no idea where the problem is without seeing the model. Finding it would require some investigation with the model.
If you wish me to investigate why your model is infeasible unless overproduction is allowed, you should provide me the model input files (all *.DD, *.RUN files for the case DEMO_T0). Because the model seems to be just some demo model, I think you could just upload those files here (zipped).
It would be very kind and helpful from you Antti!
It is a little extended demo model, mainly in the fuels for transport. The model input files are attached.
Thank you.
Having the model at hand, it was easy to see. You have defined the commodity TRAELCT on the DAYNITE level, and the demand level for it is varying over timeslices according to the demand profiles. However, the only process supplying TRAELCT is TRAELCT00, which was defined on the ANNUAL level. An ANNUAL level process (with PCG=output) can only produce the outputs evenly throughout the year (unless the output would have a COM_FR profile). So, it is immediately clear that there was inevitably overproduction in some timeslices, if TRAELCT00 was supposed to satisfy all the demand.
I tested fixing the issue by changing the PRC_TSL of TRAELCT00 to DAYNITE, and the problem with TRAELCT was vanished. There was neither overproduction of TRAELCT nor dummy imports of it. The TRAELCT market was thus now cleared.
