Refactor lactic module

[yalinli2]

Finally got around to work on #35 (opened 9 months ago 🙃 ), this would also use the new consolidated pretreatment process.

It's now giving similar MPSP, but GWP/FEC are off by about 1.3 kg CO2/kg lactic acid... Seems to be resulting from the very different natural gas usage before and after, working on figuring out this out.

[yoelcortes]

This looks amazing, @yalinli2, thanks for working on it. Please let me know if there is anything I can help with.

[yalinli2]

Thanks @yoelcortes ! Here comes the help request :)

So I've pretty much narrowed the difference, one minor thing is that the CHP in the lactic module considered ammonia usage to control NOx emission (according to the Davis 2018 report) while the Humbird report didn't, but I don't think it's a big deal and we don't really need to add it.

The main thing is indeed how much natural gas is used (and whether HHV or LHV should be used). I'm trying to compare the heating demand of the system, can you point me to where it's calculated in BT?

Kind of related, I realize that BT always satisfies both heating and electricity needs regardless of whether there's sufficient heat from the wastes/gas. Can we add an attribute to allow the use of grid power in the case that there is not sufficient heat from the grid (i.e., only buy natural gas for the heating demand but not electricity demand). I started to made some change in biosteam@boiler (https://github.com/BioSTEAMDevelopmentGroup/biosteam/pull/141), but I'm pretty sure I missed something in the calculation.

I know that for the average US grid, buying electricity from the grid does not make sense economically and environmentally, but in the future we'll be looking at regional grids and for some regions with a clean grid it might reduce GHG emissions by using the grid electricity. I know there's a standalone Boiler class, but I'm not sure if in the future we'll have biorefineries where it may need a turbogenerator in some scenarios but not others, thanks!

[yoelcortes]

OK!@yalinli2, I'll follow up with you by scheduling a meeting by email. Mainly, I'd like to discuss HHV vs. LHV and accounting for exit enthalpies.

[yalinli2]

@yoelcortes thanks so much for walking me through the BoilerTurbogenerator unit yesterday. I realized that the difference in the heating demand between the existing and refactored lactic acid module was due to the utility agent setting - I didn't include the other heating agents like medium/high pressure steams in the refactored module. With that fixed now the results are pretty much the same as before.

I might need to make additional updates when you finish updating the BoilerTurbogenerator with other changes we talked about yesterday, but it will be pretty minor.

Another thing that we could consider making improvements on: currently BoilerTurbogenerator consider natural gas and ash as utilities and their costs are included in BoilerTurbogenerator.utility_cost, but if the user initialize the BoilerTurbogenerator with natural gas and ash streams with a price, the costs will be double-counted. This could be a not-so-easy-to-spot bug and I realized this when I was trying to get the MPSP back on track.

I'm not sure how best to update this - I'm thinking that upon initialization, we could check for the price, if natural gas and ash have price, we issue a warning, and we change the price of natural gas and ash in bst.stream_utility_prices to both 0. I'm in favor of updating bst.stream_utility_prices rather than setting the price of the natural gas and ash streams to 0. I think a lot of people don't read the warnings as long as the module can run, since they provide the price for those streams, they likely will be updating those prices in a similar way in models and other analyses, so updating bst.stream_utility_prices might reduce the possibility of other bugs. Happy to discuss more on this :)

[yoelcortes]

@yalinli2, great point. I know it is natural for users to give streams prices and it may not be apparent that a stream is a utility stream sometimes...

I would recommend not to set the prices in bst.stream_utility_prices to zero when the utility stream already has a price because it would affect utility costs of other unit operations with that utility (e.g., the drum drier or a boiler from another system). Also, if users set the price of, for example, a natural gas stream after unit operation creation, more code would be needed to let BioSTEAM know something should be done about this to avoid double counting.

Instead, I think we can make the assumption that if the stream has a price, then we should treat it as a material cost or co-product regardless if it is listed as utility (so it's cost would not be included as as utility cost). In other words, a utility stream with a price will no longer be considered a utility stream. I made a change in BioSTEAMDevelopmentGroup/biosteam@8d23110 to do just this. What do you think? I think this is a good solution, but if you feel that there may be a better solution, we can always go back on this commit.

Thanks!

[yalinli2]

Valid points! Your solution looks great to me! Thanks @yoelcortes !