My Project
RSTConfig.hpp
1/*
2 Copyright 2021 Equinor ASA.
3
4 This file is part of the Open Porous Media project (OPM).
5
6 OPM is free software: you can redistribute it and/or modify
7 it under the terms of the GNU General Public License as published by
8 the Free Software Foundation, either version 3 of the License, or
9 (at your option) any later version.
10
11 OPM is distributed in the hope that it will be useful,
12 but WITHOUT ANY WARRANTY; without even the implied warranty of
13 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
14 GNU General Public License for more details.
15
16 You should have received a copy of the GNU General Public License
17 along with OPM. If not, see <http://www.gnu.org/licenses/>.
18 */
19
20#ifndef OPM_RST_CONFIG_HPP
21#define OPM_RST_CONFIG_HPP
22
23
24/*
25 The RestartConfig class internalizes information of when (at which
26 report steps) we should save restart files, and which properties
27 should be included in the restart files. The configuration of this
28 immensely complex, and this code is unfortunately also way too
29 complex.
30
31 The most basic question to disentangle is the "When to write restart
32 files" versus "What data to store write in the restart file". As
33 expressed in the deck keywords this completely entangled, in this
34 implementation we have tried to disentangle it:
35
36 Keywords involved
37 -----------------
38
39 RPTRST: This is the main keyword for configuring restart output; it
40 can be used to configure bothe when to write the files and which
41 properties should be included in the restart files.
42
43
44 RPTSCHED: The main purpose of the RPTSCHED keyword is to configure
45 output from the SCHEDULE section to the PRINT file. However the
46 mneomnic RESTART=n can be used to turn writing of restart files
47 on, and also for values > 2 to some configuration of what is
48 written to the restart file:
49
50 RESTART=1 : As RPTRST,BASIC=1
51 RESTART>1 : As RPTRST,BASIC=2
52 RESTART>2 : Flow is added to restart file
53 RESTART>3 : Fluid in place is added to restart file
54 RESTART=6 : Restart file for every timestep.
55
56
57
58 RPTSOL: The RPTSOL keyword is very similar to the RPTCHED keyword,
59 it configures output from the SOLUTION section to the PRINT file,
60 but just as the RPTSCHED keyword it accepts a RESTART=n mnenonic
61 which can be used similarly to the BASIC=n mnenonic of the RPTRST
62 keyword. In particular the writing of an initial restart files
63 with initial equilibrium solution is controlled by the RPTSOL
64 keyword. If the restart mneonic is greater than 2 that can be
65 used to configure FLOWS and FIP keywords in the restart file.
66
67 RESTART=1 : As RPTRST,BASIC=1
68 RESTART>1 : As RPTRST,BASIC=2
69 RESTART>2 : Flow is added to restart file
70 RESTART>3 : Fluid in place is added to restart file
71
72
73 The basic rule in ECLIPSE is generally that the 'last keyword wins',
74 but for the RPTRST RPTSHCED combination a BASIC setting with n >= 3
75 will override consecutive RESTART=n settings from RPTSCHED.
76
77
78 When to write restart files:
79 ----------------------------
80
81 When to write the restart file is governed by the BASIC=n setting in
82 the RPTRST keyword and the RESTART=n settings in the RPTSOL and
83 RPTSCHED keywords. The most common setting is 'ON' - i.e. BASIC=2
84 which means write a restart file for every report step, that can be
85 turned off again with BASIC=0. For BASIC>2 there are varietes of
86 every n'th report step, and the first report step in every month and
87 every year.
88
89
90 Old style / new style
91 ---------------------
92
93 All of the relevant keywords can be specified using a new style
94 based on string mneomnics and alternatively an old style represented
95 with a *strictly ordered* list of integers. For instance both of
96 these keywords request restart files written for every report step;
97 in addition to the fields required to actually restart the files
98 should contain the relative permeabilities KRO, KRW, KRG:
99
100 RPTRST
101 BASIC=2 KRG KRW KRO /
102
103
104 RPTRST
105 2 9*0 3*1 17*0
106
107 Integer controls and string mneomnics can not be mixed in the same
108 keyword, but they can be mixed in the same deck - and that is
109 actually quite common.
110
111
112 What is written to the restart file
113 -----------------------------------
114
115 The BASIC=n mneonics request the writing of a restart file which
116 should contain 'all properties required to restart', in addition you
117 can configure extra keywords to be added to the restart file. This
118 is configured by just adding a list as:
119
120 RPTRST
121 BASIC=2 KRG KRW KRO /
122
123 It is really *not clear* what is the correct persistence semantics
124 for these keywords, consider for insance the following series of keywords:
125
126 -- Request restart file at every report step, the restart files
127 -- should contain additional properties KRO, KRG and KRW.
128 RPTRST
129 BASIC=2 KRG KRW KRO /
130
131 -- Advance the simulator forward with TSTEP / DATES
132 TSTEP / DATES / WCONxxx
133
134 -- Turn writing of restart files OFF using integer controls.
135 RPTRST
136 0 /
137
138 -- Advance the simulator forward with TSTEP / DATES
139 TSTEP / DATES / WCONxxx
140
141 -- Turn writing of restart files ON using integer controls.
142 RPTRST
143 2 /
144
145 When writing of restart files is turned on again with the last
146 RPTRST keyword, should still the relative permeabilites KRO, KRW and
147 KRG be added to the restart files? The model we have implemented is:
148
149 - The list of keywords written to the restart file is persisted
150 independtly of the BASIC=n setting.
151
152 - Using string based mnonics you can *only add* kewyords to be
153 written to the files. To stop writing a keyword you must use an
154 integer control with value 0.
155
156 Based on this best guess heuristic the final restart files will
157 still contain KRO, KRW and KRG.
158
159
160
161 What is required to restart?
162 ----------------------------
163
164 A restart capable files is requested with the 'BASIC' mneomnic, but
165 exactly which properties the 'BASIC' keyword is expanded to is the
166 responsability of the simulator; i.e. for a black oil simulation you
167 will at the very least need the expansion:
168
169 BASIC -> PRESSURE, SWAT, SGAS, RS, RV
170
171 But this class just carries the boolean information: Yes - restart
172 is requested - expanding as illustrated is the responsability of the
173 simulator.
174
175
176
177
178 What is not supported?
179 ----------------------
180
181 The SAVE keyword is not supported in OPM at all, this implies that
182 the SAVE and SFREQ mneomics are not supported.
183*/
184
185#include <unordered_map>
186#include <map>
187#include <optional>
188
189namespace Opm {
190
191class DeckKeyword;
192class ErrorGuard;
193class ParseContext;
194class SOLUTIONSection;
195
197public:
198 RSTConfig() = default;
199 RSTConfig(const SOLUTIONSection& solution_section, const ParseContext& parseContext, ErrorGuard& errors);
200 void update(const DeckKeyword& keyword, const ParseContext& parseContext, ErrorGuard& errors);
201 void init_next();
202 static RSTConfig first(const RSTConfig& src);
203 static RSTConfig serializationTestObject();
204
205 template<class Serializer>
206 void serializeOp(Serializer& serializer) {
207 serializer(write_rst_file);
208 serializer(keywords);
209 serializer(basic);
210 serializer(freq);
211 serializer(save);
212 }
213
214 bool operator==(const RSTConfig& other) const;
215
216 std::optional<bool> write_rst_file;
217 std::map<std::string, int> keywords;
218 std::optional<int> basic;
219 std::optional<int> freq;
220 bool save = false;
221
222private:
223 void handleRPTSOL(const DeckKeyword& keyword);
224 void handleRPTRST(const DeckKeyword& keyword, const ParseContext& parse_context, ErrorGuard& errors);
225 void handleRPTSCHED(const DeckKeyword& keyword, const ParseContext& parse_context, ErrorGuard& errors);
226 void update_schedule(const std::pair<std::optional<int>, std::optional<int>>& basic_freq);
227};
228
229
230
231} //namespace Opm
232
233
234
235#endif
Definition: DeckKeyword.hpp:36
Definition: ErrorGuard.hpp:29
Definition: ParseContext.hpp:88
Definition: RSTConfig.hpp:196
Definition: DeckSection.hpp:139
Class for (de-)serializing.
Definition: Serializer.hpp:75
This class implements a small container which holds the transmissibility mulitpliers for all the face...
Definition: Exceptions.hpp:29