2019-03-05 04:41:02 -06: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 A general-purpose simulator for ECL decks using the black-oil model.
|
|
|
|
*/
|
|
|
|
#include "config.h"
|
|
|
|
|
|
|
|
#include "ebos.hh"
|
2019-10-07 07:51:23 -05:00
|
|
|
#include "startEbos.hh"
|
2019-03-05 04:41:02 -06:00
|
|
|
|
|
|
|
BEGIN_PROPERTIES
|
|
|
|
|
|
|
|
NEW_TYPE_TAG(EbosSolventTypeTag, INHERITS_FROM(EbosTypeTag));
|
|
|
|
|
|
|
|
// enable the solvent extension of the black oil model
|
|
|
|
SET_BOOL_PROP(EbosSolventTypeTag, EnableSolvent, true);
|
|
|
|
|
|
|
|
END_PROPERTIES
|
|
|
|
|
2019-09-05 10:04:39 -05:00
|
|
|
namespace Opm {
|
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
|
|
|
|
|
|
|
void ebosSolventSetDeck(Opm::Deck* deck,
|
2019-09-05 10:04:39 -05:00
|
|
|
Opm::ParseContext* parseContext,
|
|
|
|
Opm::ErrorGuard* errorGuard,
|
|
|
|
double externalSetupTime)
|
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
|
|
|
{
|
|
|
|
typedef TTAG(EbosSolventTypeTag) ProblemTypeTag;
|
|
|
|
typedef GET_PROP_TYPE(ProblemTypeTag, Vanguard) Vanguard;
|
|
|
|
|
|
|
|
Vanguard::setExternalSetupTime(externalSetupTime);
|
|
|
|
Vanguard::setExternalParseContext(parseContext);
|
|
|
|
Vanguard::setExternalErrorGuard(errorGuard);
|
|
|
|
Vanguard::setExternalDeck(deck);
|
|
|
|
}
|
|
|
|
|
|
|
|
int ebosSolventMain(int argc, char **argv)
|
2019-03-05 04:41:02 -06:00
|
|
|
{
|
|
|
|
typedef TTAG(EbosSolventTypeTag) ProblemTypeTag;
|
2019-10-07 07:51:23 -05:00
|
|
|
return Opm::startEbos<ProblemTypeTag>(argc, argv);
|
2019-03-05 04:41:02 -06: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
|
|
|
|
|
|
|
}
|