foamMonitor complains when viewing solverinfo.dat files and creates a STDERR stream plus line colors are duplicated
Summary
foamMonitor complains when viewing solverinfo.dat files when it parses through and hits a solver name or converged column. It continues to do this as it is left running creating a continuous (periodic) STDERR stream to the terminal that you started it from. Additionally the plot generated sometimes places the y crossing coordinate of x at 1. This can result in the 'iter' data being the top line of the graph for example. Another issue is that colors are repeated in the graph so determining which line is which can be really confusing.
Steps to reproduce
Use foamMonitor to view a solverinfo.dat file.
Example case
#foamMonitor -l solverinfo.dat
"/tmp/tmp.aQL9YjCazQ" line 29: warning: Skipping data file with no valid points
"/tmp/tmp.aQL9YjCazQ" line 29: warning: Skipping data file with no valid points
"/tmp/tmp.aQL9YjCazQ" line 29: warning: Skipping data file with no valid points
"/tmp/tmp.aQL9YjCazQ" line 29: warning: Skipping data file with no valid points
"/tmp/tmp.aQL9YjCazQ" line 29: warning: Skipping data file with no valid points
"/tmp/tmp.aQL9YjCazQ" line 29: warning: Skipping data file with no valid points
Notice the duplication of colors. Also notice that the p_rgh iter line is missing. (See the correct graph below.)
What is the current bug behaviour?
There is no parsing to remove column data that is not relevant to gnuplot. The column data is parsed into a variable and is then used to construct a temp file that is input to gnuplot. As such bad lines are generated in the temp file that depends on gnuplot rejecting the line (and registering a complaint.) This originally created some confusion for me as I didn't know if this had to do with my results or other.
What is the expected correct behavior?
Ideally foamMonitor would not generate a STDERR stream. Additionally colors should not be repeated on the graphs as this makes it difficult to interpret results. Lastly it should not (in most cases) use the top horizontal line of the graph to place data.
Relevant logs and/or images
Environment information
- OpenFOAM version :2012
- Operating system :Debian 10 (Buster)
- Hardware info :AMD Ryzen 9 3900X 12-Core Processor, 64 GB ddr4
- Compiler :g++ 4:8.3.0-1,g++-8 8.3.0-6
Possible fixes
I have created a modification of foamMonitor that I believe addresses these issues. Below is an example gnuplot output:
I have changed the gnuplot text size, and line width to make things more legible which is likely a subject of taste. I have also made the default x crossing of the y axis at 10. The color palette is now 20 long so that each column of data is colored differently (at least as much as I could muster with the algorithm I found.) I have parsed out the solver and converged data with a case directive. This gets rid of the STDERR stream. Additionally I have added a startup echo that tells people what data columns are assigned to what colors. I have used the expr command which I know is not compatible with some shells but foamMonitor already was making use of expr. I am attaching a patch to the 2012 version of foamMonitor. I have only tested this with chtMultiRegionSimpleFoam and chtMultiRegionFoam. I don't know if different matrix solvers or different physics solvers structure their logs differently so I don't know if this will work for all cases. Different column headers can easily be added to the cases for parsing only good data to gnuplot. Within the code I have added comments to help identify my changes which may or may not be recommended as a diff makes it obvious but as I am new to software development this is what I thought made sense at the time. I know the comments will have to be modified and removed before any commit is completed (which I would be pleased to do.) Also I added an attribution line when it is run that I am aware is not standard OpenFOAM and I assume there is rules around any attribution.
I would be pleased to continue making any more changes required based on feedback so this is ready for a commit. (Additionally I suspect that gnuplot doesn't really like the '_' so I was contemplating parsing this out to see if this cleans things up a bit more and it seems the legend placement could potentially be optimized which I could spend a bit of time on if people see the value.)
Kind regards,