GithubHelp home page GithubHelp logo

nrel / bioproducttransitiondynamics Goto Github PK

View Code? Open in Web Editor NEW
1.0 4.0 0.0 300.02 MB

A system dynamics decision support tool for bioproduct industry stakeholders who want to investigate how their decisions can impact the process of bioproducts gaining U.S. market share.

Home Page: https://bioenergymodels.nrel.gov/models/14/

Python 0.02% R 0.03% Jupyter Notebook 99.94% Awk 0.01% Batchfile 0.01% Shell 0.01%

bioproducttransitiondynamics's Introduction

Bioproducts Transition System Dynamics

This is the repository for all model development and analysis activities for the Bioproduct Transition Dynamics (BTD) model.

Organization

The primary model is BTD.mdl. Please make every effort to keep this model running after every commit where the model is changed.

Models under development and not yet integrated into BTD.mdl are stored in /submodels.

Files defining model inputs for analysis are stored in /inputs.

Vensim result files with extension .vdf are stored in /result-files unless they are the most current set of results, in which case they are stored in the top directory. Use care in naming older results files, and remove any that are no longer relevant.

Vensim results files are by default tracked in this repo. To have a VDF file ignored by the repo, name it with the ending -local.vdf. The majority of VDF files should be stored locally only, not in the repo.

Committing

Use the command git status to see files that have been changed since the last commit, and create multiple commits if multiple files have been edited in different ways. Commits to .mdl files should be the result of some observable change to the model.

Make your commit messages brief but explanatory. Add comments to your commits if necessary. If a commit addresses or closes an issue, tag the issue in the commit message using a hashtag and the issue number, for instance #31.

Vensim will frequently save new versions of a model when the model has only been opened and closed without any edits. Do not commit these changes; instead use the command git checkout -- BTD.mdl (changing the file name as needed) to reset the model to its previous versions.

Branching

The two branches that should (until the final model lock) remain in the repo are master and dev. master should always have a working copy of the BTD that gives correct results to our best knowledge. Small model changes can be made directly in dev, and we will pull dev into master regularly to keep our working BTD copy as up to date as possible. Larger model changes that will temporarily break the model or take multiple days to complete - for instance, when integrating a submodel into the BTD or when resolving a complex issue - should begin with a new branch off dev. Give the branch an explanatory name. Once BTD.mdl is running in the branch and related development is complete, create a pull request to pull the branch into dev and assign at least one reviewer.

Repo contents

Only the model itself, models under development, key results files, and any files necessary for running sensitivity and other analyses may be stored in this repo. All other files should be stored elsewhere.

bioproducttransitiondynamics's People

Contributors

rjhanes avatar bwbush avatar tonybologna95 avatar lauren-sittler avatar

Stargazers

 avatar

Watchers

James Cloos avatar National Renewable Energy Laboratory avatar  avatar  avatar

bioproducttransitiondynamics's Issues

probability of internal project success is too low

The "probability of internal project success" calculation also has an error. It has a limit of 0.4. By the end of the project the probability of success should be 1 or nearly 1 - it has succeeded.

"Number of stages to complete" was rounding up an integer. "Stages completed" stopped at 12 and never reached the final "13th" stage. We can either round down for the initial number of stages or alter the "Stages Completed" to make sure it reaches the last stage.

Rate of return in valley-of-death equation

@rjhanes @Lauren-Sittler

We have to be careful of the interpretation of the rate of return r in the valley-of-death equation, V > Σi=1N (( Ii (1 + ri)) / 𝚷j=n+1-iN Pj). The ri are not the annual rates of return, but instead are the rates over the whole investment, i.e. the quantity Ii(1+ri) represents the total cost of investment Ii, accounting for the cost of capital, financing, etc.

