search

OPM / opm-common

Common components for OPM, in particular build system (cmake).
http://www.opm-project.org
GNU General Public License v3.0
33 stars 111 forks source link

Rate is output in sm3/s? #1334

Open goncalvesmachadoc opened 4 years ago

goncalvesmachadoc commented 4 years ago

We were comparing the simulations results from April's release to the newest release. The injection rates output by the old version looks like what we would expect, with rates up to 50m3/day or so as described in the schedule input. The rates from the new version were much lower. We checked, they seem to be actually exported in m3/sec to the summary file.

alfbr commented 4 years ago

I have been comparing a number of simulations with master the last couple of weeks, and not noticed that difference. Are you able to narrow down what causes it, is it present on all models you test?

bska commented 4 years ago

The injection rates output by the old version looks like what we would expect, with rates up to 50m3/day or so as described in the schedule input.

Are you simulating a lab setup? I'm just asking because 50sm³/day is a fairly low rate for a field case.

goncalvesmachadoc commented 4 years ago

We are simulating the Egg model with metric system (those are common rates for this model). We will go ahead and test other models using metric system now.

bska commented 4 years ago

We are simulating the Egg model with metric system (those are common rates for this model)

I see.

As a quick test, I created a synthetic model with rates in the same order of magnitude and ran it in current master—i.e., not the 2019.10 release. Using the summary program to analyse the injection rates (water injectors constrained by surface water rate) I then got

$ summary EGG_STANDIN TIME WWIR:INJECT{1..4}
--          TIME    WWIR:INJECT1    WWIR:INJECT2    WWIR:INJECT3    WWIR:INJECT4
        1.000000       79.500000       79.500000       79.500000       79.500000
        4.000000       79.500000       79.500000       79.500000       79.500000
       13.000000       79.500000       79.500000       79.500000       79.500000
       30.000000       79.500000       79.500000       79.500000       79.500000
       60.000000       79.500000       79.500000       79.500000       79.500000
       90.000000       79.500000       79.500000       79.500000       79.500000
      120.000000       79.500000       79.500000       79.500000       79.500000
      150.000000       79.500000       79.500000       79.500000       79.500000
      180.000000       79.500000       79.500000       79.500000       79.500000
      210.000000       79.500000       79.500000       79.500000       79.500000
      240.000000       79.500000       79.500000       79.500000       79.500000
      270.000000       79.500000       79.500000       79.500000       79.500000
      300.000000       79.500000       79.500000       79.500000       79.500000
      330.000000       79.500000       79.500000       79.500000       79.500000
      360.000000       79.500000       79.500000       79.500000       79.500000

Of course, this could just be a systematic error in the I/O code that cancels out a unit conversion error, but it does at least suggest that we're not completely off.

bska commented 4 years ago

@goncalvesmachadoc : Are you still seeing the low rate symptoms?

goncalvesmachadoc commented 4 years ago

Yes, in selected cases the rates are outputted in m3/s. We are trying to figure out which feautre is causing it.

bska commented 4 years ago

Are you still seeing the low rate symptoms?

Yes, in selected cases the rates are outputted in m3/s.

Very well, thanks for the update. Do please keep me informed of any progress you make and feel free to send me an e-mail if you have further questions. I'll assist in any way I can.