Veda2.0 Released!


Need help with reviewing DAC technology specification
#1
Hello,

This is my first time introducing a technology to the TIMES model. We are building on EPA's 9 region TIMES Model for the United States - EPAUS9rT_v20.2. 

Sets: PRE 
TechName: DACCCS (direct air capture process)
Tact: kt (short ton)
Tcap: kt/year (short ton per year)

With the following characteristics:

TechName: DACCCS
Comm-IN: ELCCO2 (CO2 emissions from power generation), ELCNGCEA (natural gas to combined cycle for which emissions are accounted for)
Comm-OUT: CO2S (CO2 captured)
CAP2ACT: 1
NCAP_COST: 0.11249 $M (based on $124/ metric ton internal cost estimate)
NCAP_FOM: 0.03955 $M (internal cost estimate)

NCAP_VOM: 0.0526 $M (internal cost estimate)
VDA_FLOP(cg=ELCCO2): 1.33 kt (is this the correct way to indicate 75% rate of capture?)
VDA_FLOP(cg=ELCNGCEA): 0.0099 PJ (derived from an estimate 11 GJ natural gas consumed per metric ton CO2 captured)
NCAP_DRATE=0.1
AFA = 0.9
PEAK = 0.9
ENV_ACT~ELCCO2 =?? (Unsure how to capture this. This should be a negative number which effectively means CO2 absorbed from flue gas of auxiliary plant).

By running the model with above description, no DAC is deployed. Rather, other NG+CCS or Coal+CCS technologies are being used. We are looking into introducing carbon taxes or DAC credits to incentivize DAC deployment, but I also wanted to ensure that this setup looks correct to an experienced TIMES modeler.

Any help or suggestions are appreciated. Thank you.

Smriti.
Reply
#2
Welcome to the Forum.

The TIMES modeling framework provides quite a lot of flexibility and freedom for the modeler to choose between different modeling approaches, which I think is a good thing, but may require some efforts on learning the various details of the TIMES functionality. Different approaches may also make it less easy to comment on an individual modeling approach without seeing the "full picture", like in your example case of DACCS.  Therefore, below I just try to give first some general thoughts, and then raise some questions.

First, you should keep in mind the formulation of commodity balances in TIMES, which basically all have the following generic relation for each commodity com in region reg and year t (omitting timeslices here for simplicity):

   Production(reg,t,com)  =  Consumption(reg,t,com) + ComNet(reg,t,com)

In many cases, the variables ComNet(reg,t,com) are just internal slack variables, meaning that the equation is actually an inequality, requiring that production must always at least satisfy the consumption. However, in the case of actual GHG emissions, the variables ComNet(reg,t,com) are usually explicitly included, and play an important role: The Production of emissions represents the release of emissions from the emission sources, the Consumption represents the sequestration of emissions into emissions sinks, and the ComNet represents the difference: the net amount of emissions released. Here, you should also bear in mind that the variables ComNet(reg,t,com) are by default restricted to non-negative values (they have a lower bound of zero). Hence, to enable negative net emissions, the modeler must explicitly remove the zero lower bounds or replace them with some negative bound values.

However, for some other emission accounting commodities, one may need to ensure that Consumption is exactly equal to Production. An important common example is the amount of CO2 captured, whenever the captured amount is also modeled as an immediate emissions reduction, because in such a case one should make sure that the full amount of the captured CO2 is subsequently getting appropriately transported and permanently sequestered somewhere, typically in a geological storage. Therefore, for commodities representing the captured amounts, the ComNet(reg,t,com) variables should often be defined with a fixed bound of zero, to ensure that all of the captured amount will, in fact, be delivered to a permanent storage, and are not released to the atmosphere.  Moreover, if you are indeed crediting the emissions reductions already at the capture technology, and some of the captured amount would be directed to e-fuel production (CCU) instead of sequestration, you would need to make sure that either the captured emissions are released back to the atmosphere at the synthesis plants (if the e-fuels are assumed carbon-neutral), or you define the e-fuels with emission factors corresponding to the amount of carbon embedded in them, like for fossil fuels. Another, different modeling approach would be to postpone the actual emission reduction until the captured CO2 is actually sequestered (e.g., at the storage processes), and then you could consistently treat any e-fuels produced from the captured CO2 as carbon-neutral (with zero CO2 emission factor for combustion).

