Extend WELTRAJ/COMPTRAJ to support multi-segment wells for grid-independent wells #4524

verveerpj · 2025-03-17T09:42:54Z

This PR adds support for multi-segment wells to the WELTRAJ/COMPTRAJ keywords. If a well entry is added to the WELSEGS keyword, without defining the segment structure (i.e. only the first record), information provided by the COMPTRAJ and WELTRAJ keywords is used to generate multi-segment wells for that well (i.e. the missing WELSEGS records, and the COMPSEGS information).

In this PR the generated segments simply consist of a segment for each cell in the well trajectory generated from COMPTRAJ. A future extension should allow reading additional WELSEGS records to define the segments as usual, while still generating the COMPSEGS data from the COMPTRAJ data.

Currently, all options in the WELSEGS record are used. Only ROUGHTNESS is defaulted.

arturcastiel · 2025-03-17T10:31:37Z

jenkins build this for me please

blattms · 2025-03-20T14:05:42Z

You seem to be too egocentric 😅 . Skip the "for me" to call jenkins.

blattms · 2025-03-20T14:05:57Z

jenkins build this please

arturcastiel · 2025-05-13T09:37:05Z

@bska and @verveerpj, could you guys review this PR?

bska

It's a good start, but I would really prefer that Compsegs::Record remain a private implementation detail in Compsegs.cpp. Client code should not need to care about how we structure intermediate information.

bska · 2025-05-14T08:59:21Z

