Unify costing packages

[bknueven]

Based on offline discussion, here is the proposal to unify the costing packages:

Changes to WaterTAPCosting Package:

1. factor_capital_annualization will go away and be replaced by wacc and plant_lifetime.

No changes to ZeroOrderCosting Package.

The unified costing package will have two build modes detailed and basic.

basic mode:

1. factor_total_investment will be a Var
2. factor_maintenance_labor_chemical will be a Var
3. All other factors, e.g., land_cost_percent_FCI, salaries_percent_FCI will be defined as Expressions with offsets based on factor_total_investment and factor_maintenance_labor_chemical. I.e., such that adjusting the high-level factors will automatically adjust the low-level factors.
4. The user will have direct control over the high-level factors but not the low-level factors.

detailed mode:

1. All the factors currently in the ZO costing package will be a Var
2. factor_total_investment will be an Expression
3. factor_maintenance_labor_chemical will be an Expression
4. The user will have direct control over the low-level factors but not the high-level factors.

[adam-a-a]

Regarding "factor_capital_annualization will go away and be replaced by wacc and plant_lifetime" -- since capital recovery factor is calculated based on wacc and plant lifetime, I think capital_recovery_factor should be included either as an Expression or a Var. If the latter were chosen, then the user could optionally fix capital_recovery_factor and either plant_lifetime or wacc. Maybe you had something like this in mind already but figured I'd add this clarification just in case.

[bknueven]

Regarding "factor_capital_annualization will go away and be replaced by wacc and plant_lifetime" -- since capital recovery factor is calculated based on wacc and plant lifetime, I think capital_recovery_factor should be included either as an Expression or a Var. If the latter were chosen, then the user could optionally fix capital_recovery_factor and either plant_lifetime or wacc. Maybe you had something like this in mind already but figured I'd add this clarification just in case.

I think the thing to do here would be to let capital_recovery_factor be a Var in basic mode and an Expression in detailed mode, and visa-versa for wacc/plant_lifetime. Thoughts?

Generally speaking I don't want to have too many Vars which would allow the user to create a trivially infeasible flowsheet.

[TimBartholomew]

I like this proposal. In general, I think the better approach is the basic mode (so I'd vote making that the default if the user doesn't specify detailed).

Why include expressions for the other factors that aren't needed for the basic mode (e.g. land_cost_percent_FCI, salaries_percent_FCI)? I would think since the basic mode doesn't need them, we just don't build them.

[TimBartholomew]

Regarding "factor_capital_annualization will go away and be replaced by wacc and plant_lifetime" -- since capital recovery factor is calculated based on wacc and plant lifetime, I think capital_recovery_factor should be included either as an Expression or a Var. If the latter were chosen, then the user could optionally fix capital_recovery_factor and either plant_lifetime or wacc. Maybe you had something like this in mind already but figured I'd add this clarification just in case.

I think the thing to do here would be to let capital_recovery_factor be a Var in basic mode and an Expression in detailed mode, and visa-versa for wacc/plant_lifetime. Thoughts?

Generally speaking I don't want to have too many Vars which would allow the user to create a trivially infeasible flowsheet.

I think this is a good solution. Well wait, I think its possible people would want to use basic mode and want to set wacc and plant_lifetime. So maybe we provide a configuration argument for whether the capital_recovery_factor being calculated or not.

[bknueven]

I think this is a good solution. Well wait, I think its possible people would want to use basic mode and want to set wacc and plant_lifetime. So maybe we provide a configuration argument for whether the capital_recovery_factor being calculated or not.

Sure, the more flexibility we give the user the more options we have to allow, document, and test against. So I guess the question is if allowing capital_recovery_factor to be directly settable is worth it (I don't have an opinion).

[adam-a-a]

I think this is a good solution. Well wait, I think its possible people would want to use basic mode and want to set wacc and plant_lifetime. So maybe we provide a configuration argument for whether the capital_recovery_factor being calculated or not.

Sure, the more flexibility we give the user the more options we have to allow, document, and test against. So I guess the question is if allowing capital_recovery_factor to be directly settable is worth it (I don't have an opinion).

Following how some of our previous work was conducted, I think we'd want to keep the option open for setting capital recovery factor directly although choosing wacc and lifetime is the more common approach. For example, in one of Tim's papers, he set capital recovery factor directly. In one of mine I also set capital recovery factor directly, but in other papers I calculated it based on wacc and lifetime.

I think we could document this and let the user know that they'd need to fix 2 out of 3 of those (and maybe we have 2 out of 3 already fixed by default).

[bknueven]

I am near ready to open a PR for this issue. I have a final question: what do we think of the following APIs for differentiating detailed vs. basic:

Option 1:

from watertap.costing import WaterTAPCosting, WaterTAPCostingDetailed

costing_basic = WaterTAPCosting()
costing_detailed = WaterTAPCostingDetailed()

Option 2:

from watertap.costing import WaterTAPCosting

costing_basic = WaterTAPCosting(detailed=False) #default
costing_detailed = WaterTAPCosting(detailed=True)

Option 3:

from watertap.costing import WaterTAPCosting

costing_basic = WaterTAPCosting(mode="basic") #default
costing_detailed = WaterTAPCosting(mode="detailed")

I have Option 1 already implemented. To maintain compatibility with the ZeroOrderCosting package the implementation of options 2 or 3 would probably return a different class, e.g., WaterTAPCosting and WaterTAPCostingDetailed, so they would be no different besides how they were invoked.

I am strongly leaning towards Option 1 because I think it is the most straightforward and transparent.