As indicated above, I am not sure I can fully understand your modeling approach, where some further confusion is also caused by referring to both metric tons (tonnes) and short tons. Anyway, below are some comments:

>  Comm-IN: ELCCO2 (CO2 emissions from power generation)

AL> This would mean that the process is consuming ELCCO2, i.e. the ELCCO2 net emissions are reduced by the amounts consumed by the DACCS process. This means that you have chosen the approach where the net emissions are immediately reduced at the DACCS process, before any transport and storage. Using ELCCO2 for this purpose might be an ok choice, but because DACCS is not directly related to power generation, more often I guess the choice would be TOTCO2 (a commodity representing the total CO2 emissions) instead of ELCCO2. Moreover, recall that the ComNet variables of ELCCO2 should in your case apparently be made free (lower bounds removed), to enable negative net ELCCO2 emissions.

> Comm-OUT: CO2S (CO2 captured)

AL> I guess this commodity flow would also define the activity (and capacity) i.e. the PCG of the process would be CO2S, and the capacity represents the maximum nominal net amount captured, per year?

>  VDA_FLOP(cg=ELCCO2): 1.33 kt (is this the correct way to indicate 75% rate of capture?)

AL> VDA_FLOP is a VEDA-specific attribute, which is translated to the equivalent ACT_FLO(r,y,p,cg,s) attribute of TIMES (see documentation, Part II). It defines the flow of commodities in cg in proportion to the process activity, in timeslice s. Your parameter value, 1.33 would thus define the input flow of ELCCO2 as being 1.33 times the flow of CO2S. However, as the input flow of ELCCO2 represents the reduction of the net ELCCO2 emissions, I am not sure how the captured flow (the flow of CO2S) could be only 75% of that reduction in net emissions? Shouldn't the flow of CO2S thus actually be equal to the input flow (if they are in the same unit)?

> VDA_FLOP(cg=ELCNGCEA): 0.0099 PJ (derived from an estimate 11 GJ natural gas consumed per metric ton CO2 captured)

AL> 11 GJ per metric ton would be 0.011 PJ/kt.  Here, I am confused by your assumption of using short tons for the amount captured.  But yes, if you wish to use such, it would translate to 0.0099.  But I think the official emission inventories are in terms of tonnes (i.e. megagrams, Mg), even in the US, and I think the amounts captured should be in the same unit.

> ENV_ACT~ELCCO2 =?? (Unsure how to capture this. This should be a negative number which effectively means CO2 absorbed from flue gas of auxiliary plant).

AL> For regular processes, you can have any single commodity only as an input or output flow, not both.  However, an additional negative output term would be equivalent to a positive input term (i.e. additional reduction in the net ELCCO2), which would be easy to model as such. But shouldn't that additional amount be included also in the captured amount CO2S, and as suggested above, shouldn't the total captured amount CO2S still be equal to the total reduction in the net ELCCO2?  In, other words, I am a bit confused here again.  Anyway, if it should be included in both flows (which are equal), while the activity should represent only the DAC capture, it is possible to model it in several ways, of which the simplest would be based on using PRC_ACTFLO to define the ratio of the total CO2S to the DAC activity.

> By running the model with above description, no DAC is deployed.

AL> Well, that may well be the optimal solution (because DACCS is more expensive), or if you think the marginal CO2 price is high enough for DACCS, can be related to some modeling error(s); difficult to say without seeing the "full picture".
Reply
#3
It would perhaps be illustrative to also see how other TIMES modellers have modelled DAC/DACCS. However, there do not seem to be too many publicly available TIMES models including DAC processes, apart from the JRC-EU-TIMES model. Looking at that model, there appear to be two DAC technology variants in the JRC-EU-TIMES, see their VEDA characterization below (I tried to assemble the most current parameters from the Subres and Scenario files of that model):
   

