Inconsistent RESTART results

[flammmes]

Edit: I tried to replicate the issue on my local machine where flow version is 3-4 months outdated but the restart process worked as intended. For reference the mismatch appears on an aws machine where flow was installed from source a week or so ago. So I am wondering whether or not the issue is due to the new activity models introduced in the last months although I didn't use any of them. Did anything significant change in the CO2STORE keyword that could explain this?

Hello, I have been trying to create a closed loop reservoir management script, utilizing the RESTART keyword. The concept is that the simulation restarts from the previous RESTART step, runs for the current one and saves the data into a new timestep. However I noticed an inconsistency between the results that stem from this process and the ones from simply running the simulation for all timesteps.

Specifically, in the .DATA file generated in the x timestep, if i replace the solution keyword from RESTART to the EQUIL one and run all the steps I get very inconsistent results and I think that the biggest culprit is the oil production rate (water actually since I use CO2STORE).

In the image below, the x mark represents the saved results from the RESTART file for this timestep and the plots represent the run that disregards the RESTART keyword and simply runs it from scratch. I also noticed that since the earliest timesteps, the production rate was around 20,000 stb/day instead of the 50,000 that the EQUIL .DATA file was producing. If you want me to send more files that show how i generate the .DATA files please let me know.

[atgeirr]

Specifically, in the .DATA file generated in the x timestep, if i replace the solution keyword from RESTART to the EQUIL one and run all the steps I get very inconsistent results and I think that the biggest culprit is the oil production rate (water actually since I use CO2STORE).

I think I need a bit further explanation here: did the initial deck have EQUIL? Then you simulate a single timestep at a time, creating a new deck for each of them, and in these deks you replace EQUIL with explicit pressure and saturation fields taken from the restart files just created. Is that correct?

[flammmes]

Yes, this is exactly what I am doing.

To give a bit more context:

Firstly I generate two decks that are the same. One of them has an EQUIL keyword and the other has a RESTART keyword but is never actually being run, it is simply used as a template to be modified.

The EQUIL inital deck has this solution

SOLUTION
EQUIL
 10000 5000 12000 0 0 0 1 1 0 /
RTEMPVD
 0 200 12000 200 /
RSVD
 0 0 10000 0 /

while the restart one has something like this

RESTART
'0/TRUE_DECK0' 1 1* 1*/

the SCHEDULE section has these keywords in both files

SCHEDULE
SKIPREST
RPTSCHED
	'PRES' 'SGAS' 'SOIL' /
RPTRST
 'BASIC=1' 'TEMP' /

and there is an initial one day timestep with well controls simply for stability, since by not adding anything the restart crashes.

So after running the first timestep (the EQUIL one) and a folder is generated with the outputs, I generate a new deck and replace the SOLUTION from the template to this

SOLUTION
RESTART
 '0/TRUE_DECK2_0' 1 /

I add a new WCONINJE, WCONPROD, TSTEP and run. And so on. I have created a function that handles this process. I also have other functions that are responsible for running the simulation and for incrementing the step and collecting observations from the outputs etc.

     def modify_deck(self, action, step):
        target_line_number = 162358
        new_content = f"""
        '{step-1}/TRUE_DECK{self.env_id}_{step-1}' {step} 1* 1*/ '
        """

        # Split the string into lines
        lines = str(self.deck).split('\n')
        lines[target_line_number] = new_content

        modified_str = '\n'.join(lines)
        self.deck = self.parser.parse_string(modified_str)
        #inj_rate1,inj_rate2,inj_rate3 = action[3:6]
        prod_rate1, prod_rate2, prod_rate3 = action[0:3]
        gas_inj = 170

        gconinje_string = f'''
        GCONINJE
                'FIELD' 'GAS' 'RATE' {gas_inj}E3 3* 'NO' /
            'Inj' 'GAS' 'RATE' {gas_inj}E3 3* 'NO' /
                 /

            WCONINJE
            'I1' 'GAS' 'OPEN' 'GRUP' 100000 1* 9000 /
            'I2' 'GAS' 'OPEN' 'GRUP' 100000 1* 9000 /
            'I3' 'GAS' 'OPEN' 'GRUP' 100000 1* 9000 /
            /
                 '''
        self.deck = self.parser.parse_string(str(self.deck)+gconinje_string)

        wconprod_string = f"""
        WCONPROD
        'P1' 'OPEN' 'ORAT' {prod_rate1}E3 1* 6E3 2* 3000 /
        'P2' 'OPEN' 'ORAT' {prod_rate2}E3 1* 6E3 2* 3000 /
        'P3' 'OPEN' 'ORAT' {prod_rate3}E3 1* 6E3 2* 3000 /

        /"""

        tstep_string = """
        TSTEP\n
        180\n
        /
        """
        self.deck = self.parser.parse_string(str(self.deck)+wconprod_string+tstep_string)
        with open(f'{self.env_id}/TRUE_DECK{self.env_id}_{step}.DATA', 'w') as file:
            file.write(str(self.deck))

On my local machine with flow built from source 3-4 months ago, this process behaves as expected. Therefore, if i take any .DATA file generated and replace the SOLUTION from RESTART to the same EQUIL of the first .DATA, results are indeed consistent.

However, I run the same code on an aws machine with flow built a week or so ago and results present this inconsistency shown in the picture above. The inconsistency is the same for all timesteps. Production rate is much smaller in the restarted case compared to changing it to an EQUIL one.

[flammmes]

To further verify whether or not these inconsistencies were actually due to the aws environment or to the newest version of flow, I built flow from source in a completely new wsl vm. The inconsistencies appear again.
As you can see below, in the older flow version, the production rates from the restart steps 2,3,4,5 completely match the one from an EQUIL run so closely that they aren't even visible

On the other hand, on the brand new flow version built from source today, production rates from restart steps do not match at all the EQUIL run

I think that this verifies that there is a bug that didn't exist prior to the newest version.