I think that we should replace (1 + ri) by (1 + r'i)T(i), where T(i) is the expected number of years before completion of the last stage and r'i is the required annual rate of return, which might be a constant r' independent of stage i.

Also, I think that a better name for expected internal investment amount by stagegate would actually be expected required investment value at stagegate, since it is the threshold that NPV (or other valuation) must exceed for the investment to be worthwhile.

add time delay to receipt of investor funds

if an investor ask is successful and the amount asked for is above zero, then the requested funds are received in the next time step

should we build in a time delay to reflect getting through the red tape of funds transfer?

compute idealized regulatory costs by forecast year

regarding my review of idealized NPV and idealized internal NPV, the equations are fine except that it approximates idealized regulatory costs by an analytic integration to compute their present value. For uniformity of approach, we could replace that analytic integration with the expected costs by forecast year, which would mean we'd have to add the [forecast year] subscript to idealized regulatory costs, but this will make almost no difference numerically. Instead, I'm renaming idealized regulatory costs to idealized regulatory cost PV, to make the approach clearer.

change model stopping criteria

Currently the model stops after a set run time.

Can we change that so the model stops upon achieving the success criteria or upon reaching a certain run time without success?

What's the return on investment for this change - will it really enhance the model/results?

label switch variables

Variables that are in fact switches are often better labeled as “X?” or “X switch” or “X indicator”. Example: “in business?” or “in business switch” or “in business indicator”

adjust IS equipment depreciation

the outflow IS equipment depreciation should be formulated such that IS Equipment Useful Value declines linearly.

After implementing, compare results to determine how big an impact this change has on the overall results.

researching should impact the rest of the process

the researching parameters in general are very uninfluential; the costs are accounted for in the income statement but that's the only way this view participates in the feedback loop

options include:

  • less researching leads to longer recovery time from failures
  • a history of less researching leads to more impactful failures
  • less researching means longer start-up periods for pilot, demo and commercial plants

Remove `idealized forecast` view

@rjhanes, I recommend that we remove the idealized forecast view and associated variables from the models. These were for creating an ensemble of alternative future forecasts, but I think that the model has evolved to use other approaches since this view was created. This won't affect the logic or results from the rest of the current version of the model.

break out Indicator Variables view

Divide into Development Stages (the Gantt chart bit), Flow Dampers and Indicator Variables.

This will reduce the view size and make all three sections easier to read, in theory.

errors in internal investor decision

  • Why is completing stages multiplying both sides of the inequality?
  • value threshold contains the future revenues discounted to present, but idealized internal NPV contains both the costs and the revenues discounted to the present, but discounted using the PV formula instead of the CRF formula. I think we need to delete the revenues from the right-hand side of the equation so that we are comparing probability-adjusted revenue on the left to the expected costs on the right, but using the same discounting formula on both sides.

calculate abandonment rate as fraction of Adopters

“abandonment rate” – I think this needs to be a fraction (default now is 100), and it should represent the fraction of Adopters who will de-adopt each year (subject to the “abandoning bioproduct indicator” variable).

update model start year?

Is it worth it to change the model start year to 2020, from 2015?

Results won't change, but it might be nice for publication graphics.

redesign and upgrade user input

Some input variables represent decisions or actions - things under control by the stakeholder - while others are exogenous variables that can be controlled by stakeholders in the model but not in real life. We can use color to distinguish these two types of input variables.

Breaking out groups of decision/action variables according to what kind of stakeholder (developer, investor, and so on) controls them would also add some clarity.

Maybe the final structure has one main panel of inputs that we have deemed most important to the model results, with additional panels organized as above and by views. Probably not a good idea to put an input panel on each view.

Ideas above from the preliminary model review in Dec 2019.

update success criteria

A "successful" bioproduct should mean both that bioproduct is being produced commercially and there's sufficient demand or an offtake agreement.

Right now we only require commercial production to be a success.

remaining project duration does not account for project lag when stages are missed for internal projects

This is definitely a problem in the "required technology readiness level" equation. The project lag is accounted for in the slope "expected technology readiness level progress" but not in the calculation for required technology readiness level. To fix the issue for this formula only you could add the project lag to the remaining project duration and put that sum in parentheses to be subtracted from the initial project duration. But a better question is - should we create a new variable to capture the corrected project duration or should we add the project lag directly into the project duration.

INTEGER(initial TRL + expected technology readiness level progress * (initial project duration - (remaining project duration + project lag)))

word of mouth impact should be proportional to Adopters

“word of mouth impact” needs to be driven by the stock of Adopters (not the stock of Non Adopters). This model is using a version of the Bass Diffusion Model and as such it really needs to conform to the (perhaps extended) equations from that model.

brief relevant NREL and DOE people on model and results

These are folks to brief relatively informally on what's going on with the model to solicit feedback around the project in general, potential future applications, and how to present results.

  • Zia Haq
  • Nicole Fitzgerald
  • Karlynn Cory (finance team, possible follow-on work)
  • Paul Schwabe (finance team, possible follow-on work)
  • Sam Baldwin

These folks were briefed on an older version of the model & analysis:

  • Jay Fitzgerald (was briefed on the older version of the model)
  • Jason Hanson
  • Mark Shmorhun

simplify feedstock selector and price logic

  • “feedstock selector array” – put in [0,1,0,0,0,0,0] form (rather than have separate equations for each feedstock, forcing the modeler to “pick” the right one)
  • Equation for “feedstock price” can be more elegant – use subscripts and then SUM across feedstocks to calculate

standardize naming conventions throughout

  • essential: variables / flows / parameters are all in lower case
    • the exception is where variable names start with acronyms like TRL, CFS - those can stay capitalized
  • essential: levels / stocks are in title case (capitalize most words except for the, and, ...) and always have boxes, even when used as shadow variables. Boxes have to be added manually to shadow variables by right-clicking and selecting the Box radio button.
  • where possible: flows are named as gerunds (-ing)

implement offtake agreements as a way to create demand for bioproducts

Offtake agreements are often entered in to before commercial production begins.

We can use some of the same logic used by investors/government funders to determine if an offtake agreement is likely or not.

The agreement terms (amount, time period) will need to be inputs as they vary widely from product to product.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.