As you can see, the main difference between the two process variants is the input commodity for providing the HT heat for the process, based on chemical absorption. Both processes consume TOTCO2 in amounts equal to the CO2 captured, which is represented by the output commodity SNKCO2N.  This SNKCO2N commodity can subsequently be fed either to CCU processes (e.g. power-to-X) or transported to permanent geological CO2 storage. The model also does include full CO2 emission factors for the e-fuels produced from SNKCO2N, and so it handles the carbon balance consistently in that respect.

Note also that only the second technology variant explicitly considers the CO2 from the input fuel. The second variant has GASNAT as the fuel input (which is natural gas without any combustion emissions accounted), and you can see that the second variant assumes that the CO2 emissions from that natural gas are emitted to the atmosphere (see the emission factor 56 kt/PJ defined by the FLO_EMIS on the input flow of GASNAT). It thus seems that this technology variant in the JRC_EU-TIMES model does not consider the capture of those combustion emissions from the fuel gas, which apparently makes it less competitive. However, in the literature (e.g. Keith et al 2018), the investment cost of this chemical absorption concept usually seem to include the capture of the CO2 also from the natural gas combustion. In that respect the modeling is also different from yours, because you explicitly noted that the emissions from the natural gas input have been accounted for already upstream, and that they would be captured by the DAC process.

The first technology variant assumes that the HT heat can be provided to the DAC process by any technologies producing HETHTH in the model. Those upstream technologies may include also technologies with CO2 capture, and thereby the first DAC variant also appears quite consistent with respect to the overall carbon balances.

Anyway, I hope this comparative example can be of some additional help, because I think your technology seems to be also based on chemical absorption. It also highlights one notable difference compared to your data:  The investment costs appear much higher in the JRC-EU-TIMES model, which might indicate a mistake in your interpretation of the NCAP_COST parameter (NCAP_COST represents the lump-sum total investment cost, and not an annualized cost).  Another difference is the missing electricity input in your process, however, that could be explained by assuming an integrated power plant to be included in the process, although that would make the difference in the investment costs even further pronounced.
Reply
#4
Hello Antii,

Thank you so much for your detailed responses to my question. I will need some time to understand and implement your suggestions and will get back when I have made some progress.

regards,
Smriti.
Reply
#5
Hi Antti,
Please find my responses in line with your suggestions/questions and a short explanation of DAC configuration we are trying to model towards the end of this post.

(14-04-2023, 05:53 PM)Antti-L Wrote: Welcome to the Forum
...
...

As indicated above, I am not sure I can fully understand your modeling approach, where some further confusion is also caused by referring to both metric tons (tonnes) and short tons. Anyway, below are some comments:

>  Comm-IN: ELCCO2 (CO2 emissions from power generation)

AL> This would mean that the process is consuming ELCCO2, i.e. the ELCCO2 net emissions are reduced by the amounts consumed by the DACCS process. This means that you have chosen the approach where the net emissions are immediately reduced at the DACCS process, before any transport and storage. Using ELCCO2 for this purpose might be an ok choice, but because DACCS is not directly related to power generation, more often I guess the choice would be TOTCO2 (a commodity representing the total CO2 emissions) instead of ELCCO2. Moreover, recall that the ComNet variables of ELCCO2 should in your case apparently be made free (lower bounds removed), to enable negative net ELCCO2 emissions. 

SS> Yes, we want to remove emissions at the "capture" stage itself as our estimates include T&S costs in them. We have duly noted your second point and will update ELCCO2 to TOTCO2 soon. I also checked ELCCO2 in model results and it has negative Var_Fout in some rows so I am assuming ComNet bounds have been removed?

> Comm-OUT: CO2S (CO2 captured)

AL> I guess this commodity flow would also define the activity (and capacity) i.e. the PCG of the process would be CO2S, and the capacity represents the maximum nominal net amount captured, per year?

SS> Yes, that is what we are aiming for!

>  VDA_FLOP(cg=ELCCO2): 1.33 kt (is this the correct way to indicate 75% rate of capture?)

