Automatically flush eplusout.err if running in DEBUG mode or if env var DeveloperFlag=TRUE is passed

[jmarrec]

Pull request overview

Description of the purpose of this PR

Regarding eplusout.err, I often want to see the content up to a segfault: if segfaulting, the final flush is never happening. Or just see the content while the simulation is running (slowly, in Debug).

I'd like to make it so that at least when building in Debug mode, the err_stream flushes on each write.

I'd personally argue that in 99.5% of cases, the amount of IO happening in eplusout.err is minimal and it wouldn't hurt to do it even in Release mode. Users could actually report the content up to a segfault when opening an issue, which would be useful for us. But it's not necessarily a battle I want to fight, so I took an alternative approach of doing it in Release Mode only if environment variable DeveloperFlag=TRUE.

Pull Request Author

• Title of PR should be user-synopsis style (clearly understandable in a standalone changelog context)
• Label the PR with at least one of: Defect, Refactoring, NewFeature, Performance, and/or DoNoPublish
• Pull requests that impact EnergyPlus code must also include unit tests to cover enhancement or defect repair
• Author should provide a "walkthrough" of relevant code changes using a GitHub code review comment process
• If any diffs are expected, author must demonstrate they are justified using plots and descriptions
• If changes fix a defect, the fix should be demonstrated in plots and descriptions
• If any defect files are updated to a more recent version, upload new versions here or on DevSupport
• If IDD requires transition, transition source, rules, ExpandObjects, and IDFs must be updated, and add IDDChange label
• If structural output changes, add to output rules file and add OutputChange label
• If adding/removing any LaTeX docs or figures, update that document's CMakeLists file dependencies

Reviewer

• Perform a Code Review on GitHub
• If branch is behind develop, merge develop and build locally to check for side effects of the merge
• If defect, verify by running develop branch and reproducing defect, then running PR and reproducing fix
• If feature, test running new feature, try creative ways to break it
• CI status: all green or justified
• Check that performance is not impacted (CI Linux results include performance check)
• Run Unit Test(s) locally
• Check any new function arguments for performance impacts
• Verify IDF naming conventions and styles, memos and notes and defaults
• If new idf included, locally check the err file and other outputs

[jmarrec]

here

[jmarrec]

And document it

[Myoldmopar]

This is perfectly fine as it is, although I will say I wouldn't mind it just always being flushed. I appreciate your hesitation to make that change, @jmarrec , but I will ask the audience -- is there anyone who actually feels strongly that we should hold off writing to the err file? The ability to debug user issues without having to do special arrangements seems to be worth the milliseconds of writing time alone.

[jasondegraw]

This is perfectly fine as it is, although I will say I wouldn't mind it just always being flushed. I appreciate your hesitation to make that change, @jmarrec , but I will ask the audience -- is there anyone who actually feels strongly that we should hold off writing to the err file? The ability to debug user issues without having to do special arrangements seems to be worth the milliseconds of writing time alone.

@Myoldmopar Given our history of disk thrashing, I'd be against unbuffering the err file by default unless it can be shown (or someone does some testing to show) that it doesn't have an impact in areas where disk I/O was an issue (e.g., HPC).

[rraustad]

I don't have an opinion other than wanting to see more information. If there is a crash there will be missing information. I typically see blank err files.

[Myoldmopar]

I'm going to modify this PR slightly. I am going to add a new environment variable that specifically handles ERR file flushing without affecting all the other developer flag stuff. Now the question is, what do we default?

My gut says that the typical user wants the error file emitted right away. They do not like the shock of an empty error file after the shock of a crash. That's a bad look. And then after they ask for support, we tell them they have to re-run it with an environment variable set to see the error just to get info to us. Also, I think pretty much every interface will want this enabled. So if we default to the current behavior, then every interface developer will have to rebuild their tool to add the environment variable when it executes EnergyPlus.

I think the primary reason anyone would actually want the current behavior is what @jasondegraw mentioned above. It's a fully valid reason to want it buffered if you are churning out thousands of runs on an HPC cluster. But my gut tells me that in these cases, the person setting up the workflow is much more capable of setting an environment variable than everyone on the range of users of EnergyPlus.

My vote would be to turn this new behavior by default, but allow it to go back to previous behavior with the environment variable. I would name it something like BUFFERED_ERR_FILE. I think this is highly supportive of the entire userbase, and will provide less shock to the typical user, and our interface stakeholders will be happy to get ERR output without having to modify their code.

[nrel-bot-2c]

@jmarrec @Myoldmopar it has been 28 days since this pull request was last updated.