WPOLYMER not working after start of time stepping

[EdmundStephens]

[v2024.04] The attached example pair shows a polymer model run. Using WPOLYMER to assign polymer injection to a well after start of time stepping does not work, in fact it seems to disable the polymer mode altogether. The workaround is to use separate injectors for water and polymer water, this is possible in simple test cases but not handy to arrange in complex cases.

• R1_SS_poly1f ... uses 2 injectors I1 (water) and I2 (water with polymer) where these are switched after 2 years
• R1_SS_poly1f1 ... uses 1 injector and WPOLYMER assignment at 2 years ... model does not work

I had the chance to run the R1_SS_poly1f1 in tNavigator which resulting in the correct polymer injection.

bug_WPOLYMER.zip

[GitPaean]

Hi,

Thanks for reaching to us.

There are a few keywords that we do not support,

After commenting out the few lines, it looks running fine with both the 1f and 1f1 cases.

The results of the 1f1 case can be seen from the following file.
summary.pdf

Can you give more details about your finding, regarding that polymer mode is disabled?

And also, which version of OPM-flow are using?

Thanks.

Best,
Kai

[EdmundStephens]

I'm using version 2024.04 and still see this bug (after removing OLDTRAN, RSCONST and GCONTOL).

Runs attached with all includes, grid and summary output data. I simplified the models to help home in on this issue with three cases:

• Ref1 is a reference case with simple water flood
• Poly1 uses 1 injector well and changes the polymer concentration via WPOLYMER at t=2 years
• Poly2 uses 2 injectors with I1=water and I2=water+polymer and switches I2 on at t=2 years

bug_polymer.zip

See images below. There are two issues:

1. In case Poly1, WPOLYMER is not working. The case should show the polymer flood but does not; in fact it gives the same result as well as run performance as the Ref1 which has no polymer ... in the output all MB(P) and CNV(P) are exactly zero. Poly2 uses two wells with pre-set polymer, then switches these via WELOPEN ... worth noting that this is a successful workaround, albeit could be hard to arrange in more general models, but it would be better to identify and resolve the problem.
2. In case Poly2, the result is correct but run times are on long side, the attached zip includes the settings used via --parameter=file=default.param. In the second plot below the polymer run has run time ~ 880 seconds compared to the water flood ~9 seconds. This differential (x 100) is much larger than it should be: the solver is repeatedly failing and reducing time step size, especially after 2026 when there is polymer flowing into the producer well (presumable sensitivity between well performance and fluid inflow mobilities). I have tried at length to find parameter choices that make a difference but without success ... is there any particular solver parameters or other settings that help ?

[GitPaean]

Thanks. Please look at my running with the case 1f1, https://github.com/user-attachments/files/17461640/summary.pdf

It looks like 1f1 shows desirable results, (WOPR:P1 from the summary.pdf) (1f1 is the case you claim not working. )

I recompiled a 2024.4 release version,

it looks like POLY1F case that you provided is also working, the following is a unfinished running (green line is my running)

I do not work with installed release version, so I am not sure what happened with your running.

What is the easiest way to test release build? @akva2

Regarding the long running time, it is mostly due to convergence issue, which needs more close investigation and I do not have capacity for it, sorry about that. You can try to play with the tolerances to say if you can improve the running performance.

Depending on your computer, you can try run the cases with multiple processes to accelerate the running. For example you can run OPM-flow with 4 or 8 processes,

mpirun -np 4 flow ...

[EdmundStephens]

Kai, Thank you so much, this is a curious one it might even be some incompatibility in the release versions of some of the common libraries, so that you don't see it in your development version. Weird. I am running on Ubuntu on Windows 10 via WSL 2. I get the same issue on my laptop (MS Surface Pro 7, Intel i7) and workstation (custom build with Ryzen threadripper 32 core), fully updated on both Windows and Ubuntu sides, although still showing some very minor differences between the platforms.

Laptop: Ubuntu 22.04.5 LTS (GNU/Linux 5.10.16.3-microsoft-standard-WSL2 x86_64)
Workstation: Ubuntu 22.04.5 LTS (GNU/Linux 5.10.102.1-microsoft-standard-WSL2 x86_64)

[GitPaean]

although still showing some very minor differences between the platforms.

So on both platforms, the polymer mode does not work for POLY1F case for you. Then we need to check the release build.

I build a release for 2024.04 locally, the polymer mode works for POLY1F.

[EdmundStephens]

Could this be something to do with Octave, or a common library that is incompatible between Flow and ResInsight?

I see this in the apt upgrade output:

ed@DESKTOP-8VC26F1:~$ sudo apt upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
You might want to run 'apt --fix-broken install' to correct these.
The following packages have unmet dependencies:
 octave-resinsight : Depends: resinsight (= 2024.09.1-1~jammy) but 2023.01.0-1~focal is installed
E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution).

Then