AL> VDA_FLOP is a VEDA-specific attribute, which is translated to the equivalent ACT_FLO(r,y,p,cg,s) attribute of TIMES (see documentation, Part II). It defines the flow of commodities in cg in proportion to the process activity, in timeslice s. Your parameter value, 1.33 would thus define the input flow of ELCCO2 as being 1.33 times the flow of CO2S. However, as the input flow of ELCCO2 represents the reduction of the net ELCCO2 emissions, I am not sure how the captured flow (the flow of CO2S) could be only 75% of that reduction in net emissions? Shouldn't the flow of CO2S thus actually be equal to the input flow (if they are in the same unit)?

SS> Please see description of our DAC process below to understand the "75%" rate.

> VDA_FLOP(cg=ELCNGCEA): 0.0099 PJ (derived from an estimate 11 GJ natural gas consumed per metric ton CO2 captured)

AL> 11 GJ per metric ton would be 0.011 PJ/kt.  Here, I am confused by your assumption of using short tons for the amount captured.  But yes, if you wish to use such, it would translate to 0.0099.  But I think the official emission inventories are in terms of tonnes (i.e. megagrams, Mg), even in the US, and I think the amounts captured should be in the same unit.

SS> We will update all units to metric tons. The input files that were handed down to us aren't very good at mentioning units explicitly, so we had this confusion.

> ENV_ACT~ELCCO2 =?? (Unsure how to capture this. This should be a negative number which effectively means CO2 absorbed from flue gas of auxiliary plant).

AL> For regular processes, you can have any single commodity only as an input or output flow, not both.  However, an additional negative output term would be equivalent to a positive input term (i.e. additional reduction in the net ELCCO2), which would be easy to model as such. But shouldn't that additional amount be included also in the captured amount CO2S, and as suggested above, shouldn't the total captured amount CO2S still be equal to the total reduction in the net ELCCO2?  In, other words, I am a bit confused here again.  Anyway, if it should be included in both flows (which are equal), while the activity should represent only the DAC capture, it is possible to model it in several ways, of which the simplest would be based on using PRC_ACTFLO to define the ratio of the total CO2S to the DAC activity.

SS> Please refer below for our DAC process.

> By running the model with above description, no DAC is deployed.

AL> Well, that may well be the optimal solution (because DACCS is more expensive), or if you think the marginal CO2 price is high enough for DACCS, can be related to some modeling error(s); difficult to say without seeing the "full picture".

SS> Another member of our team is working on tax credits inclusion to make it more lucrative.

Our process configuration includes the use of an NGCC plant to provide the electrical auxiliary load of the DAC system. CO2 present in the flue gas from the NGCC plant is captured at a rate of 90 percent. The purified flue gas leaving the NGCC absorber is co-mingled with inlet air and passed to the DAC air contactors. The air contactors remove 75 percent of the CO2 from the inlet air. Purified air and flue gas leave the system.

I hope this makes it clearer on why we have ELCCO2 both as input and output. The input is from "air" and output is the 10% that DAC couldn't capture from the NGCC flue gas.

Please let me know if you need anything else to get a better picture. Thanks a lot!
Reply
#6
> our estimates include T&S costs

Oh, but that would mean that using the captured CO2 for any CCU purposes would be too expensive. Are you ignoring such downstream uses of the captured CO2?

> I also checked ELCCO2 in model results and it has negative Var_Fout in some rows so I am assuming ComNet bounds have been removed?

Negative Var_Fout does not imply that ComNet bounds have been removed. You should use COM_BNDNET to remove them (see Using negative emissions)

> The input is from "air" and output is the 10% that DAC couldn't capture from the NGCC flue gas.

Ok, but I understood you have already accounted the full combustion emissions for natural gas, upstream?  If that is the case, you should not model the 10% that DAC couldn't capture with an emission output, but just include 90% of the natural gas emissions in the total emissions reduction (i.e. either in the input flow of CO2, or as a negative output of some other CO2 commodity (e.g. ELCCO2 could be used if you now use TOTCO2 for the input). And I think that should be also included in the captured amount, no?  In other words, shouldn't the flow of CO2S thus be equal to the input flow (or the input flow minus the negative output flow, if you want to model the capture from the flue gas with a negative output flow)?

