Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Date Format Issue: DD-MMM-YYYY HH:MM:SS #5714

Open
OPMUSER opened this issue Mar 22, 2020 · 2 comments
Open

Date Format Issue: DD-MMM-YYYY HH:MM:SS #5714

OPMUSER opened this issue Mar 22, 2020 · 2 comments
Labels
libecl Issue is relly an libecl issue, that we need to remember to follow up.

Comments

@OPMUSER
Copy link

OPMUSER commented Mar 22, 2020

When history matching a DST the date format used is commonly DD-MMM-YYYY HH:MM:SS; however, OPM ResInsight seems not to take into account the START date, which can also be in this format. So for example.

START                                  -- Generated : Petrel
  27 JUN 2008 '18:00:00' /

And then with production data entered as :

WCONHIST                               -- Generated : Petrel
  OP01 OPEN ORAT 2000.0 1* 0 1 1* 1404.7 2303.64 /
  /

DATES                                  -- Generated : Petrel
  27 JUN 2008 '18:10:00' /
  /

WCONHIST                               -- Generated : Petrel
  OP01 OPEN ORAT 2000.0 1* 0 1 1* 1619.35 2601.06 /
  /

DATES                                  -- Generated : Petrel
  27 JUN 2008 '18:20:00' /
  /

But the plot data gives:

Case: XXXXXXXXXXXXXXXXXXXXXXXXXXXX
Date and time	FOPR.XXXXXX_DST_MATCHING_XXXX
2008-06-27 00:00:00 	            0
2008-06-27 00:10:00 	       2000.0
2008-06-27 00:20:00 	       2000.0
2008-06-27 00:30:00 	       2000.0
2008-06-27 00:40:00 	       2000.0
2008-06-27 00:50:00 	       2000.0
2008-06-27 01:00:00 	       2000.0
2008-06-27 01:10:00 	       2000.0
2008-06-27 01:20:00 	       2000.0
2008-06-27 01:30:00 	       2000.0
2008-06-27 01:40:00 	       2000.0
2008-06-27 01:50:00 	       2000.0
2008-06-27 02:00:00 	       2000.0

Which means the data is miss-aligned with respect to time.

@hhgs
Copy link
Member

hhgs commented Mar 24, 2020

The same problem for RST-data in the 3D view.

@hhgs
Copy link
Member

hhgs commented Mar 24, 2020

DD MM YYYY HH MM SS for start of simulation is reported in the SMSPEC file for summary data:

'STARTDAT' 6 'INTE'
1 1 2020 18 0 0

For Restart data there are multiple alternatives:

  1. The RSSPEC ITIME parameter:
    'ITIME ' 13 'INTE'
    0 1 1 2020 0 1
    1 0 1 1 18 0
    0
  2. RST-file INTEHEAD items Change file extension to RSP #65, 66, 67, 207, 208, 411
  IDAY IMON IYEAR IHOURZ IMINTS ISECND
idx 65 66 67 207 208 411
rst1 1 1 2020 18 0 0
rst2 1 1 2020 18 10 0
rst3 1 1 2020 18 20 0
  1. RST-file DOUBHEAD items Support compilation with Qt 4.6 #1 and 161 or item Print the help message if we encounter a positional command-line parameter #162 (days since year 0 = yyyy*365.25)
  Time Time Time
  since Start-of-sim Start-of-sim of current simulation
  days days days
idx 1 161 162
rst1 0.00000000000000D+00 0.73780575000000D+06 0.73780575000000D+06
rst2 0.69444444444444D-02 0.73780575000000D+06 0.73780575694444D+06
rst3 0.13888888888889D-01 0.73780575000000D+06 0.73780576388889D+06
rst1 00:00:00 01.01.2020 18:00:00 01.01.2020 18:00:00
rst2 00:10:00 01.01.2020 18:00:00 01.01.2020 18:10:00
rst3 00:20:00 01.01.2020 18:00:00 01.01.2020 18:20:00

@magnesj magnesj added the libecl Issue is relly an libecl issue, that we need to remember to follow up. label Mar 25, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
libecl Issue is relly an libecl issue, that we need to remember to follow up.
Projects
None yet
Development

No branches or pull requests

3 participants