cleaning up some comments.

This commit is contained in:
Kai Bao 2017-10-03 16:25:51 +02:00
parent 6fb459a797
commit fc64d34bc2
2 changed files with 7 additions and 48 deletions

View File

@ -166,7 +166,9 @@ namespace Opm
using Base::index_of_well_;
using Base::number_of_phases_;
using Base::well_cells_; // TODO: are the perforation orders same with StandardWell or Wells?
// TODO: the current implementation really relies on the order of the
// perforation does not change from the parser to Wells structure.
using Base::well_cells_;
using Base::well_index_;
using Base::well_type_;
using Base::first_perf_;
@ -188,17 +190,6 @@ namespace Opm
// TODO: trying to use the information from the Well opm-parser as much
// as possible, it will possibly be re-implemented later for efficiency reason.
// indices of the gird blocks that segments locate at.
// TODO: the grid cell related to a segment should be calculated based on the location
// of the segment node.
// As the current temporary solution, the grid cell related to a segment determined by the
// first perforation cell related to the segment.
// when no perforation is related to the segment, use it outlet segment's cell.
// TODO: it can be a source of error
std::vector<int> segment_cell_;
// the completions that is related to each segment
// the completions's ids are their location in the vector well_index_, well_cell_
// This is also assuming the order of the completions in Well is the same with
@ -208,17 +199,8 @@ namespace Opm
std::vector<std::vector<int> > segment_perforations_;
// the inlet segments for each segment. It is for convinience and efficiency reason
// the original segment structure is defined as a gathering tree structure based on outlet_segment
// the reason that we can not use the old way of WellOps, which is based on the Eigen matrix and vector.
// TODO: can we use DUNE FieldMatrix and FieldVector.
std::vector<std::vector<int> > segment_inlets_;
// Things are easy to get from SegmentSet
// segment_volume_, segment_cross_area_, segment_length_(total length), segment_depth_
// segment_internal_diameter_, segment_roughness_
// outlet_segment_., in the outlet_segment, we store the ID of the segment, we will need to use numberToLocation to get
// their location in the segmentSet
// segment number is an ID of the segment, it is specified in the deck
// get the loation of the segment with a segment number in the segmentSet
int numberToLocation(const int segment_number) const;
@ -228,7 +210,6 @@ namespace Opm
mutable OffDiagMatWell duneB_;
mutable OffDiagMatWell duneC_;
// diagonal matrix for the well
// TODO: if we decided not to invert it, we better change the name of it
mutable DiagMatWell duneD_;
// residuals of the well equations
@ -236,8 +217,6 @@ namespace Opm
// the values for the primary varibles
// based on different solutioin strategies, the wells can have different primary variables
// TODO: should we introduce a data structure for segment to simplify this?
// or std::vector<std::vector<double> >
mutable std::vector<std::array<double, numWellEq> > primary_variables_;
// the Evaluation for the well primary variables, which contain derivativles and are used in AD calculation
@ -258,7 +237,6 @@ namespace Opm
std::vector<std::vector<double> > segment_comp_initial_;
// the densities of segment fluids
// TODO: if it turned out it is only used to calculate the pressure difference,
// we should not have this member variable
std::vector<EvalWell> segment_densities_;
@ -312,8 +290,7 @@ namespace Opm
// convert a Eval from reservoir to contain the derivative related to wells
EvalWell extendEval(const Eval& in) const;
// compute the densities of the mixture in the segments
// TODO: probably other fluid properties also.
// compute the fluid properties, such as densities, viscosities, and so on, in the segments
// They will be treated implicitly, so they need to be of Evaluation type
void computeSegmentFluidProperties(const Simulator& ebosSimulator);

View File

@ -40,12 +40,8 @@ namespace Opm
, segment_mass_rates_(numberOfSegments(), 0.0)
, segment_depth_diffs_(numberOfSegments(), 0.0)
{
// TODO: to see what information we need to process here later.
// const auto& completion_set = well->getCompletions(time_step);
// const auto& segment_set = well->getSegmentSet(time_step);
// since we decide to use the SegmentSet from the well parser. we can reuse a lot from it.
// other facilities needed we need to process them here
// for other facilities needed but not available from parser, we need to process them here
// initialize the segment_perforations_
const CompletionSet& completion_set = well_ecl_->getCompletions(current_step_);
@ -62,7 +58,6 @@ namespace Opm
const int segment_number = segment.segmentNumber();
const int outlet_segment_number = segment.outletSegment();
if (outlet_segment_number > 0) {
// TODO: to make sure segment_location == seg here
const int segment_location = numberToLocation(segment_number);
const int outlet_segment_location = numberToLocation(outlet_segment_number);
segment_inlets_[outlet_segment_location].push_back(segment_location);
@ -74,17 +69,11 @@ namespace Opm
for (int seg = 0; seg < numberOfSegments(); ++seg) {
const double segment_depth = segmentSet()[seg].depth();
for (const int perf : segment_perforations_[seg]) {
// TODO: what kind of depth actually we get from the Wells struct?
// TODO: not sure whether to use the one from opm-parser or the one from Wells struct
// TODO: use the one from the opm-parser first
// TODO: checking wehther the order of the perforation changed or not
perf_depth_[perf] = completion_set.get(perf).getCenterDepth();
perforation_segment_depth_diffs_[perf] = perf_depth_[perf] - segment_depth;
}
}
// TODO: should we store the depth of the perforations?
// calculating the depth difference between the segment and its oulet_segments
// for the top segment, we will make its zero unless we find other purpose to use this value
for (int seg = 1; seg < numberOfSegments(); ++seg) {
@ -201,7 +190,6 @@ namespace Opm
resWell_.resize( numberOfSegments() );
// TODO: maybe this function need a different name for better meaning
primary_variables_.resize(numberOfSegments());
primary_variables_evaluation_.resize(numberOfSegments());
}
@ -358,9 +346,6 @@ namespace Opm
updateWellStateWithTarget(const int current,
WellState& well_state) const
{
// TODO: it can be challenging, when updating the segment and perforation related,
// well rates needs to be okay.
// Updating well state bas on well control
// Target values are used as initial conditions for BHP, THP, and SURFACE_RATE
const double target = well_controls_iget_target(well_controls_, current);
@ -473,9 +458,7 @@ namespace Opm
// update, so that the compositon inside the wellbore will be preserved.
//
//
// Or we might just update the segment rates directly without changing the perforation rates?
//
// Or we check our old way of the old MultisegmentWells implementation.
// It is just difficult to initialize the segment rates without initializing the perforation rates.
{
for (int phase = 0; phase < number_of_phases_; ++phase) {
const double perf_phaserate = well_state.wellRates()[number_of_phases_ * index_of_well_ + phase] / number_of_perforations_;
@ -659,7 +642,6 @@ namespace Opm
MultisegmentWell<TypeTag>::
updatePrimaryVariables(const WellState& well_state) const
{
// TODO: not tested yet.
// TODO: not handling solvent or polymer for now.
// TODO: to test using rate conversion coefficients to see if it will be better than
@ -1182,7 +1164,7 @@ namespace Opm
// injecting connections total volumerates at standard conditions
EvalWell cqt_is = cqt_i / volume_ratio;
for (int comp_idx = 0; comp_idx < num_comp; ++comp_idx) {
cq_s[comp_idx] = cmix_s[comp_idx] * cqt_is; // // TODO: checking there * b_perfcells[phase];
cq_s[comp_idx] = cmix_s[comp_idx] * cqt_is;
}
} // end for injection perforations
}