Concerning the air contractors removing 75 percent of the CO2 from the inlet air, modeling that percentage seems unnecessary to me, as I cannot see it affecting much anything. As far as I can see, the costs and inputs are all defined per unit of CO2 captured from air, and so the uncaptured amount would neither affect the costs, nor the energy used, nor the net emission reduction, would it?  It simply returns into the atmosphere. Nonetheless, of course you could model the gross amount of CO2 in the inlet air by adding a dummy input for that flow, if you like.
Reply
#7
Hi Antti,

1. Yes, we are ignoring any downstream uses of CO2 for the time being.

2. I will look into COM_BNDNET as per your suggestion.

3. We were trying to go for the negative output flow option to convey 90% capture of flue gas hence I asked "ENV_ACT~ELCCO2 =?? (negative)" in my original post. Yes, it should be reflected in the CO2S amount. My issue in getting to this negative number is defining it in per-kilo-tonne terms. The emissions accounted natural gas being fed to DAC system has per-petajoule emissions, specifically, it is 0.058 MtCO2 emitted per PJ of NG burnt. I am confused how to indicate "reabsorption" of these emissions by DAC in MtCO2 per ktCO2 (captured) terms. Could you help here, please?

4. I understand now that CO2S output flow should exactly equal input flow because we are modeling in "CO2 captured" terms. Thanks for clearing that up!

Thanks a lot for your continued engagement.
Reply
#8
Ok, thanks for the clarifications, which have provided me a much better picture, although still not complete. It is still not quite clear what should actually be the basis of the investment and fixed costs and the energy use: Are they expressed per unit of captured from AIR only, or per unit of total CO2 capture?  That would be quite crucial information for the correct modeling.  Anyway, because in the literature DAC costs and energy inputs are usually expressed per unit of captured from AIR only (for example, Keith et al. 2018 explicitly states that), I am assuming so in what follows below.

> I am confused how to indicate "reabsorption" of these emissions by DAC in MtCO2 per ktCO2 (captured) terms. Could you help here, please?

Based on the picture I have obtained thus far, I made some example variants for defining such  a DAC process (including capture of the flue gas emissions), based on the following assumptions:

  ● The activity should represent the amount captured from AIR only (because the investment and fixed costs are per unit of CO2 captured from AIR).
  ● The variable costs, on the other hand, should be applied to the total amount captured (because no CCU is assumed and all captured CO2 must therefore be transported and stored, and the variable costs include those costs).
  ● In other respects, the total amount captured is not necessary to be represented as a process flow (because no downstream CCU is assumed, and the transport+storage costs are already included), but only when convenient.
  ● The emissions from the gas input have already been accounted upstream (as you have stated), and the capture from the flue gas should thus be included in the emission reduction(s).
  ● I assume the emissions (TOTCO2, ELCCO2) are in kt(CO2). (I am confused why you said "emissions by DAC in MtCO2 per ktCO2 (captured) terms", because I think earlier you mentioned the DAC unit would be kt(CO2)?).

Please find my example process variants in the attached Excel file. I decided not to use your investment cost data, as I am not sure they correctly represent the full lump-sum investment costs (as opposed to annualized capex expenditures, which they should not be). And of course, if the assumptions above are not valid after all, the examples will not work correctly with your process data.  Let me know if you have questions about them…

[Edit]: If your emissions (TOTCO2, ELCCO2) happen to be in Mt(CO2), I would recommend modeling the DAC process also with that activity unit (not necessary, but it would be more transparent). Scaling the process parameters accordingly is quite simple. For example, if the combustion emissions are 0.058 MtCO2 emitted per PJ of NG burnt, the natural gas input is ELCNGA in PJ, and the ELCCO2 commodity is either in kt(CO2) or Mt(CO2), the negative capture factor would be either:

  FLO_EMIS(r,y,p,'ELCNGA','ELCCO2','ANNUAL') = −0.9 × 58 = −52.2; (ELCCO2 in kt(CO2)), or
  FLO_EMIS(r,y,p,'ELCNGA','ELCCO2','ANNUAL') = −0.9 × 0.058 = −0.0522; (ELCCO2 in Mt(CO2))


Attached Files
.xlsx   DAC-examples.xlsx (Size: 138.77 KB / Downloads: 13)
Reply
#9
Thanks for this, Antti. I will go over your suggestions and implement them.

