Feature Request: Add option to completely disable report file generation

[dogganon]

Issue overview

Sometimes EnergyPlus needs to be run continuously in an automated environment (e.g. offline reinforcement learning simulation server); writing unsolicited files in such scenario is wasteful and can have side effects (e.g. accidental overwrite/deletion, IO overhead, disk wear and tear). Hence, it would be extremely helpful to have an option to disable file generation (thus any kind of disk writes) completely altogether.

Details

One way to approach this would be to add relevant logic in src/EnergyPlus/SimulationManager.cc to disable report function calls. But if anyone has any better ideas feel free to comment below or create a PR.

Checklist

• Pull request created (the pull request will have additional tasks related to reviewing changes that fix this defect)

[shorowit]

I thought that all outputs can be disabled using the OutputControl:Files object. If any output files aren't covered by that, they probably should.

[dogganon]

@shorowit The output behavior should be overridable by users in the CLI/API. The input file should not have full control over the output in the first place, particularly in the API, where automatic file generation in most cases is undesired. When people use the API they intend to use it as a library and assume full control over its outputs.

[jmarrec]

If people use the API, they also can just inject or modify the OutputControl:Files unique object in the IDF before simulating it. If you're intending to continuously run the same simulation to train a model, the overhead of adding it once is absolutely trivial.

I'm not a fan of duplicating ways of setting runtime behavior (CLI, Input Files, etc). It's annoying to maintain, and can get confusing.

The input file should not have full control over the output in the first place

I tend to disagree with that statement:

• it's explicit: it's stored inside the file which means if you look at results in the future you know all of the necessary inputs/conditions that lead to them.
• It's reproducible, meaning if I share the file with anyone they will run it exactly the same way as I did, not relying on undocumented CLI invocations/params.

That being said, there is one precedent for CLI parameters overriding IDF objects: --design-day / --annual.

(That's just my two cents, I'm not saying this isn't something we shouldn't do, if people generally see a net benefit for it)

[dogganon]

@jmarrec Except those output files are auxiliary and mostly just logs no? My personal opinion is that business logic should be separate from functional logic. If the runtime does not rely on those files for the simulation functionality what's the point of defining them in a simulation "model," which is supposed to only control simulations on a functional level?

they also can just inject or modify the OutputControl:Files unique object in the IDF before simulating it.

Right now the only way to do it is to open the IDF, modify it, save it to another file on disk, and ask the EnergyPlus API to load it. I need a fully programmatic solution. If it's possible to manipulate the IDF in memory maybe it's worth considering. But creating a separate file for such a trivial thing is not sustainable in the long run.

It's annoying to maintain

Then maybe implement things like OutputProcessor as plugins? I am all for a modular design.