OPM
Fixed well status control with Python
Fixes for the issues reported on: https://github.com/OPM/opm-simulators/issues/4810 https://github.com/OPM/opm-simulators/issues/4813
Now the new code can shut or open the well correctly from the python code.
If we really want to support controlling wells from Python then we need to do something other than what's being proposed here. Although I did not write this function, my impression is nevertheless that the
Schedule::updateWellStatus()function is geared towards handling status updates from control keywords likeWELOPENandWCONPRODwith very little thought given to direct calls from Python.
The question is if this moves us towards the long-term goal of being able to manipulate wells and schedule from Python in a flexible manner. In the meantime, addressing open bugs is good?
If we really want to support controlling wells from Python then we need to do something other than what's being proposed here. Although I did not write this function, my impression is nevertheless that the
Schedule::updateWellStatus()function is geared towards handling status updates from control keywords likeWELOPENandWCONPRODwith very little thought given to direct calls from Python.The question is if this moves us towards the long-term goal of being able to manipulate wells and schedule from Python in a flexible manner
True, but it's not clear to me that this particular proposal does that because the interactions in this part of the code are obtuse at best.
In the meantime, addressing open bugs is good?
Absolutely. Still, the regression failures from this PR are such that there's more work needed before the code is suitable for inclusion into the simulator.
Sorry for the late reply. I first explain what I found and what I did.
From the example of the technical manual and the OPM-manual that it shows that we can use the pyaction to control the well from the python function like schedule.shut_well.
However the actual actual situation is the simulation will run before the well status changed If there are not more than multiple iterations in one report step. In this way, the final result often does not achieve the result of the state change. For example, I set the parameter to close the well when it is less than a certain number, but the result always does not show the effect of closing the well.
What I mainly do is to change the state of the well in the next report step after getting the instruction to change the well in the current report step. And yes, the code is a bit rudimentary now and I need to do more work
What I mainly do is to change the state of the well in the next report step after getting the instruction to change the well in the current report step.
Right. For what it's worth, our Schedule is structured around shared_ptr<>s to simulation objects–wells, groups, networks, &c. As a result, there could be quite a few follow-on report steps that use the same simulation object and if you want to propagate a state change, you will have to do so to all of them. Calling Well::update() from a call site triggered by Python is not sufficient to affect the desired state change and we need a much more comprehensive way to influence state of the simulator if we're really want to support doing what I think you want.
From the example of the technical manual and the OPM-manual that it shows that we can use the pyaction to control the well from the python function like schedule.shut_well.
Yes, and that was the goal of PYACTION, but the reality is that we've not maintained that code in light of other work and now there's probably quite a bit of work to restore the functionality.
What I mainly do is to change the state of the well in the next report step after getting the instruction to change the well in the current report step.
Right. For what it's worth, our
Scheduleis structured aroundshared_ptr<>s to simulation objects–wells, groups, networks, &c. As a result, there could be quite a few follow-on report steps that use the same simulation object and if you want to propagate a state change, you will have to do so to all of them. CallingWell::update()from a call site triggered by Python is not sufficient to affect the desired state change and we need a much more comprehensive way to influence state of the simulator if we're really want to support doing what I think you want.From the example of the technical manual and the OPM-manual that it shows that we can use the pyaction to control the well from the python function like schedule.shut_well.
Yes, and that was the goal of
PYACTION, but the reality is that we've not maintained that code in light of other work and now there's probably quite a bit of work to restore the functionality.
Ah understand. Yes for the pyaction part and the well status part, a bit of work should to do. Thanks for your suggestion, I will try to make a more comprehensive code for this part.