For the investment costs, the study we are quoting them from (it is an internal study so unfortunately, I can't attach it here) presents final figures in the units - "Costs of capture (including T&S)/ tonne of captured CO2" or "COC". All calculations indicate a capture of ~900k tonnes per annum, used for the denominator. We are not able to determine whether to treat those as annualized or lumpsum costs. Should we just multiply the COC term with the lifetime of the plant to make it lumpsum?

The 900k tonnes is the net CO2 removed from air = Gross CO2 removed from air - CO2 from the flue gas emitted to air.

I used ktCO2 as the unit since in our model CO2S commodity was predefined and is measured in kt instead of Mt.

Hope this clarifies more.

Thanks,
Smriti.
Reply
#10
> The 900k tonnes is the net CO2 removed from air = Gross CO2 removed from air - CO2 from the flue gas emitted to air.

Oh, that's another piece of new info.  Then my previous suggestions (and the examples in the Excel file) are not fully valid for you (the difference being that the activity of the DAC process should then be reduced by 10% of the flue gas emissions, causing a small complication). However, the difference is relatively small, and the error would fall onto the "safe side".

> I used ktCO2 as the unit since in our model CO2S commodity was predefined and is measured in kt instead of Mt.

The important thing here is whether or not the unit is the same for the DAC technology and for TOTCO2/ELCCO2, which would make things more transparent.  Your comment above still does not clarify whether the TOTCO2/ELCCO2 commodities are also expressed in kt, which is what I assumed in my examples.

> Should we just multiply the COC term with the lifetime of the plant to make it lumpsum?

It is unfortunate if the internal study is so untransparent that it does not make clear how the capital costs should be interpreted. If they are annualized costs, you would need to know the capital recovery factor (or internal discount rate & lifetime) that has been used in the study for annualizing them, in order to convert them back to full investment costs.  The description "Costs of capture (including T&S)/ tonne of captured CO2" may also imply that all the cost components are actually levelized costs, based on some (perhaps undisclosed) assumptions on the utilization factor of the capacity in each operating year.  In such a case it would again be a bit more difficult to convert the values back to the original investment cost data (based on capacity, not activity).
Reply
#11
Hello Antti,

I took some time to go through your DAC suggestions file and also tried to assimilate other suggestions you gave in the past and have come up with the following formulation and results. Please note that we refer to this model version as "May model" and you will see scaled NCAP costs, etc. in this one.

I understood about 60% of your DAC suggestions so think the best way for me to improve our description further is if you could point out errors in my formulation (unless it is totally wrong). Greatly appreciate your help here.

Some points-
  1. We currently have CO2S in kt terms and all other CO2 (ELCCO2, etc.) in Mt terms. I know you suggested to have same unit but decided to run with this for the time being.

  2. We want the activity to represent the "net amount captured" (because the investment, fixed and variable costs are all "per unit of net CO2 captured" which includes flue gas).

  3. Hence, we also want INDCO2/ELCCO2 and CO2S to represent this "net captured" amount. I am unable to get CO2S to reflect this, but I feel Input side things are correctly accounted for.

  4. The emissions from the gas input have already been accounted upstream (I used ELCNGCEA gas input for this), and the capture from the flue gas should thus be included in the emission reduction(s) (I attempt to do this using ELCCO2 input).



Questions-
  1. Where to define TOTCO2? I read in documentation regarding ~COMAGG table but need help with correct placement. With TOTCO2 fixed, I would also be able to replace instances of INDCO2 and ELCCO2 with TOTCO2.

  2. How to make CO2S count flue gas emissions sequestered also? Right now, it only counts INDCO2. You mentioned PRC_ACTFLO but I feel that way activity will not account for flue gas capture.

  3. I don't understand the meaning of specifying CommGrp in ~Fl_T table which you did in your DAC suggestions sheet. Could you please explain?

  4. Any other mistakes that you see in attached?


thanks a lot,
Smriti.


Attached Files Thumbnail(s)
   

.xlsx   SubRES_dacktunits.xlsx (Size: 76.86 KB / Downloads: 7)
Reply
#12
Thanks for the follow-up.
I see you have made some good progress with your modeling approach, but I have the following comments on the process specification shown in your Excel file:

1) You say that you want "the activity to represent the "net amount captured" (because the investment, fixed and variable costs are all "per unit of net CO2 captured" which includes flue gas)".  However, it seems that you are nonetheless now using the specific energy consumption data from my examples (for natural gas and electricity), and the investment cost figure is exactly the same as in Keith et al (2018). But these data were all defined in terms of per tonne of CO2 captured from the air, and not per "net amount captured", and therefore those data cannot be used as such if your activity is "net amount captured". Can you comment on this confusion?

