OilfieldToolsNet/opm-simulators
4
0
Fork 0
mirror of https://github.com/OPM/opm-simulators.git synced 2024-12-29 10:40:59 -06:00
Code Issues Packages Projects Releases Wiki Activity
cab2f4b41f
opm-simulators/opm/simulators/wells/SimFIBODetails.hpp

84 lines
2.5 KiB
C++
Raw Normal View History

fix some serious screw-ups almost all of them were caused by recent changes in the master branch: - there were methods added which depend on the types `V` and `DataBlock`. these do not make much sense in the context of the frankenstein simulator. Also, these types are defined globally for the whole Opm namespace in `BlackoilModelBase_impl.hpp` (which should be prosecuted as a fellony IMO)! Besides this, their names are useless; 'V' is the letter which comes after `U` in the alphabet and when it comes to computers basically everything can be seen as a chunk of data (i.e., a `DataBlock`). - it seems like the new and shiny dense-AD based well model was never compiled with assertations enabled, at least some asserts referenced non-existing variables. - the recent output-related API changes were pretty unfortunate because they had the effect of tying the (sub-optimal, IMO) internal structure of the model even closer to the output code: as far as I can see, `rq` does only make sense if the model works *exactly* like BlackoilModelBase and friends. (for flow_ebos, this could be replicated, but first it would be another unnecessary conversion step and second, most of the quantities in `rq` are of type `ADB` and much of the "frankenstein" excercise is devoted to getting rid of these.) I thus reverted back to an old version of the output code and created a `frankenstein` branch in my personal `opm-output` github fork.
2016-09-12 16:28:44 -05:00
/*
Copyright 2013 SINTEF ICT, Applied Mathematics.
Copyright 2014-2016 IRIS AS
Copyright 2015 Andreas Lauser
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 3 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/>.
*/
#ifndef OPM_SIM_FIBO_DETAILS_HPP
#define OPM_SIM_FIBO_DETAILS_HPP
#include <utility>
#include <algorithm>
#include <locale>
Adapt to enum changes
2019-08-27 17:30:12 -05:00
fix some serious screw-ups almost all of them were caused by recent changes in the master branch: - there were methods added which depend on the types `V` and `DataBlock`. these do not make much sense in the context of the frankenstein simulator. Also, these types are defined globally for the whole Opm namespace in `BlackoilModelBase_impl.hpp` (which should be prosecuted as a fellony IMO)! Besides this, their names are useless; 'V' is the letter which comes after `U` in the alphabet and when it comes to computers basically everything can be seen as a chunk of data (i.e., a `DataBlock`). - it seems like the new and shiny dense-AD based well model was never compiled with assertations enabled, at least some asserts referenced non-existing variables. - the recent output-related API changes were pretty unfortunate because they had the effect of tying the (sub-optimal, IMO) internal structure of the model even closer to the output code: as far as I can see, `rq` does only make sense if the model works *exactly* like BlackoilModelBase and friends. (for flow_ebos, this could be replicated, but first it would be another unnecessary conversion step and second, most of the quantities in `rq` are of type `ADB` and much of the "frankenstein" excercise is devoted to getting rid of these.) I thus reverted back to an old version of the output code and created a `frankenstein` branch in my personal `opm-output` github fork.
2016-09-12 16:28:44 -05:00
#include <opm/parser/eclipse/EclipseState/Schedule/Events.hpp>
Rename Well2 -> Well and Group2 -> Group
2019-11-13 16:16:11 -06:00
#include <opm/parser/eclipse/EclipseState/Schedule/Well/Well.hpp>
Adapt to enum changes
2019-08-27 17:30:12 -05:00
fix some serious screw-ups almost all of them were caused by recent changes in the master branch: - there were methods added which depend on the types `V` and `DataBlock`. these do not make much sense in the context of the frankenstein simulator. Also, these types are defined globally for the whole Opm namespace in `BlackoilModelBase_impl.hpp` (which should be prosecuted as a fellony IMO)! Besides this, their names are useless; 'V' is the letter which comes after `U` in the alphabet and when it comes to computers basically everything can be seen as a chunk of data (i.e., a `DataBlock`). - it seems like the new and shiny dense-AD based well model was never compiled with assertations enabled, at least some asserts referenced non-existing variables. - the recent output-related API changes were pretty unfortunate because they had the effect of tying the (sub-optimal, IMO) internal structure of the model even closer to the output code: as far as I can see, `rq` does only make sense if the model works *exactly* like BlackoilModelBase and friends. (for flow_ebos, this could be replicated, but first it would be another unnecessary conversion step and second, most of the quantities in `rq` are of type `ADB` and much of the "frankenstein" excercise is devoted to getting rid of these.) I thus reverted back to an old version of the output code and created a `frankenstein` branch in my personal `opm-output` github fork.
2016-09-12 16:28:44 -05:00
namespace Opm
{
namespace SimFIBODetails {
Rename Well2 -> Well and Group2 -> Group
2019-11-13 16:16:11 -06:00
typedef std::unordered_map<std::string, Well > WellMap;
fix some serious screw-ups almost all of them were caused by recent changes in the master branch: - there were methods added which depend on the types `V` and `DataBlock`. these do not make much sense in the context of the frankenstein simulator. Also, these types are defined globally for the whole Opm namespace in `BlackoilModelBase_impl.hpp` (which should be prosecuted as a fellony IMO)! Besides this, their names are useless; 'V' is the letter which comes after `U` in the alphabet and when it comes to computers basically everything can be seen as a chunk of data (i.e., a `DataBlock`). - it seems like the new and shiny dense-AD based well model was never compiled with assertations enabled, at least some asserts referenced non-existing variables. - the recent output-related API changes were pretty unfortunate because they had the effect of tying the (sub-optimal, IMO) internal structure of the model even closer to the output code: as far as I can see, `rq` does only make sense if the model works *exactly* like BlackoilModelBase and friends. (for flow_ebos, this could be replicated, but first it would be another unnecessary conversion step and second, most of the quantities in `rq` are of type `ADB` and much of the "frankenstein" excercise is devoted to getting rid of these.) I thus reverted back to an old version of the output code and created a `frankenstein` branch in my personal `opm-output` github fork.
2016-09-12 16:28:44 -05:00
inline WellMap
Rename Well2 -> Well and Group2 -> Group
2019-11-13 16:16:11 -06:00
mapWells(const std::vector< Well >& wells)
fix some serious screw-ups almost all of them were caused by recent changes in the master branch: - there were methods added which depend on the types `V` and `DataBlock`. these do not make much sense in the context of the frankenstein simulator. Also, these types are defined globally for the whole Opm namespace in `BlackoilModelBase_impl.hpp` (which should be prosecuted as a fellony IMO)! Besides this, their names are useless; 'V' is the letter which comes after `U` in the alphabet and when it comes to computers basically everything can be seen as a chunk of data (i.e., a `DataBlock`). - it seems like the new and shiny dense-AD based well model was never compiled with assertations enabled, at least some asserts referenced non-existing variables. - the recent output-related API changes were pretty unfortunate because they had the effect of tying the (sub-optimal, IMO) internal structure of the model even closer to the output code: as far as I can see, `rq` does only make sense if the model works *exactly* like BlackoilModelBase and friends. (for flow_ebos, this could be replicated, but first it would be another unnecessary conversion step and second, most of the quantities in `rq` are of type `ADB` and much of the "frankenstein" excercise is devoted to getting rid of these.) I thus reverted back to an old version of the output code and created a `frankenstein` branch in my personal `opm-output` github fork.
2016-09-12 16:28:44 -05:00
{
WellMap wmap;
Use new well implementation Well2 from opm-common
2019-05-02 05:51:25 -05:00
for (const auto& w : wells)
fix some serious screw-ups almost all of them were caused by recent changes in the master branch: - there were methods added which depend on the types `V` and `DataBlock`. these do not make much sense in the context of the frankenstein simulator. Also, these types are defined globally for the whole Opm namespace in `BlackoilModelBase_impl.hpp` (which should be prosecuted as a fellony IMO)! Besides this, their names are useless; 'V' is the letter which comes after `U` in the alphabet and when it comes to computers basically everything can be seen as a chunk of data (i.e., a `DataBlock`). - it seems like the new and shiny dense-AD based well model was never compiled with assertations enabled, at least some asserts referenced non-existing variables. - the recent output-related API changes were pretty unfortunate because they had the effect of tying the (sub-optimal, IMO) internal structure of the model even closer to the output code: as far as I can see, `rq` does only make sense if the model works *exactly* like BlackoilModelBase and friends. (for flow_ebos, this could be replicated, but first it would be another unnecessary conversion step and second, most of the quantities in `rq` are of type `ADB` and much of the "frankenstein" excercise is devoted to getting rid of these.) I thus reverted back to an old version of the output code and created a `frankenstein` branch in my personal `opm-output` github fork.
2016-09-12 16:28:44 -05:00
{
Use new well implementation Well2 from opm-common
2019-05-02 05:51:25 -05:00
wmap.insert(std::make_pair(w.name(), w));
fix some serious screw-ups almost all of them were caused by recent changes in the master branch: - there were methods added which depend on the types `V` and `DataBlock`. these do not make much sense in the context of the frankenstein simulator. Also, these types are defined globally for the whole Opm namespace in `BlackoilModelBase_impl.hpp` (which should be prosecuted as a fellony IMO)! Besides this, their names are useless; 'V' is the letter which comes after `U` in the alphabet and when it comes to computers basically everything can be seen as a chunk of data (i.e., a `DataBlock`). - it seems like the new and shiny dense-AD based well model was never compiled with assertations enabled, at least some asserts referenced non-existing variables. - the recent output-related API changes were pretty unfortunate because they had the effect of tying the (sub-optimal, IMO) internal structure of the model even closer to the output code: as far as I can see, `rq` does only make sense if the model works *exactly* like BlackoilModelBase and friends. (for flow_ebos, this could be replicated, but first it would be another unnecessary conversion step and second, most of the quantities in `rq` are of type `ADB` and much of the "frankenstein" excercise is devoted to getting rid of these.) I thus reverted back to an old version of the output code and created a `frankenstein` branch in my personal `opm-output` github fork.
2016-09-12 16:28:44 -05:00
}
return wmap;
}
inline void
historyRates(const PhaseUsage& pu,
Rename Well2 -> Well and Group2 -> Group
2019-11-13 16:16:11 -06:00
const Well::ProductionControls& p,
fix some serious screw-ups almost all of them were caused by recent changes in the master branch: - there were methods added which depend on the types `V` and `DataBlock`. these do not make much sense in the context of the frankenstein simulator. Also, these types are defined globally for the whole Opm namespace in `BlackoilModelBase_impl.hpp` (which should be prosecuted as a fellony IMO)! Besides this, their names are useless; 'V' is the letter which comes after `U` in the alphabet and when it comes to computers basically everything can be seen as a chunk of data (i.e., a `DataBlock`). - it seems like the new and shiny dense-AD based well model was never compiled with assertations enabled, at least some asserts referenced non-existing variables. - the recent output-related API changes were pretty unfortunate because they had the effect of tying the (sub-optimal, IMO) internal structure of the model even closer to the output code: as far as I can see, `rq` does only make sense if the model works *exactly* like BlackoilModelBase and friends. (for flow_ebos, this could be replicated, but first it would be another unnecessary conversion step and second, most of the quantities in `rq` are of type `ADB` and much of the "frankenstein" excercise is devoted to getting rid of these.) I thus reverted back to an old version of the output code and created a `frankenstein` branch in my personal `opm-output` github fork.
2016-09-12 16:28:44 -05:00
std::vector<double>& rates)
{
Use InjectionControls and ProductionControls data classes
2019-05-21 00:31:54 -05:00
assert (! p.prediction_mode);
fix some serious screw-ups almost all of them were caused by recent changes in the master branch: - there were methods added which depend on the types `V` and `DataBlock`. these do not make much sense in the context of the frankenstein simulator. Also, these types are defined globally for the whole Opm namespace in `BlackoilModelBase_impl.hpp` (which should be prosecuted as a fellony IMO)! Besides this, their names are useless; 'V' is the letter which comes after `U` in the alphabet and when it comes to computers basically everything can be seen as a chunk of data (i.e., a `DataBlock`). - it seems like the new and shiny dense-AD based well model was never compiled with assertations enabled, at least some asserts referenced non-existing variables. - the recent output-related API changes were pretty unfortunate because they had the effect of tying the (sub-optimal, IMO) internal structure of the model even closer to the output code: as far as I can see, `rq` does only make sense if the model works *exactly* like BlackoilModelBase and friends. (for flow_ebos, this could be replicated, but first it would be another unnecessary conversion step and second, most of the quantities in `rq` are of type `ADB` and much of the "frankenstein" excercise is devoted to getting rid of these.) I thus reverted back to an old version of the output code and created a `frankenstein` branch in my personal `opm-output` github fork.
2016-09-12 16:28:44 -05:00
assert (rates.size() ==
std::vector<double>::size_type(pu.num_phases));
if (pu.phase_used[ BlackoilPhases::Aqua ]) {
const std::vector<double>::size_type
i = pu.phase_pos[ BlackoilPhases::Aqua ];
Use InjectionControls and ProductionControls data classes
2019-05-21 00:31:54 -05:00
rates[i] = p.water_rate;
fix some serious screw-ups almost all of them were caused by recent changes in the master branch: - there were methods added which depend on the types `V` and `DataBlock`. these do not make much sense in the context of the frankenstein simulator. Also, these types are defined globally for the whole Opm namespace in `BlackoilModelBase_impl.hpp` (which should be prosecuted as a fellony IMO)! Besides this, their names are useless; 'V' is the letter which comes after `U` in the alphabet and when it comes to computers basically everything can be seen as a chunk of data (i.e., a `DataBlock`). - it seems like the new and shiny dense-AD based well model was never compiled with assertations enabled, at least some asserts referenced non-existing variables. - the recent output-related API changes were pretty unfortunate because they had the effect of tying the (sub-optimal, IMO) internal structure of the model even closer to the output code: as far as I can see, `rq` does only make sense if the model works *exactly* like BlackoilModelBase and friends. (for flow_ebos, this could be replicated, but first it would be another unnecessary conversion step and second, most of the quantities in `rq` are of type `ADB` and much of the "frankenstein" excercise is devoted to getting rid of these.) I thus reverted back to an old version of the output code and created a `frankenstein` branch in my personal `opm-output` github fork.
2016-09-12 16:28:44 -05:00
}
if (pu.phase_used[ BlackoilPhases::Liquid ]) {
const std::vector<double>::size_type
i = pu.phase_pos[ BlackoilPhases::Liquid ];
Use InjectionControls and ProductionControls data classes
2019-05-21 00:31:54 -05:00
rates[i] = p.oil_rate;
fix some serious screw-ups almost all of them were caused by recent changes in the master branch: - there were methods added which depend on the types `V` and `DataBlock`. these do not make much sense in the context of the frankenstein simulator. Also, these types are defined globally for the whole Opm namespace in `BlackoilModelBase_impl.hpp` (which should be prosecuted as a fellony IMO)! Besides this, their names are useless; 'V' is the letter which comes after `U` in the alphabet and when it comes to computers basically everything can be seen as a chunk of data (i.e., a `DataBlock`). - it seems like the new and shiny dense-AD based well model was never compiled with assertations enabled, at least some asserts referenced non-existing variables. - the recent output-related API changes were pretty unfortunate because they had the effect of tying the (sub-optimal, IMO) internal structure of the model even closer to the output code: as far as I can see, `rq` does only make sense if the model works *exactly* like BlackoilModelBase and friends. (for flow_ebos, this could be replicated, but first it would be another unnecessary conversion step and second, most of the quantities in `rq` are of type `ADB` and much of the "frankenstein" excercise is devoted to getting rid of these.) I thus reverted back to an old version of the output code and created a `frankenstein` branch in my personal `opm-output` github fork.
2016-09-12 16:28:44 -05:00
}
if (pu.phase_used[ BlackoilPhases::Vapour ]) {
const std::vector<double>::size_type
i = pu.phase_pos[ BlackoilPhases::Vapour ];
Use InjectionControls and ProductionControls data classes
2019-05-21 00:31:54 -05:00
rates[i] = p.gas_rate;
fix some serious screw-ups almost all of them were caused by recent changes in the master branch: - there were methods added which depend on the types `V` and `DataBlock`. these do not make much sense in the context of the frankenstein simulator. Also, these types are defined globally for the whole Opm namespace in `BlackoilModelBase_impl.hpp` (which should be prosecuted as a fellony IMO)! Besides this, their names are useless; 'V' is the letter which comes after `U` in the alphabet and when it comes to computers basically everything can be seen as a chunk of data (i.e., a `DataBlock`). - it seems like the new and shiny dense-AD based well model was never compiled with assertations enabled, at least some asserts referenced non-existing variables. - the recent output-related API changes were pretty unfortunate because they had the effect of tying the (sub-optimal, IMO) internal structure of the model even closer to the output code: as far as I can see, `rq` does only make sense if the model works *exactly* like BlackoilModelBase and friends. (for flow_ebos, this could be replicated, but first it would be another unnecessary conversion step and second, most of the quantities in `rq` are of type `ADB` and much of the "frankenstein" excercise is devoted to getting rid of these.) I thus reverted back to an old version of the output code and created a `frankenstein` branch in my personal `opm-output` github fork.
2016-09-12 16:28:44 -05:00
}
}
} // namespace SimFIBODetails
} // namespace Opm
#endif // OPM_SIM_FIBO_DETAILS_HPP
Reference in New Issue Copy Permalink