ed@DESKTOP-8VC26F1:~$ sudo apt --fix-broken install
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Correcting dependencies... Done
The following packages were automatically installed and are no longer required:
  libboost-date-time1.71.0 libboost-filesystem1.71.0 libffi7 libhdf5-103 libhdf5-cpp-103 libhdf5-cpp-103-1 libhdf5-fortran-102
  libhdf5-hl-100 libhdf5-hl-cpp-100 libhdf5-hl-fortran-100 libhdf5-openmpi-103 libhdf5-openmpi-fortran-102 libhdf5-openmpi-hl-100
  libhdf5-openmpi-hl-fortran-100 libmpdec2 libptscotch-6.0 libpython3.8 libpython3.8-minimal libpython3.8-stdlib libscotch-6.0
  libssl1.1 libtrilinos-zoltan12
Use 'sudo apt autoremove' to remove them.
The following additional packages will be installed:
  resinsight
The following packages will be upgraded:
  resinsight
1 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
13 not fully installed or removed.
Need to get 0 B/26.0 MB of archives.
After this operation, 47.5 MB of additional disk space will be used.
Do you want to continue? [Y/n] Y
(Reading database ... 152208 files and directories currently installed.)
Preparing to unpack .../resinsight_2024.09.1-1~jammy_amd64.deb ...
Unpacking resinsight (2024.09.1-1~jammy) over (2023.01.0-1~focal) ...
dpkg: error processing archive /var/cache/apt/archives/resinsight_2024.09.1-1~jammy_amd64.deb (--unpack):
 trying to overwrite '/usr/lib/x86_64-linux-gnu/libopenvds-e1541338.so.3.2.7', which is also in package octave-resinsight 2024.09.1-1~jammy
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
Errors were encountered while processing:
 /var/cache/apt/archives/resinsight_2024.09.1-1~jammy_amd64.deb
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)

Not seen this before, possible a new problem.

[akva2]

yeah, this is a new problem. i'll have to fix up the packaging, for some reason a shared object has ended up in both of the packages. for now, unless you need it, remove the octave-resinsight package.

[EdmundStephens]

Just FYI, I did sudo apt autoremove and full-upgrade on both machines, then removed octave-resinsight. Unfortunately the problem persists: Poly1f fails, Poly2f runs but slowly.

Grateful for your attention, with any luck this might expose and help you resolve some sort of nasty internal issue. On the solver side I have noticed for example that the solver is slow whenever there is a 4th component including thermal runs.

[GitPaean]

although still showing some very minor differences between the platforms.

So on both platforms, the polymer mode does not work for POLY1F case for you. Then we need to check the release build.

I build a release for 2024.04 locally, the polymer mode works for POLY1F.

One small update. I tested in build release with the following command,

sudo apt-add-repository ppa:opm/ppa
sudo apt-get update
sudo apt-get install libopm-simulators-bin

kaib@kai-ws:~$ which flow
/usr/bin/flow
kaib@kai-ws:~$ flow --version
flow 2024.04

with this build, the polymer mode works with POLY1F.

It is out of my knowledge on what happened with your installation.

[EdmundStephens]

Well I tried these and no luck so I'm not sure what that leave you if you cannot reproduce the issue. Seems very odd to me. Can you push this issue around your developer base see if anyone has ideas. Thing is the student this comes from sees the same thing and has a completely fresh installation of Ubuntu made last week for this project, so I dont think a complete reinstall will necessarily be an answer.

ed@DESKTOP-8VC26F1:~$ sudo apt-add-repository ppa:opm/ppa
Repository: 'deb https://ppa.launchpadcontent.net/opm/ppa/ubuntu/ jammy main'
Description:
The Open Porous Media (OPM) initiative provides a set of open-source tools centered around the simulation of flow and transport of fluids in porous media. The goal of the initiative is to establish a sustainable environment for the development of an efficient and well-maintained software suite.
More info: https://launchpad.net/~opm/+archive/ubuntu/ppa
Adding repository.
Press [ENTER] to continue or Ctrl-c to cancel.
Found existing deb entry in /etc/apt/sources.list.d/opm-ubuntu-ppa-jammy.list
Adding deb entry to /etc/apt/sources.list.d/opm-ubuntu-ppa-jammy.list
Found existing deb-src entry in /etc/apt/sources.list.d/opm-ubuntu-ppa-jammy.list
Adding disabled deb-src entry to /etc/apt/sources.list.d/opm-ubuntu-ppa-jammy.list
Adding key to /etc/apt/trusted.gpg.d/opm-ubuntu-ppa.gpg with fingerprint 91121C48A10BAC661586B42A50BDC27473618B59
Hit:1 https://ppa.launchpadcontent.net/opm/ppa/ubuntu jammy InRelease
Hit:2 http://archive.ubuntu.com/ubuntu jammy InRelease
Hit:3 http://security.ubuntu.com/ubuntu jammy-security InRelease
Hit:4 http://archive.ubuntu.com/ubuntu jammy-updates InRelease
Hit:5 http://archive.ubuntu.com/ubuntu jammy-backports InRelease
Reading package lists... Done
ed@DESKTOP-8VC26F1:~$ sudo apt-get update
Hit:1 https://ppa.launchpadcontent.net/opm/ppa/ubuntu jammy InRelease
Hit:2 http://security.ubuntu.com/ubuntu jammy-security InRelease
Hit:3 http://archive.ubuntu.com/ubuntu jammy InRelease
Hit:4 http://archive.ubuntu.com/ubuntu jammy-updates InRelease
Hit:5 http://archive.ubuntu.com/ubuntu jammy-backports InRelease
Reading package lists... Done
ed@DESKTOP-8VC26F1:~$ sudo apt-get install libopm-simulators-bin
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
libopm-simulators-bin is already the newest version (2024.04-1~jammy).
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
ed@DESKTOP-8VC26F1:~$ which flow
/usr/bin/flow
ed@DESKTOP-8VC26F1:~$ flow --version
flow 2024.04
ed@DESKTOP-8VC26F1:~$