2) In particular, your statement that "variable costs are all per unit of net CO2 captured" sounds a bit strange, because I think the variable costs primarily consist of the T+S (CO2 transport & storage) costs, the data for which of course should be expressed in (currency units)/(unit of CO2 captured). If you model these costs in terms of ACT_COST (=VAROM) and your activity is "net amount captured", you cannot use that cost data as such, but it should be converted to be consistent with your different denominator. But if you do so, then you lose the transparency in the original parameter value.  That is why in my examples I defined the variable costs per unit of total CO2 captured (including the CO2 captured from the flue gas, which you exclude), to facilitate using the T+S cost data appropriately and transparently.

3) The energy consumption of the full-electric variant (SECDACE) seems too low to me. For that process, you have removed the natural gas consumption (used in the calciner process), but your electricity consumption is identical to the SECDAC process. Hence, it looks like you may be missing the energy consumption of the electric calciner?

> Where to define TOTCO2? I read in documentation regarding ~COMAGG table but need help with correct placement.

Ok, I did not know that you didn't have TOTCO2 in your model.  You can define it with parameters COM_AGG(r,y,com1,'TOTCO2')=1, where com1 is the component emission and TOTCO2 is the aggregate emission.  It should be defined for each of the sectoral CO2 emissions com1 to be aggregated into TOTCO2.  For an example defining TOTCO2 from the component emissions, see VEDA Advanced Demo.

> How to make CO2S count flue gas emissions sequestered also? Right now, it only counts INDCO2. You mentioned PRC_ACTFLO but I feel that way activity will not account for flue gas capture.

I showed that in my earlier examples, but of course they were based on somewhat different assumptions. For now (with the current information about your assumptions), I think would suggest to use a dummy commodity for the PCG, and the define CO2S as an output, with two FLO_EMIS parameters (like I did in two of my earlier examples).  And then, for transparency (good modeling practice), I would definitely define the T+S costs on that CO2S flow, and not on the activity.

> I don't understand the meaning of specifying CommGrp in ~Fl_T table which you did in your DAC suggestions sheet. Could you please explain?

FLO_EMIS expects a commodity group and a commodity. The commodity group specifies the source flow(s), and the commodity represents the derived emission commodity flow. In the ~Fl_T table I simply specified the source flows under CommGrp. But now, for your SECDAC process, you are defining ELCCO2 as an input flow, and you use the Input attribute for defining the flow per activity. This is again somewhat non-transparent, and would be better modeled with a FLO_EMIS defined on the natural gas input flow. In addition, because this emission flow is correcting for the upstream CO2 emissions accounting, I think it could well be defined as a negative output flow, as you originally wanted (to avoid including the captured CO2 in the gross 'ELCCO2' emissions):
   FLO_EMIS(r,y,'SECDAC','ELCNGCEA','ELCCO2',ANNUAL) = −0.9×0.058;

I would appreciate if you can still comment on the points I made above, and would be happy to answer any clarifying questions you still may have.
Reply
#13
Thanks for your replies and questions, Antti. From this I feel I have been mixing up "net capture from air" and "net capture". Upon rechecking I found that the 903,970 tonnes/yr figure is indeed "net capture from air". I apologize for the confusion. I am in the process of correcting my understanding and modeling based on this realization, right now. Hopefully, your recommendations and counter questions will make more sense to me now.

I checked recently and realized that the DAC studies which we have been referring to, are actually public so I am going to post the one with the data I am trying to use, here. Hopefully, by looking at it you would be able to help me find fixes more easily.

https://netl.doe.gov/energy-analysis/det...2b607f6987
Reply
#14
Thanks.  It looks like your DAC modeling is getting all set.  Shy
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)