OPM / opm-parser

http://www.opm-project.org
11 stars 44 forks source link

respect the fact that non-SI temperature may be offset from zero #1205

Closed andlaus closed 6 years ago

andlaus commented 6 years ago

this is another attempt for fixing the "measure" temperature conversion stuff after #1203 without causing a trainwreck.

I did not find any substantial mistakes in #1203, so maybe some downstream code tries to work around the missing offset and thus creates a wrong result (then the downstream code needs to be fixed), maybe the reference data needs to be updated, or both. Anyway, temperature conversion is now much more thoroughly tested...

andlaus commented 6 years ago

jenkins build this with downstreams please

joakim-hove commented 6 years ago

so maybe some downstream code tries to work around the missing offset and thus creates a wrong result

That is my hunch.

joakim-hove commented 6 years ago

jenkins build this update_data please

joakim-hove commented 6 years ago

OK - this looks fine; and modulo update_data I am nearly ready to merge it. But to be honest I fear there might be hardcoded 273.xx around - maybe in opm-output? So - would appreciate a search for such obscenities first.

andlaus commented 6 years ago

okay, I've updated the PR for the first review comment and looked at the test failures in opm-simulators: all are caused by legacy simulators. This is reasonable because without OPM/opm-simulators#1391 (?) temperature is not written to ECL restart files by the non-legacy simulators. @totto82: can you please test that temperature output says correct with OPM/opm-simulators#1391 if the present PR gets merged.

the new temperatures written by the legacy simulators is both more correct than the current master but it is still wrong: it is more correct because with the present PR, °F instead of °R are used but they are wrong because the legacy simulators seem to hardcode a reservoir temperature of 20 °C instead of 60 °F (which is 15.666°C).

andlaus commented 6 years ago

jenkins build this with downstreams update_data please

atgeirr commented 6 years ago

hardcode a reservoir temperature of 20 °C instead of 60 °F

Is 60 degrees F the "eclipse default"? If so we should just change it and be done.

andlaus commented 6 years ago

Is 60 degrees F the "eclipse default"? If so we should just change it and be done.

it seems to be the E100 default, E300 defaults to 100°C as far as I can tell. (IMO the E300 default is much more sensible.)

On the OPM side, this havoc is basically caused by the fact that the legacy simulators do not use the fluid system to determine the reservoir temperature. Anyway, the legacy simulators do not really use the temperature, so the outputted values are basically "eye candy" and thus it's probably better not to change that code.

jenkins4opm commented 6 years ago

Existing PR https://github.com/OPM/opm-data/pull/303 was updated

atgeirr commented 6 years ago

Please don't merge this until @totto82's big output-PR is merged (expected tomorrow morning).

andlaus commented 6 years ago

the output PRs have been merged. let's see which reference solutions are affected.

andlaus commented 6 years ago

jenkins build this with downstreams update_data please

jenkins4opm commented 6 years ago

Existing PR https://github.com/OPM/opm-data/pull/303 was updated

andlaus commented 6 years ago

I looked at all the jenkins failures, and all of them are caused by the TEMP field going from absolute temperature (i.e., °R or K) to relative ones (°F or °C). I suppose that this can be merged if jenkins succeeds with the new reference results?

andlaus commented 6 years ago

jenkins build this with downstreams opm-data=303 please

atgeirr commented 6 years ago

I looked at all the jenkins failures, and all of them are caused by the TEMP field going from absolute temperature (i.e., °R or K) to relative ones (°F or °C). I suppose that this can be merged if jenkins succeeds with the new reference results?

So this is nice bugfix! Sounds good to me. I guess it also means that our fears of code further downstream manually applying an offset were false?

andlaus commented 6 years ago

arg I forgot to force push the fix from review! re-jenkins please!

andlaus commented 6 years ago

jenkins build this with downstreams opm-data=303 please

andlaus commented 6 years ago

I guess it also means that our fears of code further downstream manually applying an offset were false?

it looks like it. maybe there was just some confusion of whether the "first" or the "second" values are the current or the reference results?

joakim-hove commented 6 years ago

jenkins build this opm-data=303 please

andlaus commented 6 years ago

alright, Jenkins is green. @joakim-hove: mind merging?

joakim-hove commented 6 years ago

mind merging?

No - I do not mind merging!