[DEFECT] No Depreciation and Amortization with 2 one-time cashflow in one component - Githubissues

idaholab / HERON

Holistic Energy Resource Optimization Network (HERON) is a modeling toolset and plugin for RAVEN to accelerate stochastic technoeconomic assessment of the economic viability of various grid-energy system configurations, especially with application to electrical grids and integrated energy systems (IES).

Apache License 2.0

22 stars 36 forks source link

[DEFECT] No Depreciation and Amortization with 2 one-time cashflow in one component #273

Closed mgarrouste closed 1 year ago

mgarrouste commented 1 year ago

Defect Description

Describe the defect I have a component with a flat and a scaling part in the capex cost that I modeled as 2 'one-time' cashflows with a depreciate node

What did you expect to see happen?

All the capex cashflows in the model should be depreciated and amortized

What did you see instead?

In my model none of the capex cashflows are depreciated nor amortized. I have reproduced part of this issue with the depreciate test input and then the second capex is not amortized nor depreciated.

Do you have a suggested fix for the development team?

Describe how to Reproduce Steps to reproduce the behavior:

I have attached files for my use case and the HERON depreciate test that show this issue
The problem can be seen in the out~inner files in the PROJECT Cashflow outputs
For HERON depreciate test see files in test.zip
For my use case see files in use_case.zip

Screenshots and Input Files Please attach the input file(s) that generate this error. The simpler the input, the faster we can find the issue.

Platform (please complete the following information): test.zip

OS: [e.g. iOS] use_case_files.zip
Version: [e.g. 22]
Dependencies Installation: [CONDA or PIP]

For Change Control Board: Issue Review

This review should occur before any development is performed as a response to this issue.

[x] 1. Is it tagged with a type: defect or task?
[x] 2. Is it tagged with a priority: critical, normal or minor?
[x] 3. If it will impact requirements or requirements tests, is it tagged with requirements?
[x] 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
[x] 5. Is a rationale provided? (Such as explaining why the improvement is needed or why current code is wrong.)

For Change Control Board: Issue Closure

This review should occur when the issue is imminently going to be closed.

[x] 1. If the issue is a defect, is the defect fixed?
[x] 2. If the issue is a defect, is the defect tested for in the regression test system? (If not explain why not.)
[x] 3. If the issue can impact users, has an email to the users group been written (the email should specify if the defect impacts stable or master)?
[x] 4. If the issue is a defect, does it impact the latest release branch? If yes, is there any issue tagged with release (create if needed)?
[x] 5. If the issue is being closed without a pull request, has an explanation of why it is being closed been provided?

mgarrouste commented 1 year ago

Even when only one one-time capex cashflow is in the HTSE component I still don't get any depreciation nor amortization for neither the HTSE component nor the other components with a capex cost (h2_storage and ft) No_dep_No_Am.zip

PaulTalbot-INL commented 1 year ago

There's something else going on in this case; unlike the example test case, which correctly shows values for "alpha" and "driver" in the LIFETIME component cashflow for depreciation/amortization, you show all zeros for the driver. I didn't notice what the input problem is immediately, but that's a sure sign of an issue in how the input is set up.

PaulTalbot-INL commented 1 year ago

I see that the depreciation is set up correctly:

.. ... cf htse_amortize_htse_capex ...
 ... ... ... D htse|htse_capex
 ... ... ... a [ 0.      0.05    0.095   0.0855  0.077   0.0693  0.0623  0.059   0.059
  0.0591  0.059   0.0591  0.059   0.0591  0.059   0.0591  0.0295  0.
  0.      0.      0.      0.      0.      0.      0.      0.      0.
  0.      0.      0.      0.    ]
 ... ... ... Dp 1.0
 ... ... ... x 1.0

... but it seems to be reading the driver htse|htse_capex as 0 when filling it in.

CashFlow INFO (compLife): ---------------------------------------------------------------------------
CashFlow INFO (compLife): Computing LIFETIME cash flow for Component "htse" CashFlow "htse_amortize_htse_capex" ...
CashFlow INFO (compLife): ...   driver  : htse|htse_capex
[...]
CashFlow INFO (compLife): LIFETIME cash flow summary by year:
CashFlow INFO (compLife):     year,   alpha   ,   driver  ,    cashflow    
CashFlow INFO (compLife):      0  ,  0.000e+00, -7.628e+08, -0.000000000e+00
CashFlow INFO (compLife):      1  ,  5.000e-02,  0.000e+00,  0.000000000e+00
CashFlow INFO (compLife):      2  ,  9.500e-02,  0.000e+00,  0.000000000e+00
...

However, this works correctly in the test case. Is there a custom function or something similar that's tinkering with the capex cash flow?

PaulTalbot-INL commented 1 year ago

For comparison, from the test case:

 ... ... cf source_amortize_capex ...
 ... ... ... D source|capex
 ... ... ... a [ 0.      0.2     0.32    0.192   0.1152  0.1152  0.0576  0.      0.
  0.      0.    ]
 ... ... ... Dp 1.0
 ... ... ... x 1.0

and

CashFlow INFO (compLife): Computing LIFETIME cash flow for Component "source" CashFlow "source_amortize_capex" ...
CashFlow INFO (compLife): ...   driver  : source|capex
[...]
CashFlow INFO (compLife): LIFETIME cash flow summary by year:
CashFlow INFO (compLife):     year,   alpha   ,   driver  ,    cashflow    
CashFlow INFO (compLife):      0  ,  0.000e+00,  0.000e+00,  0.000000000e+00
CashFlow INFO (compLife):      1  ,  2.000e-01,  1.002e+03,  2.004610476e+02
CashFlow INFO (compLife):      2  ,  3.200e-01,  1.002e+03,  3.207376762e+02
CashFlow INFO (compLife):      3  ,  1.920e-01,  1.002e+03,  1.924426057e+02
...

PaulTalbot-INL commented 1 year ago

I introduced a second amortized cashflow to the first and was able to see undesirable calculation effects similar to what you're seeing in this problem.

However, if I only have one capex per component, I have not yet been able to reproduce this problem.

mgarrouste commented 1 year ago

I was able to reproduce the issue when the capex is modelled with a one-time cashflow named 'componentname_capex' the amortization and deprecation are not computed anymore (see attached out~inner). See input test file attached that can be tested by creating a test_depr/ folder in HERON/tests/integration_tests/mechanics depr_issue.zip

PaulTalbot-INL commented 1 year ago

That is truly bizarre, thanks for finding a case we can look at.

PaulTalbot-INL commented 1 year ago

I found the difference to occur within TEAL.CashFlows.Amortizor.extendParameters, just to log progress. Working on understanding why this is different depending on the name.

Update: found it. Screenshot 2023-03-27 at 15 08 49

Looking for a better solution.

PaulTalbot-INL commented 1 year ago

See fix in https://github.com/idaholab/TEAL/pull/70. Until that is merged, you can avoid this issue by not putting underscores in CAPEX-type cashflows that are depreciated.

dylanjm commented 1 year ago

This issue is approved for closure due to the successful merge of idaholab/TEAL#70