opm/input/eclipse/Schedule/MSW/Compsegs.hpp

 namespace Compsegs {


+struct Record {


There has to be a better way than to make this internal implementation detail public. What information do you really need to accomplish what you want to do?

I will check, maybe we can avoid passing records.

bska · 2025-05-14T09:36:45Z

opm/input/eclipse/Schedule/MSW/Compsegs.cpp

-    processCOMPSEGS(const DeckKeyword& compsegs,
+    processCOMPSEGS(const std::vector< Record >& compsegs_vector,


Could you not add a separate overload of processCOMPSEGS(), possibly by extracting the common pieces out to a private helper function, that would allow you to keep the Compsegs::Record structure private?

I am sure there is a way to re-arrange the code, I will need to find some time in the next weeks and I will have a go at it.

bska · 2025-05-14T09:39:02Z

opm/input/eclipse/Schedule/MSW/WellSegments.cpp

+        for (size_t is = 0; is < intersections.size(); ++is) {
+            const auto startMD = intersections[is].first;
+            const auto endMD = intersections[is].second;


You don't need the is index, so please use "range for" here,

for (const auto& [startMD, endMD] : intersections) { // ... }

bska · 2025-05-14T09:40:04Z

opm/input/eclipse/Schedule/MSW/WellSegments.cpp

+            const auto startMD = intersections[is].first;
+            const auto endMD = intersections[is].second;
+            const auto length = (endMD - startMD) / 2.0 + startMD;
+            const auto depth = length;


Does this (depth = length) mean that we (currently?) assume vertical wells only?

My (admittedly somewhat limited) understanding is that the depth is in fact a measured depth, so that would be valid. The test case does a non-vertical well, and we get the same compared to the keywords generated by ResInsight, so that seems to be working.

Does this (depth = length) mean that we (currently?) assume vertical wells only?

understanding is that the depth is in fact a measured depth, so that would be valid.

we get the same compared to the keywords generated by ResInsight, so that seems to be working.

I believe that at least as far as the rest of the simulator goes, the "length" is the MD and the "depth" is the TVD. Is that accurate, @GitPaean?

Thanks for bringing me here. You are right, and depth == length should only be possible for strictly vertical wells. For any other wells, it is problematic.

That was also what I understood to be generally so, but it seemed to different in this part of the code, if my understanding is correct. It may bea confusion with variable naming. In the manual of the COMPSEGS keyword there are also some DEPTH options that are defined as tubing lengths, which presumable are MD.

And in the keyword COMPSEGS , there should be only length/distance, there is no depth. Depth is calculated based on length/distance. The keyword definition should also be changed without using DEPTH. @gdfldm

Hm, it remains a bit confusing to me, this my understanding, which may be wrong, since its not really my area:

The documentation of COMPSEGS has DEPTH1 and DEPTH2, but the description describes both as a tubing length, which suggest to me it's MD. So, it seems the names are just confusing.

The documentation of WELSEGS also has DEPTH1 and DEPTH2, where the first is again a tubing length, so MD, that seems fine. The second is described as a depth of the tubing, suggesting its TVD. In that case, these should not be the same if the well is not vertical. However, ResInsight keeps both the same, when generating WELSEGS keywords for a non-vertical well, suggesting it thinks they are also MD. But that is strange, why would you need two identical columns?

So, the PR reproduces what ResInsight does, but it is actually unclear it it does what it should. Are we looking at a bug in ResInsight, or is the documtenation just wrong?

Hi, I do not work with ResInsight and we do not have control over what ResInsight does. If ResInsight does what you said, they have a bug. I do not use ResInsight regularly, but you can consider to report to them.

As mentioned previously, the OPM-flow document looks indeed confusing regarding the meaning of the items. I will report to @gdfldm for a potential correction.

That makes sense, I will change the PR to generate true depth instead of duplicating length. I will check again what ResInsight exactly does, and report it to them if they do it differently.

I have tried to clarify this the manual:
WELSEGS
COMPSEGS

verveerpj · 2025-08-08T15:15:20Z

I have now updated the code to address the length/depth situation so that non-vertical wells are now handled properly.

I have tested this against the WELSEGS/COMPSEGS keywords generated by Resinsight, and this gives now virtually identically results, giving me some confidence that is now working as intended. This test is included as a test case.

Code-related concerns have also been addressed, so I think this is ready for another round of review.

arturcastiel · 2025-08-12T06:20:20Z

jenkins build this please

arturcastiel · 2025-08-18T07:17:30Z

@verveerpj very good. the tests are successful. @bska and @GitPaean, could you check this please?

GitPaean · 2025-08-18T20:22:04Z

jenkins build this please

GitPaean · 2025-08-21T14:27:43Z

I was hoping to manage to look into this PR but I did not. I will be away for one week. If it is okay, I will review and merge it in the week after. Otherwise, if others have time before that, please feel free to do so.

arturcastiel · 2025-08-21T14:40:17Z

@GitPaean , @verveerpj is also off this week.

GitPaean · 2025-08-27T10:12:19Z

Hei, let us start from the design of the keyword system. I was not involved much in this development, please excuse me if I understand things wrong.

In theory, a well can be a segmented well or a standard well (no segments are involved), while can not be both. The keyword COMPTRAJ is to generate connections/perforations, and we can have multiple COMPTRAJ records for one well. Adding a flag to the COMPTRAJ record looks worrying to me. Simply, what we have a record with MSW yes while the other one with MSW no.

Furthermore, the concept of the multisegment wells is pretty abstract and numerical. It means the path of the MSW does not always follow the path of the connections (which is the physical perforations), and also we can decide how many segments we want for each well. It means the same well can have 5 or 10 segments depending what we want.

Based on the thoughts above, I suggest that we still use the keyword WELSEGS to indicate whether a well is multisegment or not. And also, with WELSEGS, we can design the MSW by specifying the numbers of the branches and number of the segments more freely.

Please let me now what you think. @verveerpj

With more discussion, I might understand the system better and let us work together to get a solid design for the way forward.

verveerpj · 2025-08-27T10:25:19Z

Hi @GitPaean,

Sure, I am open to changing the design. Let me discuss it with my colleagues at TNO and we will get back to you.

GitPaean · 2025-08-27T11:38:01Z

Hi @GitPaean,

Sure, I am open to changing the design. Let me discuss it with my colleagues at TNO and we will get back to you.

Great. Feel free to get me involved in the discussion any time.

verveerpj · 2025-08-27T12:50:14Z

We just had a short discussion, some of the main points we have:

WELSEGS offers indeed the flexibility to define segments as you like. We were not trying to bring that functionalilty to wells defined by WELTRAJ/COMPTRAJ. For now we duplicate the functionality that ResinSight has: given a well path, export WELSEGS/COMPSEGS that just split the wellpath into many small segments. So, we only really need the data from WELTRAJ/COMPTRAJ for that, at least for now. I imagine we could extend this by using additional information from WELSEGS to define segments in a more flexible way, given a path defined by WELTRAJ/COMPTRAJ, but that is not our goal at the moment.
As a result, we do not really need WELSEGS in addition to WELTRAJ/COMPTRAJ, at least at the moment, but we do need a way to specify that we want the segments, hence the MSW flag. I did indeed not take into consideration that there could be multiple entries, so the flags could be inconsistent. That will require some extra checks, I have to look into that. I guess that requires tracking the flags over multiple keywords, not sure how to do that...
We are open to alternatives for the MSW flag, but we do think that using WELSEGS for that would currently just make it more complicated for the user. But any ideas are welcome!

gdfldm · 2025-08-27T13:44:49Z

IMHO, I think it is worth considering using the WELSEGS keyword to specify that a well is a multi-segment well, perhaps just by specifying the well-name, and defaulting all the other items. The reason being that this is the standard method and it would probably be required in the future in any case for tubing ID, tubing roughness, etc.

GitPaean · 2025-08-29T08:12:28Z

Thanks for the feedback.

I would like to understand the current design better before I can suggest more.

With the keyword WELTRAJ/COMPTRAJ,

how to decide how many segments along the wellbore?
how does it work with multiple branches? In multisegment wells, the segment-tree connect orderly towards the well head. When multiple branches happen, there will be two segments points to one segment to show there is intersection of the segments, which is basically where the branches intersect.
how to determine the segment properties and parameters?

We just had a short discussion, some of the main points we have:

WELSEGS offers indeed the flexibility to define segments as you like. We were not trying to bring that functionalilty to wells defined by WELTRAJ/COMPTRAJ. For now we duplicate the functionality that ResinSight has: given a well path, export WELSEGS/COMPSEGS that just split the wellpath into many small segments. So, we only really need the data from WELTRAJ/COMPTRAJ for that, at least for now. I imagine we could extend this by using additional information from WELSEGS to define segments in a more flexible way, given a path defined by WELTRAJ/COMPTRAJ, but that is not our goal at the moment.

As a result, we do not really need WELSEGS in addition to WELTRAJ/COMPTRAJ, at least at the moment, but we do need a way to specify that we want the segments, hence the MSW flag. I did indeed not take into consideration that there could be multiple entries, so the flags could be inconsistent. That will require some extra checks, I have to look into that. I guess that requires tracking the flags over multiple keywords, not sure how to do that...

We are open to alternatives for the MSW flag, but we do think that using WELSEGS for that would currently just make it more complicated for the user. But any ideas are welcome!

verveerpj · 2025-08-29T08:59:43Z

how to decide how many segments along the wellbore?

We are using the approach that ResInsight has for exporting COMPSEG/WELSEGS keywords. Basically we calculate intersections with the cells and add a segment to each cell. Currently that is good enough for us. Next step would be what you mentioned before: be able to specify them (probably by md in WELSEGS?)

how does it work with multiple branches? In multisegment wells, the segment-tree connect orderly towards the well head. When multiple branches happen, there will be two segments points to one segment to show there is intersection of the segments, which is basically where the branches intersect.

We have not implemented multiple branches yet, but the next step is to be able to define multiple branches and generate the correct COMPSET/WELSEG data.

how to determine the segment properties and parameters?

They are currently defaulted. That is also something we also need to work on.

We had some further discussions internally and decided to follow you advice and get rid of the MSW flag. We will use WELSEGS, probably still defaulting a lot. But then we are open to extend it, allowing us to address your points about specifying well segments and properties/parameters.

GitPaean · 2025-11-13T13:17:45Z

Thanks for the update. I do not have capacity at the moment, while will get back to you in a couple of days.

verveerpj · 2025-11-13T13:30:37Z

Thanks for the update. I do not have capacity at the moment, while will get back to you in a couple of days.

No problem, we are not in a hurry!

GitPaean · 2025-11-18T09:53:06Z

Is there a test case somewhere that I can test the PR with? You can share with my email. or if you think it is ready, you can also open a PR with opm-tests.

Either way works for me. Thanks.

verveerpj · 2025-11-18T10:14:14Z

Is there a test case somewhere that I can test the PR with? You can share with my email. or if you think it is ready, you can also open a PR with opm-tests.

Either way works for me. Thanks.

The PR has a test that uses this case: opm-common/tests/SPE1CASE1_WELTRAJ_MSW.DATA

That should run with the the new code and show the multi-segment structure in its output.

GitPaean · 2025-11-25T08:59:18Z

This PR adds support for multi-segment wells to the WELTRAJ/COMPTRAJ keywords. A yes/no option is added to COMPTRAJ and if it is set, the equivalent to WELSEGS/COMPSEGS will be generated from the WELTRAJ and COMPTRAJ keywords. The code is tested against a case using WELSEGS/COMPSEGS keywords generated by ResInsight.

Some considerations:

The added option to COMPTRAJ is called MSW and takes YES and NO values. The default is NO, i.e. not generating segments. Suggestions for an alternative approach or an alternative naming scheme are welcome.

The following WELSEGS options have been defaulted for now:

PRESSURE_COMPONENTS is defaulted to HF-

WELLBORE_VOLUME is defaulted to 1e-5.

ROUGHNESS is defaulted to zero.

The description should be updated so that it reflects the current design. I am reviewing the PR now and will comment during the day.

GitPaean

These are some comments for now, we need to do more refactoring after these. Please let me what you think about the comments.

GitPaean · 2025-11-20T13:58:19Z

tests/parser/ConnectionTests.cpp

 }
+
+
+BOOST_AUTO_TEST_CASE(loadCOMPTRAJTESTSPE1_MSW) {


You can either to have a separate test file for grid-independent wells or you can have this test in MultisegmentWellTests.cpp .

This file looks like focusing on connections mostly.

Moved it to MultisegmentWellTests.cpp

GitPaean · 2025-11-20T13:59:18Z

tests/SPE1CASE1_WELTRAJ_MSW.DATA

+
+-- Note: This is a modified version of SPE1CASE1
+-- This model specifies the well trajectories independent of grid indexes
+-- This model use keywords WELTRAJ and COMPTRAJ instead of WELSPECS and COMPDAT


I think WELSPECS is still necessary.

GitPaean · 2025-11-20T15:05:10Z

opm/input/eclipse/Schedule/MSW/Compsegs.hpp

                    ErrorGuard& errors);

+    std::pair<WellConnections, WellSegments>
+    processCOMPSEGS(std::vector<std::tuple<double, double, std::array<int, 3>>>& segments_md_and_ijk,


When we use capitalized COMPSEGS, we are referring to the keyword COMPSEGS, which is not the case here. Even later we use COMPSEGS keyword for the grid-independent multisegment wells, we can still make it clear this function is used for grid-independent wells. There is no need to share the same function name, which might be better for readability.

I have renamed it.

GitPaean · 2025-11-20T22:22:02Z

opm/input/eclipse/Schedule/Well/WellCompletionKeywordHandlers.cpp

            }
+
+            if (handlerContext.state().wells.get(name).isMultiSegment()) {
+                // Retrieve the well path coordinates:


This part inside the if (handlerContext.state().wells.get(name).isMultiSegment()) { should probably be made a function (a couple of functions inside for better readability) .

This part as whole is basically generate the pair between the WellConnections and WellSegments.

The definition of the function should not be in this file, which is mostly for Completion handling, we should avoid to introduce Segments related headers in this file also.

Splitting it up in a separate function or functions is fine, I will do that. However, I am not clear on how avoid including the segment related headers, since COMPTRAJ is now processing segments which otherwise would be done by WELSEGS and COMPSEGS. We would have to locate the new function(s) in a different file, but I am not sure where.

I have not thought through/much about it, possibly Well.hpp, while maybe it is time to let grid-independent related keywords to have their own .cpp file.

Maybe a new file: GridIndependentKeywordHandlers.cpp?

Yes. Since we only talk about keywords related to Wells (correct me if I am mistaken), we can have Well in the file name.

GridIndependentWellKeywords.cpp? But long, but why not.

It is fine. and we should have the Handlers in the file name so that it is consistent with other Handlers files.

Hm, that would be GridIndependentWellKeywordHandlers.cpp, that seems too long. I will think on a name.

I have made the new file, and refactored the handleCOMPTRAJ code.

GitPaean · 2025-11-25T09:31:34Z

opm/input/eclipse/Schedule/MSW/Compsegs.cpp

    std::pair<WellConnections, WellSegments>
-    processCOMPSEGS(const DeckKeyword& compsegs,
+    processCOMPSEGSfromRecords(const std::vector<Record>& compsegs_vector,
                    const WellConnections& input_connections,


Indentation of the function parameters. And from is probably should be From.

Technically, this function is not tied to the keyword COMPSEGS anymore, we should not have full capitalized COMPSEGS in the function name anymore, while it is generating a pair of WellConnections and WellSegments. You can suggest better names for this or we keep it in a new round refactoring.

processCOMPSEGSfromRecords is just a local helper function, I renamed it to process_compsegs_records and moved it into an anonymous namespace.

GitPaean · 2025-11-25T10:43:08Z

opm/input/eclipse/Schedule/Well/WellCompletionKeywordHandlers.cpp

+                    throw Opm::OpmInputError(msg, handlerContext.keyword.location());
+                }
+                // Generate WELSEGS data:
+                const auto& diameter = record.getItem("DIAMETER").getSIDouble(0);


There is no point to use reference here.

GitPaean · 2025-11-25T10:52:03Z

opm/input/eclipse/Schedule/Well/Well.cpp


+void Well::addWellSegmentsFromLengthsAndDepths(std::vector<std::pair<double, double>>& lengths_and_depths, double diameter)
+{
+    if (this->segments != nullptr) {


With the usage of WELSEGS, should we instead of checking whether this->m_segments->empty()?

And also, with WELSEGS, will the else branch ever be possible?

I honestly do not know. I followed the same structure as the bool Well::handleWELSEGS(const DeckKeyword& keyword) constructor does. Since segments is a shared pointer, that seemed reasonable.

In the current implementation, if (handlerContext.state().wells.get(name).isMultiSegment()) must be true before we enter this function, which means WELSEGS has already been parsed.

And with WELSEGS, we will generate the top segment already.

Whether we allow WELSEGS input after COMPTRAJ is a design question we need to decide.

handleWELSEGS is different. If it is the first time WELSEGS is parsed for the well, this->segments can be nullptr.

But for this function, with current design and implementation, a top segment is already there. We will not encounter empty this->m_segments.

Please let me know id you see it differently.

This makes sense, I will remove the comparison and the else clause.

I think you add something like at the beginning of the function.

if (this->segments == nullptr) { throw OpmInputError{ fmt::format("The WELSEGS keyword must be specified for well {} " "before creating segments through COMPTRAJ keyword.", this->name()), keyword.location() }; }

But then you need to parse in more argument.

That could be, I will check that.

opm/input/eclipse/Schedule/MSW/WelSegsSet.cpp

opm/input/eclipse/Schedule/MSW/WellSegments.hpp

opm/input/eclipse/Schedule/MSW/WellSegments.cpp

GitPaean · 2025-11-25T13:17:11Z

Will trigger copilot to check the typos.

Copilot

Pull request overview

This PR extends the WELTRAJ/COMPTRAJ keywords to support multi-segment wells (MSW) for grid-independent wells. When a well is added to WELSEGS with only the first record (top segment definition) and no segment structure, the system now automatically generates the missing WELSEGS records and COMPSEGS information using the trajectory data from COMPTRAJ and WELTRAJ. Each cell in the well trajectory becomes a segment.

Key changes:

Modified loadCOMPTRAJ to return intersection data needed for MSW generation
Added automatic MSW generation logic in handleCOMPTRAJ when a well has WELSEGS entry
Implemented validation to prevent both COMPSEGS and COMPTRAJ from being used for the same MSW well

Reviewed changes

Copilot reviewed 18 out of 18 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
tests/parser/ConnectionTests.cpp	Added test case for MSW with COMPTRAJ functionality
tests/SPE1CASE1_WELTRAJ_MSW.DATA	New test data file with WELSEGS and COMPTRAJ keywords
opm/input/eclipse/Schedule/Well/WellConnections.hpp	Changed loadCOMPTRAJ signature to return intersection data
opm/input/eclipse/Schedule/Well/WellConnections.cpp	Modified loadCOMPTRAJ to return intersections for MSW processing
opm/input/eclipse/Schedule/Well/WellCompletionKeywordHandlers.cpp	Added MSW generation logic in COMPTRAJ handler
opm/input/eclipse/Schedule/Well/Well.hpp	Added method for generating segments from lengths and depths
opm/input/eclipse/Schedule/Well/Well.cpp	Implemented addWellSegmentsFromLengthsAndDepths method
opm/input/eclipse/Schedule/Schedule.hpp	Added comptraj_wells parameter for consistency checking
opm/input/eclipse/Schedule/Schedule.cpp	Updated consistency checking for COMPSEGS/COMPTRAJ overlap
opm/input/eclipse/Schedule/MSW/WellSegments.hpp	Added constructor and method for MSW from lengths/depths, getLengthDepthType accessor
opm/input/eclipse/Schedule/MSW/WellSegments.cpp	Implemented segment generation and stored length_depth_type
opm/input/eclipse/Schedule/MSW/WelSegsSet.hpp	Added intersection method declaration
opm/input/eclipse/Schedule/MSW/WelSegsSet.cpp	Implemented intersection to check for COMPSEGS/COMPTRAJ overlap
opm/input/eclipse/Schedule/MSW/Compsegs.hpp	Added processCOMPSEGS overload for COMPTRAJ data
opm/input/eclipse/Schedule/MSW/Compsegs.cpp	Refactored and added processCOMPSEGS for segment MD/IJK data
opm/input/eclipse/Schedule/HandlerContext.hpp	Added comptraj_wells tracking support
opm/input/eclipse/Schedule/HandlerContext.cpp	Implemented comptraj_handled method
CMakeLists_files.cmake	Added new test data file to build

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

opm/input/eclipse/Schedule/MSW/WelSegsSet.cpp

opm/input/eclipse/Schedule/Schedule.cpp

tests/parser/ConnectionTests.cpp

verveerpj · 2025-11-26T15:20:58Z

@GitPaean I think I have made adjustments for all your comments, I will wait for your comments on that.

GitPaean · 2025-11-27T08:45:34Z

@GitPaean I think I have made adjustments for all your comments, I will wait for your comments on that.

Thanks. I will look into it today or tomorrow, depending how much I manage today.

GitPaean · 2025-11-28T15:15:32Z

I am reviewing the PR, while it does not look like I can finish before the end of the day. Sorry for the delay, while it will be finished soon also.

verveerpj force-pushed the weltraj-welsegs branch from b142936 to 9522075 Compare March 20, 2025 11:16

bska reviewed May 14, 2025

View reviewed changes

verveerpj force-pushed the weltraj-welsegs branch from 9522075 to 17be30b Compare June 18, 2025 14:24

verveerpj marked this pull request as draft June 19, 2025 08:29

verveerpj changed the title ~~Extend WELTRAJ/COMPTRAJ to support multi-segment wells for grid-independent wells~~ WIP: Extend WELTRAJ/COMPTRAJ to support multi-segment wells for grid-independent wells Jun 19, 2025

verveerpj force-pushed the weltraj-welsegs branch 3 times, most recently from e6ccaa4 to 77428c9 Compare June 19, 2025 14:56

verveerpj force-pushed the weltraj-welsegs branch 3 times, most recently from 14770f1 to 7748652 Compare August 8, 2025 15:11

verveerpj changed the title ~~WIP: Extend WELTRAJ/COMPTRAJ to support multi-segment wells for grid-independent wells~~ Extend WELTRAJ/COMPTRAJ to support multi-segment wells for grid-independent wells Aug 8, 2025

GitPaean added the manual:new-feature This is a new feature and should be described in the manual label Aug 18, 2025

verveerpj force-pushed the weltraj-welsegs branch 3 times, most recently from 98f0b45 to fe9e060 Compare November 14, 2025 09:44

verveerpj force-pushed the weltraj-welsegs branch 2 times, most recently from 65dcd8b to 19bdca2 Compare November 18, 2025 10:12

GitPaean reviewed Nov 25, 2025

View reviewed changes

GitPaean requested a review from Copilot November 25, 2025 13:17

Copilot started reviewing on behalf of GitPaean November 25, 2025 13:17 View session

Copilot finished reviewing on behalf of GitPaean November 25, 2025 13:19

Copilot AI reviewed Nov 25, 2025

View reviewed changes

opm/input/eclipse/Schedule/MSW/WelSegsSet.cpp Outdated Show resolved Hide resolved

opm/input/eclipse/Schedule/Schedule.cpp Outdated Show resolved Hide resolved

tests/parser/ConnectionTests.cpp Outdated Show resolved Hide resolved

verveerpj force-pushed the weltraj-welsegs branch 6 times, most recently from 48d9e2e to b539f17 Compare November 26, 2025 12:02

verveerpj added 2 commits November 26, 2025 16:09

Implement multi-segment well handling in COMPTRAJ

f9a397a

Review fixes

4073a74

verveerpj force-pushed the weltraj-welsegs branch from 3f9d7fe to 3f91810 Compare November 26, 2025 15:10

Add file for grid independent well keywords

37bbd1f

verveerpj force-pushed the weltraj-welsegs branch from 3f91810 to 37bbd1f Compare November 26, 2025 15:14

		processCOMPSEGS(const DeckKeyword& compsegs,
		processCOMPSEGS(const std::vector< Record >& compsegs_vector,

		}


		BOOST_AUTO_TEST_CASE(loadCOMPTRAJTESTSPE1_MSW) {

Extend WELTRAJ/COMPTRAJ to support multi-segment wells for grid-independent wells #4524

Are you sure you want to change the base?

Extend WELTRAJ/COMPTRAJ to support multi-segment wells for grid-independent wells #4524

Uh oh!

Conversation

verveerpj commented Mar 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

arturcastiel commented Mar 17, 2025

Uh oh!

blattms commented Mar 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

blattms commented Mar 20, 2025

Uh oh!

arturcastiel commented May 13, 2025

Uh oh!

bska left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

GitPaean May 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

verveerpj commented Aug 8, 2025

Uh oh!

arturcastiel commented Aug 12, 2025

Uh oh!

arturcastiel commented Aug 18, 2025

Uh oh!

GitPaean commented Aug 18, 2025

Uh oh!

GitPaean commented Aug 21, 2025

Uh oh!

arturcastiel commented Aug 21, 2025

Uh oh!

GitPaean commented Aug 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

verveerpj commented Aug 27, 2025

Uh oh!

GitPaean commented Aug 27, 2025

Uh oh!

verveerpj commented Aug 27, 2025

Uh oh!

gdfldm commented Aug 27, 2025

Uh oh!

GitPaean commented Aug 29, 2025

Uh oh!

verveerpj commented Aug 29, 2025

verveerpj commented Mar 17, 2025 •

edited

Loading

blattms commented Mar 20, 2025 •

edited

Loading

GitPaean May 22, 2025 •

edited

Loading

GitPaean commented Aug 27, 2025 •

edited

Loading