for some of these files this is needed to make to keep it compiling
after the next patch because the new ErrorMacros.hpp file will no
longer implicitly includes <iostream>. for the remaining files it is
just good style.
While at it, the includes for most of these files have been ordered in
order of decreasing abstraction level.
our policy is that we only use boost if necessary, i.e., if the oldest
supported compiler does not support a given feature but boost
does. since we recently switched to GCC 4.4 or newer, std::shared_ptr
is available unconditionally.
Do not use the well's comp_frac member, only rely on the control's distr
member for initialization. This forced a change to WellsManager's
initialization of the distr member.
Specifically, the tests
if (!wells->type[self_index] == INJECTOR)
if (!wells->type[self_index] == PRODUCER)
produced the expected results *only* because INJECTOR==0 and PRODUCER==1
in the WellType enumeration, thus (!INJECTOR == PRODUCER) and
(!PRODUCER == INJECTOR).
Installing the (much) more appropriate
if (wells->type[self_index] != INJECTOR)
if (wells->type[self_index] != PRODUCER)
is not only more readable, it is also future-proof and scales better if
we ever introduce new WellTypes (e.g., a MONITOR).
It complains about not finding a match for the pair<> template class,
because the first parameter (this) is allegedly const. However, this
isn't a const method, so I suspect it is a compiler bug.
In order to move on, I slap on a harmless cast which will make this
particular compiler happy, and which should have no effects elsewhere,
but put it in a #if..#else..#endif macro to avoid warnings on others;
hopefully this also makes it easier to spot and remove in the future.
In the Wells struct, production rate control targets must be negative
(and injection rate control targets are always positive).
In the WellsGroup classes, there are separate variables for injection
and production, and all rates are positive. Therefore, upon adding or
modification of a production rate control, the negated value must
be used.
This installs a measure of safety on the part of the interface in that
the caller is free to dispose of the wells object upon returning from
the WellsManager constructor.
Now you can actually shut and open wells with WELOPEN. The following
caveats apply:
- this may interact improperly with group controls,
- dynamic usage of WCONINJE/WCONPROD should not be mixed with WELOPEN.
