add `mebos`, a multiplexed ebos variant
`mebos` works similarly as `flow`, but in contrast to `flow`, `mebos`
only creates the deck in the common code path whilst the
'EclipseState' and the other higher-level parser objects are always
created internally by the vanguard. this approach avoids code
duplication and the worst effects of parser API creep.
to avoid having to compile non-trivial compile units multiple times,
the actual code of the variants is moved into `ebos_$VARIANT.{hh,cc}`
files and the respective compile units are each put into a small
static library whilst the main function of said libraries are invoked
by either the multiplexed or the respective specialized simulator's
`main()`. This is also somewhat similar of how `flow` works, with the
difference that `mebos` uses the blackoil variant to determine the
parameters it needs to know for parsing the deck instead of
introducing a "fake" type tag for this. The rationale is to reduce
compile time compared to the "fake type tag" approach and -- to a
lesser extend -- avoid unnecessary copy-and-pasting of code. In
particular, this means that for the vast majority of cases, only one
place needs changed in the code for all `ebos` variants if, for
example, the parser API requires further objects in the future.
2019-06-11 03:22:11 -05:00
|
|
|
// -*- mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*-
|
|
|
|
|
// vi: set et ts=4 sw=4 sts=4:
|
|
|
|
|
/*
|
|
|
|
|
This file is part of the Open Porous Media project (OPM).
|
|
|
|
|
|
|
|
|
|
OPM is free software: you can redistribute it and/or modify
|
|
|
|
|
it under the terms of the GNU General Public License as published by
|
|
|
|
|
the Free Software Foundation, either version 2 of the License, or
|
|
|
|
|
(at your option) any later version.
|
|
|
|
|
|
|
|
|
|
OPM is distributed in the hope that it will be useful,
|
|
|
|
|
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
|
GNU General Public License for more details.
|
|
|
|
|
|
|
|
|
|
You should have received a copy of the GNU General Public License
|
|
|
|
|
along with OPM. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
|
|
|
|
|
|
Consult the COPYING file in the top-level source directory of this
|
|
|
|
|
module for the precise wording of the license and the list of
|
|
|
|
|
copyright holders.
|
|
|
|
|
*/
|
|
|
|
|
/*!
|
|
|
|
|
* \file
|
|
|
|
|
*
|
|
|
|
|
* \brief The main file of mebos, an multiplexed-version of ebos, the general-purpose
|
|
|
|
|
* black-oil simulator for ECL decks for research purposes.
|
|
|
|
|
*
|
|
|
|
|
* Just like 'flow', it does not require to select the simulator binary to run a deck
|
|
|
|
|
* that uses certain options like twophase, solvent, polymer or thermal in advance.
|
|
|
|
|
*/
|
|
|
|
|
#include "config.h"
|
|
|
|
|
|
|
|
|
|
#include "ebos_blackoil.hh"
|
|
|
|
|
#include "ebos_oilwater.hh"
|
|
|
|
|
#include "ebos_gasoil.hh"
|
|
|
|
|
// TODO (?): #include "ebos_watergas.hh"
|
|
|
|
|
#include "ebos_thermal.hh"
|
|
|
|
|
#include "ebos_solvent.hh"
|
|
|
|
|
#include "ebos_polymer.hh"
|
2019-08-09 04:04:45 -05:00
|
|
|
#include "ebos_foam.hh"
|
add `mebos`, a multiplexed ebos variant
`mebos` works similarly as `flow`, but in contrast to `flow`, `mebos`
only creates the deck in the common code path whilst the
'EclipseState' and the other higher-level parser objects are always
created internally by the vanguard. this approach avoids code
duplication and the worst effects of parser API creep.
to avoid having to compile non-trivial compile units multiple times,
the actual code of the variants is moved into `ebos_$VARIANT.{hh,cc}`
files and the respective compile units are each put into a small
static library whilst the main function of said libraries are invoked
by either the multiplexed or the respective specialized simulator's
`main()`. This is also somewhat similar of how `flow` works, with the
difference that `mebos` uses the blackoil variant to determine the
parameters it needs to know for parsing the deck instead of
introducing a "fake" type tag for this. The rationale is to reduce
compile time compared to the "fake type tag" approach and -- to a
lesser extend -- avoid unnecessary copy-and-pasting of code. In
particular, this means that for the vast majority of cases, only one
place needs changed in the code for all `ebos` variants if, for
example, the parser API requires further objects in the future.
2019-06-11 03:22:11 -05:00
|
|
|
|
2019-09-16 03:58:20 -05:00
|
|
|
#include <opm/models/utils/propertysystem.hh>
|
add `mebos`, a multiplexed ebos variant
`mebos` works similarly as `flow`, but in contrast to `flow`, `mebos`
only creates the deck in the common code path whilst the
'EclipseState' and the other higher-level parser objects are always
created internally by the vanguard. this approach avoids code
duplication and the worst effects of parser API creep.
to avoid having to compile non-trivial compile units multiple times,
the actual code of the variants is moved into `ebos_$VARIANT.{hh,cc}`
files and the respective compile units are each put into a small
static library whilst the main function of said libraries are invoked
by either the multiplexed or the respective specialized simulator's
`main()`. This is also somewhat similar of how `flow` works, with the
difference that `mebos` uses the blackoil variant to determine the
parameters it needs to know for parsing the deck instead of
introducing a "fake" type tag for this. The rationale is to reduce
compile time compared to the "fake type tag" approach and -- to a
lesser extend -- avoid unnecessary copy-and-pasting of code. In
particular, this means that for the vast majority of cases, only one
place needs changed in the code for all `ebos` variants if, for
example, the parser API requires further objects in the future.
2019-06-11 03:22:11 -05:00
|
|
|
|
|
|
|
|
#include <dune/common/parallel/mpihelper.hh>
|
|
|
|
|
#include <dune/common/timer.hh>
|
|
|
|
|
|
|
|
|
|
#include <opm/parser/eclipse/Parser/Parser.hpp>
|
|
|
|
|
#include <opm/parser/eclipse/Parser/ParseContext.hpp>
|
|
|
|
|
#include <opm/parser/eclipse/Parser/ErrorGuard.hpp>
|
|
|
|
|
#include <opm/parser/eclipse/Deck/Deck.hpp>
|
|
|
|
|
|
|
|
|
|
#include <string>
|
|
|
|
|
#include <memory>
|
|
|
|
|
|
|
|
|
|
int main(int argc, char **argv)
|
|
|
|
|
{
|
|
|
|
|
Dune::Timer externalSetupTimer;
|
|
|
|
|
externalSetupTimer.start();
|
|
|
|
|
|
2019-09-05 10:04:39 -05:00
|
|
|
if (!Opm::ebosBlackOilDeckFileNameIsSet(argc, argv))
|
add `mebos`, a multiplexed ebos variant
`mebos` works similarly as `flow`, but in contrast to `flow`, `mebos`
only creates the deck in the common code path whilst the
'EclipseState' and the other higher-level parser objects are always
created internally by the vanguard. this approach avoids code
duplication and the worst effects of parser API creep.
to avoid having to compile non-trivial compile units multiple times,
the actual code of the variants is moved into `ebos_$VARIANT.{hh,cc}`
files and the respective compile units are each put into a small
static library whilst the main function of said libraries are invoked
by either the multiplexed or the respective specialized simulator's
`main()`. This is also somewhat similar of how `flow` works, with the
difference that `mebos` uses the blackoil variant to determine the
parameters it needs to know for parsing the deck instead of
introducing a "fake" type tag for this. The rationale is to reduce
compile time compared to the "fake type tag" approach and -- to a
lesser extend -- avoid unnecessary copy-and-pasting of code. In
particular, this means that for the vast majority of cases, only one
place needs changed in the code for all `ebos` variants if, for
example, the parser API requires further objects in the future.
2019-06-11 03:22:11 -05:00
|
|
|
// no deck was specified, e.g., --help. use the black oil variant to figure out
|
|
|
|
|
// what exactly should be done
|
2019-09-05 10:04:39 -05:00
|
|
|
return Opm::ebosBlackOilMain(argc, argv);
|
add `mebos`, a multiplexed ebos variant
`mebos` works similarly as `flow`, but in contrast to `flow`, `mebos`
only creates the deck in the common code path whilst the
'EclipseState' and the other higher-level parser objects are always
created internally by the vanguard. this approach avoids code
duplication and the worst effects of parser API creep.
to avoid having to compile non-trivial compile units multiple times,
the actual code of the variants is moved into `ebos_$VARIANT.{hh,cc}`
files and the respective compile units are each put into a small
static library whilst the main function of said libraries are invoked
by either the multiplexed or the respective specialized simulator's
`main()`. This is also somewhat similar of how `flow` works, with the
difference that `mebos` uses the blackoil variant to determine the
parameters it needs to know for parsing the deck instead of
introducing a "fake" type tag for this. The rationale is to reduce
compile time compared to the "fake type tag" approach and -- to a
lesser extend -- avoid unnecessary copy-and-pasting of code. In
particular, this means that for the vast majority of cases, only one
place needs changed in the code for all `ebos` variants if, for
example, the parser API requires further objects in the future.
2019-06-11 03:22:11 -05:00
|
|
|
|
|
|
|
|
std::string deckFileName =
|
2019-09-05 10:04:39 -05:00
|
|
|
Opm::ebosBlackOilGetDeckFileName(argc, argv);
|
add `mebos`, a multiplexed ebos variant
`mebos` works similarly as `flow`, but in contrast to `flow`, `mebos`
only creates the deck in the common code path whilst the
'EclipseState' and the other higher-level parser objects are always
created internally by the vanguard. this approach avoids code
duplication and the worst effects of parser API creep.
to avoid having to compile non-trivial compile units multiple times,
the actual code of the variants is moved into `ebos_$VARIANT.{hh,cc}`
files and the respective compile units are each put into a small
static library whilst the main function of said libraries are invoked
by either the multiplexed or the respective specialized simulator's
`main()`. This is also somewhat similar of how `flow` works, with the
difference that `mebos` uses the blackoil variant to determine the
parameters it needs to know for parsing the deck instead of
introducing a "fake" type tag for this. The rationale is to reduce
compile time compared to the "fake type tag" approach and -- to a
lesser extend -- avoid unnecessary copy-and-pasting of code. In
particular, this means that for the vast majority of cases, only one
place needs changed in the code for all `ebos` variants if, for
example, the parser API requires further objects in the future.
2019-06-11 03:22:11 -05:00
|
|
|
|
|
|
|
|
std::unique_ptr<Opm::ParseContext> parseContext
|
2019-09-05 10:04:39 -05:00
|
|
|
= Opm::ebosBlackOilCreateParseContext(argc, argv);
|
add `mebos`, a multiplexed ebos variant
`mebos` works similarly as `flow`, but in contrast to `flow`, `mebos`
only creates the deck in the common code path whilst the
'EclipseState' and the other higher-level parser objects are always
created internally by the vanguard. this approach avoids code
duplication and the worst effects of parser API creep.
to avoid having to compile non-trivial compile units multiple times,
the actual code of the variants is moved into `ebos_$VARIANT.{hh,cc}`
files and the respective compile units are each put into a small
static library whilst the main function of said libraries are invoked
by either the multiplexed or the respective specialized simulator's
`main()`. This is also somewhat similar of how `flow` works, with the
difference that `mebos` uses the blackoil variant to determine the
parameters it needs to know for parsing the deck instead of
introducing a "fake" type tag for this. The rationale is to reduce
compile time compared to the "fake type tag" approach and -- to a
lesser extend -- avoid unnecessary copy-and-pasting of code. In
particular, this means that for the vast majority of cases, only one
place needs changed in the code for all `ebos` variants if, for
example, the parser API requires further objects in the future.
2019-06-11 03:22:11 -05:00
|
|
|
std::unique_ptr<Opm::ErrorGuard> errorGuard(new Opm::ErrorGuard);
|
|
|
|
|
|
|
|
|
|
// deal with parallel runs
|
|
|
|
|
int myRank = Dune::MPIHelper::instance(argc, argv).rank();
|
|
|
|
|
|
|
|
|
|
Opm::Parser parser;
|
|
|
|
|
// parse the deck file
|
|
|
|
|
if (myRank == 0)
|
|
|
|
|
std::cout << "Parsing deck file \"" << deckFileName << "\"" << std::endl;
|
|
|
|
|
std::unique_ptr<Opm::Deck> deck(new Opm::Deck(parser.parseFile(deckFileName, *parseContext, *errorGuard)));
|
|
|
|
|
|
|
|
|
|
// TODO: check which variant ought to be used
|
|
|
|
|
bool waterActive = deck->hasKeyword("WATER");
|
|
|
|
|
bool gasActive = deck->hasKeyword("GAS");
|
|
|
|
|
bool oilActive = deck->hasKeyword("OIL");
|
|
|
|
|
bool solventActive = deck->hasKeyword("SOLVENT");
|
|
|
|
|
bool polymerActive = deck->hasKeyword("POLYMER");
|
2019-08-09 04:04:45 -05:00
|
|
|
bool foamActive = deck->hasKeyword("FOAM");
|
add `mebos`, a multiplexed ebos variant
`mebos` works similarly as `flow`, but in contrast to `flow`, `mebos`
only creates the deck in the common code path whilst the
'EclipseState' and the other higher-level parser objects are always
created internally by the vanguard. this approach avoids code
duplication and the worst effects of parser API creep.
to avoid having to compile non-trivial compile units multiple times,
the actual code of the variants is moved into `ebos_$VARIANT.{hh,cc}`
files and the respective compile units are each put into a small
static library whilst the main function of said libraries are invoked
by either the multiplexed or the respective specialized simulator's
`main()`. This is also somewhat similar of how `flow` works, with the
difference that `mebos` uses the blackoil variant to determine the
parameters it needs to know for parsing the deck instead of
introducing a "fake" type tag for this. The rationale is to reduce
compile time compared to the "fake type tag" approach and -- to a
lesser extend -- avoid unnecessary copy-and-pasting of code. In
particular, this means that for the vast majority of cases, only one
place needs changed in the code for all `ebos` variants if, for
example, the parser API requires further objects in the future.
2019-06-11 03:22:11 -05:00
|
|
|
bool thermalActive = deck->hasKeyword("THERMAL") || deck->hasKeyword("TEMP");
|
|
|
|
|
|
|
|
|
|
std::stringstream notSupportedErrorStream;
|
|
|
|
|
notSupportedErrorStream << "deck not supported by mebos, you might want to use a specialized binary. Active options:\n"
|
|
|
|
|
<< " water: " << waterActive << "\n"
|
|
|
|
|
<< " gas: " << gasActive << "\n"
|
|
|
|
|
<< " oil: " << oilActive << "\n"
|
|
|
|
|
<< " solvent: " << solventActive << "\n"
|
|
|
|
|
<< " polymer: " << polymerActive << "\n"
|
2019-08-09 04:04:45 -05:00
|
|
|
<< " foam: " << foamActive << "\n"
|
add `mebos`, a multiplexed ebos variant
`mebos` works similarly as `flow`, but in contrast to `flow`, `mebos`
only creates the deck in the common code path whilst the
'EclipseState' and the other higher-level parser objects are always
created internally by the vanguard. this approach avoids code
duplication and the worst effects of parser API creep.
to avoid having to compile non-trivial compile units multiple times,
the actual code of the variants is moved into `ebos_$VARIANT.{hh,cc}`
files and the respective compile units are each put into a small
static library whilst the main function of said libraries are invoked
by either the multiplexed or the respective specialized simulator's
`main()`. This is also somewhat similar of how `flow` works, with the
difference that `mebos` uses the blackoil variant to determine the
parameters it needs to know for parsing the deck instead of
introducing a "fake" type tag for this. The rationale is to reduce
compile time compared to the "fake type tag" approach and -- to a
lesser extend -- avoid unnecessary copy-and-pasting of code. In
particular, this means that for the vast majority of cases, only one
place needs changed in the code for all `ebos` variants if, for
example, the parser API requires further objects in the future.
2019-06-11 03:22:11 -05:00
|
|
|
<< " thermal/temperature: " << thermalActive << "\n";
|
|
|
|
|
|
|
|
|
|
int numBlackOilPhases = (waterActive?1:0) + (gasActive?1:0) + (oilActive?1:0);
|
|
|
|
|
if (numBlackOilPhases == 0) {
|
|
|
|
|
notSupportedErrorStream << "\n"
|
|
|
|
|
<< "no black-oil phase (water, gas or oil) specified.\n";
|
|
|
|
|
std::cerr << notSupportedErrorStream.str() << std::endl;
|
|
|
|
|
std::abort();
|
|
|
|
|
}
|
|
|
|
|
else if (numBlackOilPhases == 1) {
|
|
|
|
|
notSupportedErrorStream << "\n"
|
|
|
|
|
<< "single-phase simulations are unsupported\n";
|
|
|
|
|
std::cerr << notSupportedErrorStream.str() << std::endl;
|
|
|
|
|
std::abort();
|
|
|
|
|
}
|
|
|
|
|
else if (numBlackOilPhases == 2) {
|
|
|
|
|
if (solventActive) {
|
|
|
|
|
notSupportedErrorStream << "\n"
|
|
|
|
|
<< "combining twophase and solvent is not supported by the multiplexed simulator\n";
|
|
|
|
|
std::cerr << notSupportedErrorStream.str() << std::endl;
|
|
|
|
|
std::abort();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (polymerActive) {
|
|
|
|
|
notSupportedErrorStream << "\n"
|
|
|
|
|
<< "combining twophase and polymer is not supported by the multiplexed simulator\n";
|
|
|
|
|
std::cerr << notSupportedErrorStream.str() << std::endl;
|
|
|
|
|
std::abort();
|
|
|
|
|
}
|
|
|
|
|
|
2019-08-09 04:04:45 -05:00
|
|
|
if (foamActive) {
|
|
|
|
|
notSupportedErrorStream << "\n"
|
|
|
|
|
<< "combining twophase and foam is not supported by the multiplexed simulator\n";
|
|
|
|
|
std::cerr << notSupportedErrorStream.str() << std::endl;
|
|
|
|
|
std::abort();
|
|
|
|
|
}
|
|
|
|
|
|
add `mebos`, a multiplexed ebos variant
`mebos` works similarly as `flow`, but in contrast to `flow`, `mebos`
only creates the deck in the common code path whilst the
'EclipseState' and the other higher-level parser objects are always
created internally by the vanguard. this approach avoids code
duplication and the worst effects of parser API creep.
to avoid having to compile non-trivial compile units multiple times,
the actual code of the variants is moved into `ebos_$VARIANT.{hh,cc}`
files and the respective compile units are each put into a small
static library whilst the main function of said libraries are invoked
by either the multiplexed or the respective specialized simulator's
`main()`. This is also somewhat similar of how `flow` works, with the
difference that `mebos` uses the blackoil variant to determine the
parameters it needs to know for parsing the deck instead of
introducing a "fake" type tag for this. The rationale is to reduce
compile time compared to the "fake type tag" approach and -- to a
lesser extend -- avoid unnecessary copy-and-pasting of code. In
particular, this means that for the vast majority of cases, only one
place needs changed in the code for all `ebos` variants if, for
example, the parser API requires further objects in the future.
2019-06-11 03:22:11 -05:00
|
|
|
if (thermalActive) {
|
|
|
|
|
notSupportedErrorStream << "\n"
|
|
|
|
|
<< "combining twophase and energy conservation is not supported by the multiplexed simulator\n";
|
|
|
|
|
std::cerr << notSupportedErrorStream.str() << std::endl;
|
|
|
|
|
std::abort();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (oilActive && waterActive) {
|
|
|
|
|
if (myRank == 0)
|
|
|
|
|
std::cout << "Using oil-water mode" << std::endl;
|
2019-09-05 10:04:39 -05:00
|
|
|
Opm::ebosOilWaterSetDeck(deck.get(),
|
|
|
|
|
parseContext.get(),
|
|
|
|
|
errorGuard.get(),
|
|
|
|
|
externalSetupTimer.elapsed());
|
|
|
|
|
return Opm::ebosOilWaterMain(argc, argv);
|
add `mebos`, a multiplexed ebos variant
`mebos` works similarly as `flow`, but in contrast to `flow`, `mebos`
only creates the deck in the common code path whilst the
'EclipseState' and the other higher-level parser objects are always
created internally by the vanguard. this approach avoids code
duplication and the worst effects of parser API creep.
to avoid having to compile non-trivial compile units multiple times,
the actual code of the variants is moved into `ebos_$VARIANT.{hh,cc}`
files and the respective compile units are each put into a small
static library whilst the main function of said libraries are invoked
by either the multiplexed or the respective specialized simulator's
`main()`. This is also somewhat similar of how `flow` works, with the
difference that `mebos` uses the blackoil variant to determine the
parameters it needs to know for parsing the deck instead of
introducing a "fake" type tag for this. The rationale is to reduce
compile time compared to the "fake type tag" approach and -- to a
lesser extend -- avoid unnecessary copy-and-pasting of code. In
particular, this means that for the vast majority of cases, only one
place needs changed in the code for all `ebos` variants if, for
example, the parser API requires further objects in the future.
2019-06-11 03:22:11 -05:00
|
|
|
}
|
|
|
|
|
else if (oilActive && gasActive) {
|
|
|
|
|
// run ebos_gasoil
|
|
|
|
|
if (myRank == 0)
|
|
|
|
|
std::cout << "Using gas-oil mode" << std::endl;
|
2019-09-05 10:04:39 -05:00
|
|
|
Opm::ebosGasOilSetDeck(deck.get(),
|
|
|
|
|
parseContext.get(),
|
|
|
|
|
errorGuard.get(),
|
|
|
|
|
externalSetupTimer.elapsed());
|
|
|
|
|
return Opm::ebosGasOilMain(argc, argv);
|
add `mebos`, a multiplexed ebos variant
`mebos` works similarly as `flow`, but in contrast to `flow`, `mebos`
only creates the deck in the common code path whilst the
'EclipseState' and the other higher-level parser objects are always
created internally by the vanguard. this approach avoids code
duplication and the worst effects of parser API creep.
to avoid having to compile non-trivial compile units multiple times,
the actual code of the variants is moved into `ebos_$VARIANT.{hh,cc}`
files and the respective compile units are each put into a small
static library whilst the main function of said libraries are invoked
by either the multiplexed or the respective specialized simulator's
`main()`. This is also somewhat similar of how `flow` works, with the
difference that `mebos` uses the blackoil variant to determine the
parameters it needs to know for parsing the deck instead of
introducing a "fake" type tag for this. The rationale is to reduce
compile time compared to the "fake type tag" approach and -- to a
lesser extend -- avoid unnecessary copy-and-pasting of code. In
particular, this means that for the vast majority of cases, only one
place needs changed in the code for all `ebos` variants if, for
example, the parser API requires further objects in the future.
2019-06-11 03:22:11 -05:00
|
|
|
}
|
|
|
|
|
else if (waterActive && gasActive) {
|
|
|
|
|
notSupportedErrorStream << "\n"
|
|
|
|
|
<< "water-gas simulations are currently unsupported\n";
|
|
|
|
|
std::cerr << notSupportedErrorStream.str() << std::endl;
|
|
|
|
|
std::abort();
|
|
|
|
|
}
|
|
|
|
|
}
|
2019-08-09 04:04:45 -05:00
|
|
|
else if (foamActive) {
|
|
|
|
|
if (solventActive) {
|
|
|
|
|
notSupportedErrorStream << "\n"
|
|
|
|
|
<< "combining foam and solvent is not supported by the multiplexed simulator\n";
|
|
|
|
|
std::cerr << notSupportedErrorStream.str() << std::endl;
|
|
|
|
|
std::abort();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (polymerActive) {
|
|
|
|
|
notSupportedErrorStream << "\n"
|
|
|
|
|
<< "combining foam and polymer is not supported by the multiplexed simulator\n";
|
|
|
|
|
std::cerr << notSupportedErrorStream.str() << std::endl;
|
|
|
|
|
std::abort();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (thermalActive) {
|
|
|
|
|
notSupportedErrorStream << "\n"
|
|
|
|
|
<< "combining foam and and energy conservation is not supported by the multiplexed simulator\n";
|
|
|
|
|
std::cerr << notSupportedErrorStream.str() << std::endl;
|
|
|
|
|
std::abort();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// run ebos_foam
|
|
|
|
|
if (myRank == 0)
|
|
|
|
|
std::cout << "Using foam mode" << std::endl;
|
2019-09-05 10:04:39 -05:00
|
|
|
Opm::ebosFoamSetDeck(deck.get(),
|
|
|
|
|
parseContext.get(),
|
|
|
|
|
errorGuard.get(),
|
|
|
|
|
externalSetupTimer.elapsed());
|
|
|
|
|
return Opm::ebosFoamMain(argc, argv);
|
2019-08-09 04:04:45 -05:00
|
|
|
}
|
add `mebos`, a multiplexed ebos variant
`mebos` works similarly as `flow`, but in contrast to `flow`, `mebos`
only creates the deck in the common code path whilst the
'EclipseState' and the other higher-level parser objects are always
created internally by the vanguard. this approach avoids code
duplication and the worst effects of parser API creep.
to avoid having to compile non-trivial compile units multiple times,
the actual code of the variants is moved into `ebos_$VARIANT.{hh,cc}`
files and the respective compile units are each put into a small
static library whilst the main function of said libraries are invoked
by either the multiplexed or the respective specialized simulator's
`main()`. This is also somewhat similar of how `flow` works, with the
difference that `mebos` uses the blackoil variant to determine the
parameters it needs to know for parsing the deck instead of
introducing a "fake" type tag for this. The rationale is to reduce
compile time compared to the "fake type tag" approach and -- to a
lesser extend -- avoid unnecessary copy-and-pasting of code. In
particular, this means that for the vast majority of cases, only one
place needs changed in the code for all `ebos` variants if, for
example, the parser API requires further objects in the future.
2019-06-11 03:22:11 -05:00
|
|
|
else if (polymerActive) {
|
|
|
|
|
if (solventActive) {
|
|
|
|
|
notSupportedErrorStream << "\n"
|
|
|
|
|
<< "combining polymer and solvent is not supported by the multiplexed simulator\n";
|
|
|
|
|
std::cerr << notSupportedErrorStream.str() << std::endl;
|
|
|
|
|
std::abort();
|
|
|
|
|
}
|
|
|
|
|
|
2019-08-09 04:04:45 -05:00
|
|
|
if (foamActive) {
|
|
|
|
|
notSupportedErrorStream << "\n"
|
|
|
|
|
<< "combining polymer and foam is not supported by the multiplexed simulator\n";
|
|
|
|
|
std::cerr << notSupportedErrorStream.str() << std::endl;
|
|
|
|
|
std::abort();
|
|
|
|
|
}
|
|
|
|
|
|
add `mebos`, a multiplexed ebos variant
`mebos` works similarly as `flow`, but in contrast to `flow`, `mebos`
only creates the deck in the common code path whilst the
'EclipseState' and the other higher-level parser objects are always
created internally by the vanguard. this approach avoids code
duplication and the worst effects of parser API creep.
to avoid having to compile non-trivial compile units multiple times,
the actual code of the variants is moved into `ebos_$VARIANT.{hh,cc}`
files and the respective compile units are each put into a small
static library whilst the main function of said libraries are invoked
by either the multiplexed or the respective specialized simulator's
`main()`. This is also somewhat similar of how `flow` works, with the
difference that `mebos` uses the blackoil variant to determine the
parameters it needs to know for parsing the deck instead of
introducing a "fake" type tag for this. The rationale is to reduce
compile time compared to the "fake type tag" approach and -- to a
lesser extend -- avoid unnecessary copy-and-pasting of code. In
particular, this means that for the vast majority of cases, only one
place needs changed in the code for all `ebos` variants if, for
example, the parser API requires further objects in the future.
2019-06-11 03:22:11 -05:00
|
|
|
if (thermalActive) {
|
|
|
|
|
notSupportedErrorStream << "\n"
|
|
|
|
|
<< "combining polymer and and energy conservation is not supported by the multiplexed simulator\n";
|
|
|
|
|
std::cerr << notSupportedErrorStream.str() << std::endl;
|
|
|
|
|
std::abort();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// run ebos_polymer
|
|
|
|
|
if (myRank == 0)
|
|
|
|
|
std::cout << "Using polymer mode" << std::endl;
|
2019-09-05 10:04:39 -05:00
|
|
|
Opm::ebosPolymerSetDeck(deck.get(),
|
|
|
|
|
parseContext.get(),
|
|
|
|
|
errorGuard.get(),
|
|
|
|
|
externalSetupTimer.elapsed());
|
|
|
|
|
return Opm::ebosPolymerMain(argc, argv);
|
add `mebos`, a multiplexed ebos variant
`mebos` works similarly as `flow`, but in contrast to `flow`, `mebos`
only creates the deck in the common code path whilst the
'EclipseState' and the other higher-level parser objects are always
created internally by the vanguard. this approach avoids code
duplication and the worst effects of parser API creep.
to avoid having to compile non-trivial compile units multiple times,
the actual code of the variants is moved into `ebos_$VARIANT.{hh,cc}`
files and the respective compile units are each put into a small
static library whilst the main function of said libraries are invoked
by either the multiplexed or the respective specialized simulator's
`main()`. This is also somewhat similar of how `flow` works, with the
difference that `mebos` uses the blackoil variant to determine the
parameters it needs to know for parsing the deck instead of
introducing a "fake" type tag for this. The rationale is to reduce
compile time compared to the "fake type tag" approach and -- to a
lesser extend -- avoid unnecessary copy-and-pasting of code. In
particular, this means that for the vast majority of cases, only one
place needs changed in the code for all `ebos` variants if, for
example, the parser API requires further objects in the future.
2019-06-11 03:22:11 -05:00
|
|
|
}
|
|
|
|
|
else if (solventActive) {
|
|
|
|
|
if (polymerActive) {
|
|
|
|
|
notSupportedErrorStream << "\n"
|
2019-08-09 04:04:45 -05:00
|
|
|
<< "combining solvent and polymer is not supported\n";
|
|
|
|
|
std::cerr << notSupportedErrorStream.str() << std::endl;
|
|
|
|
|
std::abort();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (foamActive) {
|
|
|
|
|
notSupportedErrorStream << "\n"
|
|
|
|
|
<< "combining solvent and foam is not supported\n";
|
add `mebos`, a multiplexed ebos variant
`mebos` works similarly as `flow`, but in contrast to `flow`, `mebos`
only creates the deck in the common code path whilst the
'EclipseState' and the other higher-level parser objects are always
created internally by the vanguard. this approach avoids code
duplication and the worst effects of parser API creep.
to avoid having to compile non-trivial compile units multiple times,
the actual code of the variants is moved into `ebos_$VARIANT.{hh,cc}`
files and the respective compile units are each put into a small
static library whilst the main function of said libraries are invoked
by either the multiplexed or the respective specialized simulator's
`main()`. This is also somewhat similar of how `flow` works, with the
difference that `mebos` uses the blackoil variant to determine the
parameters it needs to know for parsing the deck instead of
introducing a "fake" type tag for this. The rationale is to reduce
compile time compared to the "fake type tag" approach and -- to a
lesser extend -- avoid unnecessary copy-and-pasting of code. In
particular, this means that for the vast majority of cases, only one
place needs changed in the code for all `ebos` variants if, for
example, the parser API requires further objects in the future.
2019-06-11 03:22:11 -05:00
|
|
|
std::cerr << notSupportedErrorStream.str() << std::endl;
|
|
|
|
|
std::abort();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (thermalActive) {
|
|
|
|
|
notSupportedErrorStream << "\n"
|
2019-08-09 04:04:45 -05:00
|
|
|
<< "combining solvent and and energy conservation is not supported\n";
|
add `mebos`, a multiplexed ebos variant
`mebos` works similarly as `flow`, but in contrast to `flow`, `mebos`
only creates the deck in the common code path whilst the
'EclipseState' and the other higher-level parser objects are always
created internally by the vanguard. this approach avoids code
duplication and the worst effects of parser API creep.
to avoid having to compile non-trivial compile units multiple times,
the actual code of the variants is moved into `ebos_$VARIANT.{hh,cc}`
files and the respective compile units are each put into a small
static library whilst the main function of said libraries are invoked
by either the multiplexed or the respective specialized simulator's
`main()`. This is also somewhat similar of how `flow` works, with the
difference that `mebos` uses the blackoil variant to determine the
parameters it needs to know for parsing the deck instead of
introducing a "fake" type tag for this. The rationale is to reduce
compile time compared to the "fake type tag" approach and -- to a
lesser extend -- avoid unnecessary copy-and-pasting of code. In
particular, this means that for the vast majority of cases, only one
place needs changed in the code for all `ebos` variants if, for
example, the parser API requires further objects in the future.
2019-06-11 03:22:11 -05:00
|
|
|
std::cerr << notSupportedErrorStream.str() << std::endl;
|
|
|
|
|
std::abort();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// run ebos_solvent
|
|
|
|
|
if (myRank == 0)
|
|
|
|
|
std::cout << "Using solvent mode" << std::endl;
|
2019-09-05 10:04:39 -05:00
|
|
|
Opm::ebosSolventSetDeck(deck.get(),
|
|
|
|
|
parseContext.get(),
|
|
|
|
|
errorGuard.get(),
|
|
|
|
|
externalSetupTimer.elapsed());
|
|
|
|
|
return Opm::ebosSolventMain(argc, argv);
|
add `mebos`, a multiplexed ebos variant
`mebos` works similarly as `flow`, but in contrast to `flow`, `mebos`
only creates the deck in the common code path whilst the
'EclipseState' and the other higher-level parser objects are always
created internally by the vanguard. this approach avoids code
duplication and the worst effects of parser API creep.
to avoid having to compile non-trivial compile units multiple times,
the actual code of the variants is moved into `ebos_$VARIANT.{hh,cc}`
files and the respective compile units are each put into a small
static library whilst the main function of said libraries are invoked
by either the multiplexed or the respective specialized simulator's
`main()`. This is also somewhat similar of how `flow` works, with the
difference that `mebos` uses the blackoil variant to determine the
parameters it needs to know for parsing the deck instead of
introducing a "fake" type tag for this. The rationale is to reduce
compile time compared to the "fake type tag" approach and -- to a
lesser extend -- avoid unnecessary copy-and-pasting of code. In
particular, this means that for the vast majority of cases, only one
place needs changed in the code for all `ebos` variants if, for
example, the parser API requires further objects in the future.
2019-06-11 03:22:11 -05:00
|
|
|
}
|
|
|
|
|
else if (thermalActive) {
|
|
|
|
|
if (solventActive) {
|
|
|
|
|
notSupportedErrorStream << "\n"
|
|
|
|
|
<< "combining thermal and solvent is not supported by the multiplexed simulator\n";
|
|
|
|
|
std::cerr << notSupportedErrorStream.str() << std::endl;
|
|
|
|
|
std::abort();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (polymerActive) {
|
|
|
|
|
notSupportedErrorStream << "\n"
|
|
|
|
|
<< "combining thermal and polymer is not supported by the multiplexed simulator\n";
|
|
|
|
|
std::cerr << notSupportedErrorStream.str() << std::endl;
|
|
|
|
|
std::abort();
|
2019-08-09 04:04:45 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (foamActive) {
|
|
|
|
|
notSupportedErrorStream << "\n"
|
|
|
|
|
<< "combining thermal and foam is not supported by the multiplexed simulator\n";
|
|
|
|
|
std::cerr << notSupportedErrorStream.str() << std::endl;
|
|
|
|
|
std::abort();
|
add `mebos`, a multiplexed ebos variant
`mebos` works similarly as `flow`, but in contrast to `flow`, `mebos`
only creates the deck in the common code path whilst the
'EclipseState' and the other higher-level parser objects are always
created internally by the vanguard. this approach avoids code
duplication and the worst effects of parser API creep.
to avoid having to compile non-trivial compile units multiple times,
the actual code of the variants is moved into `ebos_$VARIANT.{hh,cc}`
files and the respective compile units are each put into a small
static library whilst the main function of said libraries are invoked
by either the multiplexed or the respective specialized simulator's
`main()`. This is also somewhat similar of how `flow` works, with the
difference that `mebos` uses the blackoil variant to determine the
parameters it needs to know for parsing the deck instead of
introducing a "fake" type tag for this. The rationale is to reduce
compile time compared to the "fake type tag" approach and -- to a
lesser extend -- avoid unnecessary copy-and-pasting of code. In
particular, this means that for the vast majority of cases, only one
place needs changed in the code for all `ebos` variants if, for
example, the parser API requires further objects in the future.
2019-06-11 03:22:11 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// run ebos_thermal
|
|
|
|
|
if (myRank == 0)
|
|
|
|
|
std::cout << "Using thermal mode" << std::endl;
|
2019-09-05 10:04:39 -05:00
|
|
|
Opm::ebosThermalSetDeck(deck.get(),
|
|
|
|
|
parseContext.get(),
|
|
|
|
|
errorGuard.get(),
|
|
|
|
|
externalSetupTimer.elapsed());
|
|
|
|
|
return Opm::ebosThermalMain(argc, argv);
|
add `mebos`, a multiplexed ebos variant
`mebos` works similarly as `flow`, but in contrast to `flow`, `mebos`
only creates the deck in the common code path whilst the
'EclipseState' and the other higher-level parser objects are always
created internally by the vanguard. this approach avoids code
duplication and the worst effects of parser API creep.
to avoid having to compile non-trivial compile units multiple times,
the actual code of the variants is moved into `ebos_$VARIANT.{hh,cc}`
files and the respective compile units are each put into a small
static library whilst the main function of said libraries are invoked
by either the multiplexed or the respective specialized simulator's
`main()`. This is also somewhat similar of how `flow` works, with the
difference that `mebos` uses the blackoil variant to determine the
parameters it needs to know for parsing the deck instead of
introducing a "fake" type tag for this. The rationale is to reduce
compile time compared to the "fake type tag" approach and -- to a
lesser extend -- avoid unnecessary copy-and-pasting of code. In
particular, this means that for the vast majority of cases, only one
place needs changed in the code for all `ebos` variants if, for
example, the parser API requires further objects in the future.
2019-06-11 03:22:11 -05:00
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
if (myRank == 0)
|
|
|
|
|
std::cout << "Using blackoil mode" << std::endl;
|
2019-09-05 10:04:39 -05:00
|
|
|
Opm::ebosBlackOilSetDeck(deck.get(),
|
|
|
|
|
parseContext.get(),
|
|
|
|
|
errorGuard.get(),
|
|
|
|
|
externalSetupTimer.elapsed());
|
|
|
|
|
return Opm::ebosBlackOilMain(argc, argv);
|
add `mebos`, a multiplexed ebos variant
`mebos` works similarly as `flow`, but in contrast to `flow`, `mebos`
only creates the deck in the common code path whilst the
'EclipseState' and the other higher-level parser objects are always
created internally by the vanguard. this approach avoids code
duplication and the worst effects of parser API creep.
to avoid having to compile non-trivial compile units multiple times,
the actual code of the variants is moved into `ebos_$VARIANT.{hh,cc}`
files and the respective compile units are each put into a small
static library whilst the main function of said libraries are invoked
by either the multiplexed or the respective specialized simulator's
`main()`. This is also somewhat similar of how `flow` works, with the
difference that `mebos` uses the blackoil variant to determine the
parameters it needs to know for parsing the deck instead of
introducing a "fake" type tag for this. The rationale is to reduce
compile time compared to the "fake type tag" approach and -- to a
lesser extend -- avoid unnecessary copy-and-pasting of code. In
particular, this means that for the vast majority of cases, only one
place needs changed in the code for all `ebos` variants if, for
example, the parser API requires further objects in the future.
2019-06-11 03:22:11 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (myRank == 0)
|
|
|
|
|
// this is supposed to be unreachable. this should not happen!
|
|
|
|
|
std::cerr << "Oops: something went wrong when deciding which simulator ought to be used" << std::endl;
|
|
|
|
|
std::abort();
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
