In the first version of well collections, the most important thing to understand is that a well collection is a project level entity. It essentially behaves just like a project level well. The main difference between a well collection and a project level well is that a well collection can be assigned wells. I am using the word “assigned” because it is important to understand the wells that are contributing volumes to a collection don’t technically exist “in” the collection. This means that wells in a collection will always exist as a separate entity in the project while in a collection. Additionally, the wells contained within a collection can influence the production for that collection (see How to Aggregate Volumes for a Well Collection).
In the first version of well collections, well collections can only be added to scenarios and forecasts (not type curves or schedules). Therefore, as a project level entity, users have the ability to do anything they could do to a project well, to a collection in a forecast or scenario (i.e. run auto forecasts, apply type curves, run economics, etc.)
As mentioned above, a well collection can only be created while in a project. In addition, collections can only be created in the project wells page. Collections cannot be created via data import but can be updated via data import (see Data Import Compatibility). There are two options for creating collections:
The first is “Create Wells Collection” which allows a user to create a single well collection. In the project wells page, click the “Collections” drop down and select “Create Wells Collection”. By clicking this option, the user will be navigated to a popup menu where they can name the collection and assign headers to that collection. Note that, like a created well, headers can be edited for a collection at any point in time after the collection is created. After naming and assigning headers to the collection, the user can click Create and the collection will appear on their project wells table.
Figure 1: Creating a Well Collection
The second option for creating collections is the “Mass Create Wells Collection”. This option works similar to mass creating econ groups in the scenario module. By choosing this option, users are able to select a header and create a well collection for each unique instance of that header for all wells in their project. Additionally, the user can choose their own name for the collections or choose the “Assign Header Criteria as the Wells Collection Name and Selected Header”. If the user chooses to type their own name, the resulting collections will be named “[inputted name]-1, [inputted name-2], etc. If the user selects the latter option, the unique instances in the selected header will be applied for the collection name AND to that header.
Note: Currently there is a limit of 1000 well collections per project.
Figure 2: Mass Creating Well Collections
Since collections are project level entities, deleting a collection will permanently delete it from the environment. Deleting a well collection can only be done in the project wells page. To delete a collection, navigate to the project wells page, select the collection or collections (shift+click/control+click) you would like to delete, and navigate to the “Delete Wells Collection” option in the Collection drop down. In the resulting popup window, the user will be required to enter a confirmation message to delete the collection. It is important to note that like deleting a project well or removing a company level well from a project, deleting a collection will remove it from any scenarios or forecasts in the project and deletes all unique econ models made for the collection. It is also important to note that deleting a collection has NO EFFECT on the wells in the project.
It is important to understand that wells can only be added to a collection if they exist in the same project as the collection. Additionally, wells can only be added to a collection after it has been created. Adding wells to a collection can only be done in the project wells page. Adding wells to a collection can be done in a couple of ways. First, the users can navigate to the project wells table and select the well or wells (shift+click/control+click) they would like to add to a collection. Then, the user can either open the Collections drop down and select “Add Wells to Collection” or right click on the selected well(s) and select “Add selected X Wells to Wells Collection”. Regardless of which method they choose, they will encounter a popup that will allow them to select which collection they would like to add the well(s) to. It is important to note that, in the first version of well collections, users can only add wells to one collection at a time. Another important note is that once the well is added to a collection, you will notice that it still exists like normal in the project wells table AND is shown in the collapsable “rollup” for the collections the well is in.
Note: Currently there is a limit of 2,000 wells per well collection.
Once you have created a well collection and added wells to it, you will notice a new “Collection” column on your wells table. In this column, there is a collection icon, a tag that shows how many wells are in the collection, and a dropdown arrow. Clicking the dropdown arrow will allow you to “expand” the collection and see what wells are contained within it. Additionally, the wells in the collection will appear greyed out. IMPORTANT: This might cause confusion for users, and it is important to understand. For any well that exists in a collection, it will be shown in the wells table and in the collection. The version of it in the collection is a visual indicator of that well being tied to that collection. It does NOT mean that well is copied in any way. Users can edit header data and production data for the well as it is viewed in the collection or wells table and the changes will be reflected between each. Therefore, it does not matter which “version” of the well they make changes to from the wells table
Another addition for well collections in the well tables and filter page is the “Wells Collection” Boolean filter. This filter allows users to quickly filter their well sets down to only well collections. Users can find this filter anywhere in the platform.
Removing wells from a collection can only be done in the project wells page. Similar to adding wells to a collection there are a couple ways to remove a well from a collection. The first is by navigating to the well as it exists IN the collection. This means you will find the collection the well is in and expand that collection and select the wells in the collection that you would like to remove. From here, you can either right click and select “Remove Selected Wells from Wells Collection [name of collection]” or navigate to the Collections dropdown and select “Remove Wells from Collection. Note that you can select multiple wells at once and select wells across different collections. Also note that selecting the well as it exists in the collection and removing will only remove the well from that collection. If you find the well as it exists in the wells table and right click, you will notice the message says “Remove Well from X Collections” where X is the total number of collections that well exists in. Doing so will remove it from all collections.
Like any other project level entity, a well collection can be copied. To copy a collection, navigate to the “Collections” dropdown in the project wells page and select the collection or collections you would like to copy. Simply right click on the collection(s) and choose “Make Copy”. You will notice that a new collection will be created that has the same name as the original but with a “1” suffix. This copy will contain the same wells as the original. Additionally, it will have the same headers as the original other than a different INPT ID.
The main thing that sets collections apart from project level wells is the ability to aggregate the volumes of all wells contained in a collection as the production for that collection. For the first version of well collections, this is a manually run process that exists under the “Collections” dropdown in the project wells page. By selecting this option, users will trigger a long running operation that, once complete, will have aggregated ALL collections in the project.
What streams can be aggregated?
For v1, users will be able to aggregate volumes for Oil, Gas, Water, and all Company Custom Streams
What resolution can I aggregate?
For v1, clicking the aggregation button will run aggregation on monthly and daily for all collections.
How will I know when I ran aggregation last?
For v1, there will be a timestamp under the run aggregation button that will show the user the date and time at which aggregation was last ran for the collections in the project.
Once the production is aggregated, the collection and its production can be used like any project level well with a few exceptions. First, users will not be able to edit the production of their collection via the production table or well info menu. For now, all production values will be greyed out for a collection. Therefore, the only way to change production for a collection is to run aggregation or through a form of data import (see Data Import Compatibility). Additionally, directional survey data will not be usable for collections. When selecting a collection in the wells table, the “Directional Survey” option at the top will be disabled.
NOTE: To populate calculated columns for collections (i.e. cum oil, months produced, etc.), users will need to first run aggregation and then run calcs on the well collections.
Like project wells, well collections can be added to forecasts. It is important to note that when adding a collection to a forecast, the wells contained within that collection are not added to the forecast. If you navigate to the forecast wells table and expand your collection, you will see the contained wells but any forecasts you run will not be applied to those wells. The wells must exist in the forecast to be forecasted. Other than that, collections behave just like project level wells in a forecast. You can run auto forecasts on them, manually edit their forecasts, run proximity forecasts, diagnostics, etc. The only difference is that in the first version of well collections, you will not be able to forecast project custom streams for a collection. Collections will also be distinguished with an icon on the top right of its grid with a count of the wells in that collection
Like project wells, well collections can be added to scenarios. Like with forecasts, when a collection is added to a scenario, the wells contained within the collection are not added to the scenario. In a scenario, the user can assign any type of econ model to the collection and run full econ, single well econ, rollups, and anything else you can do to a project well. Like in the forecast module, collections will have a collections icon next to the collection name in the Well Name column on the scenario grid table.
Figure 11: Using Well Collections in a Scenario
Since collections can have headers assigned to them, they can also have scenario and type curve lookup tables and embedded lookup tables assigned. This works the same way it does for project level wells. It is important that users understand that collections have headers that exist separately from the wells assigned to them. Therefore, the users must make sure their collections have headers populated if they want to reference that header in a scenario lookup table, type curve lookup table, or ELT and assign it to a collection in a scenario.
Forecast and Scenario Import
The first thing to note when importing forecasts or scenarios containing well collections is that we will always match collections to collections and wells to wells. In the unlikely scenario that users somehow match IDs between collections and wells, we want to prevent well forecast/models from overriding collections forecasts/models.
Importing forecasts and scenarios with well collections essentially works the same way as merging projects. There is one main difference. If a collection exists in a project, the wells assigned to that collection MUST exist in that project as well. However, if a collection exists in a forecast or scenario the wells assigned to that collection do not necessarily have to exist in the forecast or scenario as well.
If there are matching IDs between a collection in the destination project and a collection in the origin forecast/scenario, the origin collection is replaced with the destination collection completely. The resulting forecast/scenario would contain the destination collection. Any curves/models that were applied to the origin collection are now applied to the destination collection.
If there are not matching IDs between a collection in the destination project and a collection in the origin forecast/scenario, AND the Overlapping Wells Only is toggled OFF, the origin collection will be brought into the project. In this case, we also look at the wells assigned to the “new” collection. If any wells assigned to the origin collection have matching IDs with wells in the destination project, those wells will replace the wells IN THE COLLECTION. If the wells in the origin collection do not have matching IDs with any wells in the destination project, those wells will be brought into the project. Again, this is only if there are not matching IDs between collections and the Overlapping Wells Only toggle is disabled.
Project Sharecode
When sharecoding a project that contains well collections, the collections will behave just like a project level well. Any collections in the project will exist exactly as they did in the origin project (Just with different INPT IDs). The production for any collections will exist exactly as it was since the last aggregation run or data import in the origin project.
Project Copy
Copying a project with collections is straightforward. Any collections in the copy will exist exactly as they did in the origin project (just with different INPT IDs). Since collections are project level entities, there is no worry for duplicates of anything. Additionally, the production for the collection will be whatever it was after the last aggregation run or data import in the origin project.
Forecast and Scenario Copy
Copying forecasts and scenarios with well collections is also straightforward. Since users can only copy forecasts and scenarios contained within a project, copying will result in a duplicate of the forecast or scenario with the same collections and wells and the same forecasts or econ models applied to those collections and wells. Like with project level wells, no duplication of wells or collections occurs.
Project Merge
Merging projects with well collections works similar to importing forecasts/scenarios, but is a little simpler.
If there are matching IDs between collections
The collection from the top ranked project will be brought in as it existed in the top ranked project (i.e. with the same wells assigned to it and the same production/headers)
If the collection in the bottom ranked project was in any forecasts or scenarios, the collection will be replaced with the collection from the top ranked project and any curves/models applied to the bottom ranked collection will be applied to the top ranked collection. As far as wells contained in these collections, the rules for importing forecasts/scenarios still apply.
If there are not matching IDs between collections
The collection from the bottom ranked project will be brought into the new project with the same production and headers. However, now we will look at the wells assigned to that collection. If there are any ID matches between the wells assigned to both collections, the well from the top ranked project will take the place of the bottom ranked well and the top ranked well will now be assigned to the “new” collection.
Again, for any forecasts or scenarios that the collections existed in, the rules for importing forecasts or scenarios still apply.
Users will also note that we have added a “Merged Wells Collections Final” counter to the Merged Project Well Count section of the Project Merge menu. This is a visual indication of how many collections it found that have matching IDs
Scenario and Forecast Merge
Since only two scenarios or forecasts in the SAME project can be merged, merging scenarios or forecasts that contain well collections is straightforward. In the merge scenario menu, the merged well count will include all wells and well collections with different INPT IDs (should be all of them excluding company level wells). The ranking of the projects only dictates what models or forecasts are applied to entities with matching INPT IDs (i.e. if you have the same collection or well that exists in both forecasts or both scenarios).
CSV Import
The user will need to run aggregation again to update this. This is similar to Auto Run Calcs only working for company level imports. Since collections are project level, well calcs and therefore aggregation will not be updated until the user runs these functions in the project.
Note: Upon creation, a well collection possesses the following:
Scope: Project
Source Internal
ChosenID: INPTID (randomly generated just like when creating a project level well)
API/SYNC
Since well collections are project level entities, users can update anything for collections that they can for project level wells. This means that, given an identifier for a collection, users can update the production and headers for a collection, add/update forecast segments for a collection, add/update econ models assigned to a collection and more (see ComboCurve API docs -> projects -> {projectId}). Additionally, like CSV imports, users will be able to insert production records for a collection via the API.
Since collection aggregation cannot be triggered via the API, it is important to note that if a user updates the production of any wells tied to a collection, those changes will not be reflected in the collection’s aggregated production until they run aggregation via the project wells table. Also, if users update the production of a collection via the API, the “Last Updated” timestamp in the wells table will not reflect when those updates occurred. The Last Updated timestamp only captures when that button is clicked via the ComboCurve UI.
We have added warnings for how collections interact with the API to the API docs, so double check that documentation if you have any questions.
NOTE: Importing production data for a collection will overwrite any aggregated production for that collection. Then, if the user runs aggregation after importing data, the imported data will be overwritten by the aggregation results for the wells in the collection.
We do not recommend updating the production of a collection via CSV import or API/SYNC import. Users should be updating the production of wells and then running aggregation via the project wells table.
Aries/PHDWin Import
Although Aries and PHDWin have similar functionality to our version of well collections, we will not support any special cases for well collections when importing or exporting Aries or PHDWin databases that contain well collections. For now, well collections will be treated as a well, so when exporting to Aries/PHDWin they will look like a well and when importing they will be converted to a well.