Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handling well cost in fm_well_trajectory and 'fm_npv' #67

Open
slawekszklarz opened this issue Oct 16, 2024 · 0 comments
Open

Handling well cost in fm_well_trajectory and 'fm_npv' #67

slawekszklarz opened this issue Oct 16, 2024 · 0 comments

Comments

@slawekszklarz
Copy link

Currently, when optimizing well trajectories with NPV as objective funtion, the length-dependent well drilling cost is calculated by fm_well_trajectory forward job. The cost per km is provided in --config file:

wells:
  - name: WELLNAME                                       
    cost: COST_PER_KM                   

Then the calculated cost is inserted by fm_well_trajectory into the YAML input file --config to fm_npv replacing any values:

well_costs:
- currency: EUR
  value: COST
  well: WELLNAME

In addition fm_npv requires the standard transaction file --input (file passed between forward models, each adding information), i.e., JSON file with well names and dates at which to insert the drilling cost.

The issues with this approach are:

  • YAML config file for the fm_npv cannot be linked (instead of copied) with install_data in Everest config anymore since forward jobs for different realizations would be editing the same file with possibly different cost.
  • So far the standard was for forward model jobs to not edit users' YAML input files but only the transaction JSON file.
  • It's not clear which costs are per length and which are total.
  • There might be some cost in well_costs that will be unintentionally overwritten.
  • It's more natural for fm_npv to be responsible for calculating any costs instead of fm_well_trajectory which is responsible for geometric design.

One of possible solutions would be to move the drilling cost calculation to fm_npv:

  • fm_well_trajectory writes out well length for each well into the transaction JSON file. Field cost: COST_PER_KM is removed from the input.
  • fm_npv calculates the cost, a new input defining cost per length is introduced in the --config file:
well_costs:
- currency: EUR
  #value: COST
  value_per_km: COST
  well: WELLNAME

If value_per_km and value is specified then an error should be thrown at pydantic level. New approach would be backward compatible for the fm_npv.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: No status
Development

No branches or pull requests

1 participant