Overwriting Output Files

[zacharycope0]

Problem In my workflow, I run the QF executable directly w/out the bash script. If I run QF twice without deleting the previous output folder, I get the following error:

Solution My team would prefer if we reverted to the protocol from previous versions of QF, where QF would overwrite the old outputs. Is the LANL team ok with this?

[amarcozzi]

I typically run with rm-r Output/ && ./quicfire which prevents the error, but yes I agree that this is annoying. I think it makes more sense for QUIC-Fire to overwrite the data and it's a user's responsibility to manage their output files.

[sbrambilla]

No, because if you change any of the inputs, you'll still have the old binaries in the output folder.

[amarcozzi]

That makes sense, but that's what I mean by it the responsibility of a user to manage their output folder. If a user runs QUIC-Fire, then changes the inputs, and now has conflicting output binaries, then that is the responsibility of the user to remove the old binaries. At least that is my opinion.

Maybe a middle ground option is to throw a warning instead of an error if an Output directory exists at runtime?

I don't think that this is a big deal one way or another, but I do agree with Zach that it's annoying.

[iperezx]

Good to know that it is not just us. v5.1.1 is only giving this error when running a big uniform fuel ensemble (total = 945). But I do think this is user-space and if you have automation in place you will only have to think about it once.

It will suck that if it gets changed and we don't get notified which is part of my new issue about the changelog: https://github.com/QF-Error-Tracking/QFVD5/issues/14