ert
ert copied to clipboard
equinor
Special treatment of RMS output file
It could be beneficial for debugging to be able to access the RMS log file from the ERT gui (details window).
Today, the stdout and stderr files are available, but most often it is another file that contains enough error trace to understand what went wrong. The filename to read is named along:
<RUNPATH>/rms/model/20200827-140324-u94993-RMS.log
most often determined by ls -ltra in rms/model. Not sure what the id after date and time represents.
This is a good idea. I think, however, that the solution to this problem should be general. I.e. there's a configuration directive that allows you to pick up this file for viewing in the GUI (or CLI) in certain conditions, or—the RMS job is programmed in such a way that it communicates to ERT that the file in question contains valuable information pertaining to an error.
We have introduced a Reporter that might come in handy. Our intention is to move this to ERT.
What do you think?
If RMS is not near the python interpreter, we're also planning to implement a Reporter REST API that could be utilized as well.
I agree with Jonas. But, I also think a much quicker win is to do something similar to what we did for Eclipse where we collect logs in our Python wrapper script and dump them to the standard location...
So, if we are able to predict the filename RMS writes to, in the RMS forward model code (before having launched RMS), there is a place we can submit the filename?
(Not sure yet how feasible it is though to predict or control that filename)
If we can predict this, we can crawl that file, dump it to the log-file of the job and hence have it available in the GUI...
Redirecting it to the stdout file is perhaps tricky, as it is already being filled with whatever RMS itself writes to stdout, and what external scripts (called from inside RMS) prints (f.ex xtgeo). How it looks interleaved in time I don't know.
The timestamp in the filename seems to be +2-3 secs compared to the RMS startup time in STATUS.
Yeah, but maybe we could prefix the lines to make it easier to deduce the relevance?
I don't think we should make a solution for RMS only and I'm not sure of the general usefulness of supporting multiple log files from the same job 🤷 Maybe the weekend grants us with some great ideas 💡
I am inclined to request an option to pipe the RMS log-file content over to the stdout file, in an interleaved fashion. Without any prefixing at first pass. I assume the determination of the filename is the crux - is the forward model infrastructure set up to do such a thing - in case it has to monitor the directory to figure out the exact filename?
Confirmed from Roxar that the character after the datetime specification in the filename are just there to ensure filename uniqueness.
As relevant as the filename with the timestamp is workflow.log. Where the relevant error message appears, depends on the nature of the error. workflow.log is HTML formatted and used inside the RMS gui when run interactive.
is the forward model infrastructure set up to do such a thing
This is a job for the Python script in libres wrapping around RMS! And it should very much be possible! 👍
Remember the name "workflow.log" is just a default name which the user can change, so don't hardcode that name. Also the log files with datastamp and workflow.log are not similar but overlapping. Perhaps a need to ask Roxar to clarify around these.
Do we have a clear path moving forward here @jcrivenaes and @berland? What is the logic for the file we would potentially be looking for here?
Remember the name "workflow.log" is just a default name which the user can change, so don't hardcode that name.
The name of the file is in the .master file, e.g.:
sed -n -e /^workflowname/p -e /^logfile/p <RMS_PROJECT>/.master | grep -A1 <RMS_WORKFLOW> | grep ^logfile
The plan is now to delegate handling of rms to rms-sys: https://github.com/equinor/ert/issues/7859 . I am closing this issue as we are not planning to solve it in ert, but atlas has been notified about this discussion and will take over the development of it.
