different "meaning" of report_step in writeTimeStep is not catered for

[blattms]

I am reporting this here but the problem is also in EclipseWriter::writeTimeStep.

The problem is that report_step is used to get the Well definitions from the Parser, but this only works for non-adaptive time stepping. During adaptive time stepping writeTimeStep might be called like in this gdb session (report_step=0, 1, 2, 1):

================ Starting main simulation loop ===============


Breakpoint 1, Opm::EclipseWriter::writeTimeStep (this=0x244e890, 
    report_step=0, secs_elapsed=0, cells=..., wells=..., isSubstep=false)
    at /home/mblatt/src/dune/opm/opm-output/opm/output/eclipse/EclipseWriter.cpp:619
619         if( !this->impl->output_enabled )
(gdb) c
Continuing.

Time step    0 at day 0/4870, date = 01-Jan-2000

Adaptive time step (0), stepsize 0.66 days.
well iterations = 0, non-linear iterations = 1, total linear iterations = 1

Breakpoint 1, Opm::EclipseWriter::writeTimeStep (this=0x244e890, 
    report_step=1, secs_elapsed=57024, cells=..., wells=..., isSubstep=true)
    at /home/mblatt/src/dune/opm/opm-output/opm/output/eclipse/EclipseWriter.cpp:619
(gdb) c
Continuing.

Time step    0 at day 0/4870, date = 01-Jan-2000

Adaptive time step (0), stepsize 0.66 days.
well iterations = 0, non-linear iterations = 1, total linear iterations = 1

Breakpoint 1, Opm::EclipseWriter::writeTimeStep (this=0x244e890, 
    report_step=1, secs_elapsed=57024, cells=..., wells=..., isSubstep=true)
    at /home/mblatt/src/dune/opm/opm-output/opm/output/eclipse/EclipseWriter.cpp:619
619         if( !this->impl->output_enabled )
(gdb) p isSubstep 
$3 = true
(gdb) p report_step 
$4 = 1
(gdb) c
Continuing.
Adaptive time step (1), stepsize 1.34 days.
well iterations = 0, non-linear iterations = 2, total linear iterations = 6

Breakpoint 1, Opm::EclipseWriter::writeTimeStep (this=0x244e890, 
    report_step=2, secs_elapsed=172800, cells=..., wells=..., isSubstep=true)
    at /home/mblatt/src/dune/opm/opm-output/opm/output/eclipse/EclipseWriter.cpp:619
619         if( !this->impl->output_enabled )
(gdb) c
Continuing.

Breakpoint 1, Opm::EclipseWriter::writeTimeStep (this=0x244e890, 
    report_step=1, secs_elapsed=172800, cells=..., wells=..., isSubstep=false)
    at /home/mblatt/src/dune/opm/opm-output/opm/output/eclipse/EclipseWriter.cpp:619
619         if( !this->impl->output_enabled )
(gdb) 

What I am wondering is what this means for the call this->impl->rft.writeTimeStep if report_step is actually the number of the adaptive timestep.

The problem is there for the parallel output where the report_step is used to create the WellState from the parser.

[blattms]

BTW: As restart information is not written for substeps at least the restart information is not affected. In the example the intermediate substeps 1,2 will not be written.

[blattms]

Let's continue the debugging session a little more:

(gdb) c
Continuing.

Time step    1 at day 2/4870, date = 03-Jan-2000

Adaptive time step (0), stepsize 1 days.
well iterations = 0, non-linear iterations = 1, total linear iterations = 1

Breakpoint 1, Opm::EclipseWriter::writeTimeStep (this=0x244e890, 
    report_step=1, secs_elapsed=259200, cells=..., wells=..., isSubstep=true)
    at /home/mblatt/src/dune/opm/opm-output/opm/output/eclipse/EclipseWriter.cpp:619
619         if( !this->impl->output_enabled )
(gdb) c
Continuing.

Breakpoint 1, Opm::EclipseWriter::writeTimeStep (this=0x244e890, 
    report_step=2, secs_elapsed=259200, cells=..., wells=..., isSubstep=false)
    at /home/mblatt/src/dune/opm/opm-output/opm/output/eclipse/EclipseWriter.cpp:619
619         if( !this->impl->output_enabled )
(gdb) c
Continuing.

Time step    2 at day 3/4870, date = 04-Jan-2000

Adaptive time step (0), stepsize 3 days.
well iterations = 0, non-linear iterations = 1, total linear iterations = 14

Breakpoint 1, Opm::EclipseWriter::writeTimeStep (this=0x244e890, 
    report_step=1, secs_elapsed=518400, cells=..., wells=..., isSubstep=true)
    at /home/mblatt/src/dune/opm/opm-output/opm/output/eclipse/EclipseWriter.cpp:619
619         if( !this->impl->output_enabled )
(gdb) 

[jokva]

opm-output gets its report step from the simulator and it's up to the simulator code to give the correct step. Obviously this surfaces in opm-output, but the root is likely in the simulator.

[jokva]

Also, currently output expects data to be added in a linear fashion, i.e. write( 1 ) must come before write( 2 ) ... write( n ), n must be strictly increasing. We might relax this restriction later but that's a lot of work.

[blattms]

Ergo, this is a real bug.

May I ask what the report step is used for in rft.writeTimeStep?

[blattms]

@dr-robertk So the real questions are: Where is the report_step manipulated in the adaptive time stepper ? I have troubles to find this.

[blattms]

@jokva report_step is also passed to this->impl->summary.add_timestep

[jokva]

@blattms probably is, yeah. Good catch.

The report_step is what entry, as requested by the deck, to write when invoked. It should coincide with the DATES and TSTEP keywords in the Deck. Internally it is given to ert (which does the actual writing) and also used to look up certain values in the Deck.

[blattms]

Just to be sure that I comprehend how this output writing is supposed to work:

Let us say we simulate from report step 0 (0 days) over report step 1 (3 days) up to report step 2 (5 days), the adaptive time stepper chooses a constant step size of 1 day, and GEO_MODIFIER at report step 1, then the following is written

• report step 0, day 0 summary/timestep and restart with wellstate of report step 0
• report step 0, day 1 just the summary/timestep with wellstate of report step 0
• report step 0, day 2 just the summary/timestep with wellstate of report step 0
• report step 1, day 3 summary/timestep and restart with wellstate of report step 1 and the geo modification applied
• report step 1, day 4 just the summary/timestep with wellstate of report step 1
• report step 2, day 5 summary/timestep and restart with wellstate of report step 2

Would it matter to output/ert if we would use the wellstate that was used in the computation, e.g on day 3 the wellstate as of report step 0?

[joakim-hove]

Sorry:

Output in itself is complicated an very much in flux. Getting it to work on MPI is unrealistic while the rate of change is so high.

[jokva]

Would it matter to ouput/ert if we would use the wellstate that was used in the computation, e.g on day 3 the wellstate as of report step 0?

Yes. I haven't thoroughly tested this particular case, but it's the last write of report step N that ends up showing up in report step N, and it does not accumulate within one time step. The underlying assumption is that data given to output from the simulator is complete and correct.

[blattms]

Ooops, seems like I broke the report step number used when writing in my local version. It should to the writing with acending report step in master, Thanks for the help and sorry for the noise.

@jokva Thanks for the answer. That might help. Closing as invalid

[jokva]

Splendid, hope it works out. I'd like to re-emphasise that output has no concept of adaptive time stepping and probably never wants to care. It's a rather stupid construction really, and assumes that whoever calls the shots have these things under control.