When a restarted model uses SKIPREST, there must be DATES or TSTEP
records/report times that correspond exactly to the restart time.
The current diagnostic message is a little too brief and developer
centric and does not offer sufficient hints to the user as to what
the underlying issue might be.
Try to expand the current message and provide more clues to the user
by mentioning both the SKIPREST and RESTART keywords in addition to
the expected and encountered time points.
Example original message:
Error: Problem with keyword DATES
In PRED_FLOW.DATA line 223
At date: 2019-04-18 - scanned past restart data: 2019-04-12
Example message in this commit:
Error: Problem with keyword DATES
In PRED_FLOW.DATA line 223
In a restarted simulation using SKIPREST, the DATES keyword must have
a record corresponding to the RESTART time 12-Apr-2019 00:00:00.
Reached time 18-Apr-2019 00:00:00 without an intervening record.
This commit adds a new query
SummaryConfig::fip_regions_interreg_flow
that retrieves the set of FIP array names (e.g., FIPNUM and FIPXYZ)
that are associated to any inter-region flow summary keywords. This
query method returns an empty set if there are no inter-region flow
summary keywords.
This commit extends the 'SummaryConfig' support for inter-region
flows to be aware of user-provided FIP arrays. In other words, we
now recognize, e.g., that
ROFT_XYZ
is the cumulative inter-region oil flow volume corresponding to
regions defined by the 'FIPXYZ' region definition.
Somehow using a custom build_ext subclass always triggered a failing
rebuild when testing:
/usr/lib/ccache/g++-10 -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-z,relro -g -fwrapv -O2 -Wl,-z,relro -g -fwrapv -O2 -g -ffile-prefix-map=/build/python3.9-RNBry6/python3.9-3.9.2=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 build/temp.linux-x86_64-3.9/cxx/builtin_pybind11.o build/temp.linux-x86_64-3.9/cxx/connection.o build/temp.linux-x86_64-3.9/cxx/converters.o build/temp.linux-x86_64-3.9/cxx/deck.o build/temp.linux-x86_64-3.9/cxx/deck_keyword.o build/temp.linux-x86_64-3.9/cxx/eclipse_config.o build/temp.linux-x86_64-3.9/cxx/eclipse_grid.o build/temp.linux-x86_64-3.9/cxx/eclipse_io.o build/temp.linux-x86_64-3.9/cxx/eclipse_state.o build/temp.linux-x86_64-3.9/cxx/emodel_util.o build/temp.linux-x86_64-3.9/cxx/export.o build/temp.linux-x86_64-3.9/cxx/field_props.o build/temp.linux-x86_64-3.9/cxx/group.o build/temp.linux-x86_64-3.9/cxx/log.o build/temp.linux-x86_64-3.9/cxx/parsecontext.o build/temp.linux-x86_64-3.9/cxx/parser.o build/temp.linux-x86_64-3.9/cxx/schedule.o build/temp.linux-x86_64-3.9/cxx/summary_state.o build/temp.linux-x86_64-3.9/cxx/table_manager.o build/temp.linux-x86_64-3.9/cxx/unit_system.o build/temp.linux-x86_64-3.9/cxx/well.o -lopmcommon -lboost_system -lstdc++fs -o build/lib.linux-x86_64-3.9/opm/libopmcommon_python.cpython-39-x86_64-linux-gnu.so -fopenmp /usr/lib/x86_64-linux-gnu/libfmt.so.7.1.3
error: can't copy 'build/lib.linux-x86_64-3.9/opm/libopmcommon_python.cpython-39-x86_64-linux-gnu.so': doesn't exist or not a regular file
Therefore we resort to only setting the CC and CXX variables to the
C++ compiler. Note that one cannot use "ccache c++" for CXX.
With the default build_ext the problem vanishes.
CC is the C compiler. CXX is the C++ compiler. Setuptools will
use the C++ compiler for C++ code. Hence it is vital to set that
correctly. If not set the default C++ compiler will be used.
Unfortunately it will use the first string as the CXX compiler and
hence we need to strip ccache. Fortunately it used CC for the
compilation and that works with gcc as well.