[GitPaean]

The only difference that I can see is that you are using Ubuntu 22.04 and I am using Ubuntu 24.04. I am not an expert in packaging, not sure whether it matters.

[GitPaean]

another update, I use virtual machine of Ubuntu 22.04 and installed a OPM-flow 24.04, still I could not reproduce your issue.

there is something really hard to answer from my end.

[EdmundStephens]

I get a message in the login phase

Windows Subsystem for Linux is now available in the Microsoft Store!
You can upgrade by running 'wsl.exe --update' or by visiting https://aka.ms/wslstorepage
Installing WSL from the Microsoft Store will give you the latest WSL updates, faster.
For more information please visit https://aka.ms/wslstoreinfo

which ties to this discussion, so I am mid process of updating and will get back to you shortly

First on Windows command prompt (Admin)

wsl.exe --update

Then in the Ubuntu shell
$ sudo apt remove snapd
$ sudo do-release-upgrade -d

... ongoing (its a rather long process)

[EdmundStephens]

Long install process followed by restarting WSL and Ubuntu

wsl.exe --shutdown

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 24.04.1 LTS
Release: 24.04
Codename: noble

and reinstall OPM

sudo apt-add-repository ppa:opm/ppa
sudo apt-get update
apt-cache search opm-simulators
sudo apt-get install mpi-default-bin
sudo apt-get install libopm-simulators-bin

... and ... drumroll ... no change in the result for poly1f run.

Sorry ...

[GitPaean]

I reproduced your problem now.

For your case, when I ran with 3 or more processes, poly1f does not show correct behavoir.

When I ran with 1 or 2 processes, poly1f shows desired behavoir.

Both the development branch and release branch have the same problem.

So there is a bug for the parallel running related to your polymer case.

For now I can only suggest you run the cases with 1 or 2 processes. I am not sure whether we can prioritize the fix because there is not much polymer development at the moment. But we will keep it in mind.

Please let us know whether you see desired results with 1 or 2 processes?

[GitPaean]

Checking the output, it also confirms that when the polymer mode not working, there is indeed no polymer existing in the field.

[GitPaean]

It is related to the parallel distribution of the wells after parsing the DATA file. We will see whether we can fix it easily. You will hear from us if there is any update.

[EdmundStephens]

Great - that is some impressive detective work there. For the time being the workaround (that you can circulate to interested users) is to have duplicate wells as the polymer injector and switch these via WELOPEN.

Would you like me to submit the more general polymer solver issue as a separate issue ? To me it seems related to other circumstances where the 4th component is used, including a lot of my Geothermal work (black oil TEMP model) and CCS in black oil with the Solvent method (per Matthias & Oldenberg).

[GitPaean]

Would you like me to submit the more general polymer solver issue as a separate issue ? To me it seems related to other circumstances where the 4th component is used, including a lot of my Geothermal work (black oil TEMP model) and CCS in black oil with the Solvent method (per Matthias & Oldenberg).

sure, that will be great!

I am in progress in debugging the current case at the moment.

[EdmundStephens]

Ok will do. I think I will check the solver on the Thermal and CCS cases, if these have a common pattern I can whizz up a set of simplified test decks to you guys to target in debugging.

[GitPaean]

Ok will do. I think I will check the solver on the Thermal and CCS cases, if these have a common pattern I can whizz up a set of simplified test decks to you guys to target in debugging.

much appreciated!

[GitPaean]

@EdmundStephens thanks for reporting this issue. With the help of some colleague, we figured out the issue and proposed a fix OPM/opm-common#4277 .

We are in the final stage of publishing new release of 2024.10. Not sure whether the fix can enter this release. It if did not, the fix can only be available for the simulator compiled from the source code until the later release in 2025.4.

Will keep you updated with the issue.

[GitPaean]

My colleague just confirmed that the fix will go in the 2024.10 release. So within about a week, you can have a new version of OPM-flow will not have the same issue (polymer not working in parallel running. )