Repository navigation
Document UDQ support in PYACTION - #40
panasun1994 wants to merge 2 commits into
Conversation
|
@SoilRos, this is the documentation for UDQ support. Please review it. |
| ---------------------------------------------- | ||
|
|
||
| The ``UDQ`` keyword can be inserted from a PYACTION script. These features are supported | ||
| in both serial and parallel runs: |
There was a problem hiding this comment.
Is there any difference between serial and parallel runs for pyaction? If not, I would exclude this sentence. If yes, we need to explain the difference.
There was a problem hiding this comment.
In the view of the user, I think it is the same... at least both serial and parallel provide the same result. The difference is (also what I concern) is that the parallel run writes the insert UDQ variable once per rank (say you have 4 similar variables for 4 rank) but only rank 0 writes the summary. My experience is still not enough to find a case where you can have different values of the same variable across ranks. But as far as I know, it does not make sense; i.e., the case does not exist.
Anyway, I will remove the sentence These features are supported in both serial and parallel runs because it just tells the user that we tested it, nothing more.
| schedule = opm_embedded.current_schedule | ||
|
|
||
| # Run the insertion only once | ||
| if 'setup_done' not in globals(): |
There was a problem hiding this comment.
What happens when the user has more than one pyaction? Is this variable shared among all python scripts or is there one for each one? If there is only one globally, we need to be careful to advertise this generic variable name as it would only be initialized by the first script.
There was a problem hiding this comment.
That is a very interesting point. I already tested it. The test result says that every pyaction has its own global step_done. Let's say you have action_a.py and action_b.py. If action_a.py fires first, then we have done = true. After that, check step_done in action_b.py; it is still false.
Should I have to add anything about this to the document?
There was a problem hiding this comment.
@SoilRos. I investigated whether this is the intention or a bug. The commit of Joakim in 2020. He said, "The purpose of this dictionary is to allow PYACTION scripts to store state between invocations". Claude found it.... In addition, the code in PyRunModule.cpp also shows that each Python script has its own namespace. Each script is imported by py::module::import(file name) and globals() in Python is a dictionary of the module that the code is in.
As I said before, this structure makes sense because the execution of script a.py should not immediately be the reason to stop the execution of b.py.
So, I will find the place to write this note. Still not sure where, because I think it is a topic outside UDQ.
There was a problem hiding this comment.
I think it should be another pull request because it is a topic outside UDQ. What do you think @SoilRos
|
|
||
| .. warning:: | ||
|
|
||
| The well name ``'?'`` (for example ``ASSIGN WU_Q '?' 7 /``) is **not supported yet**. |
There was a problem hiding this comment.
Is this a warning for the schedule or for the summary? Its position seems to make it as a warning for inserting quantities to the summary, but the contents show the scheduler.
There was a problem hiding this comment.
It is C++ error and Python pass it back as a runtime error.
After adding the valid keyword in PR#5500 and creating the test in PR#7581, here is the first documentation of UDQ support. Note that this documentation assumes that PR#7581, PR#5500, and PR#1673 have been merged into master. The links to
PYACTION_UDQ_INSERT_KW.DATA,pyaction_udq_insert_kw.pyandACTIONX_UDQ_INSERT_KW.DATAneed one more opm-tests PR, which I will open and link here.Another note: In the code block for Inserting UDQ keywords. the body of
ifis not related to the condition; this because the keywordASSIGN WU_X '?'is still not supported yet. So, I use a named well,ASSIGN WU_FLAG 'OP01' 5, instead.