IO Bug Fix

[feathern]

This fixes a subtle bug in Rayleigh. When opening a file for parallel I/O, Rayleigh records the error code. It was intended that if a nonzero error code was found, so that the file_open variable remained false, no subsequent file operations would be performed. A check on the file_open variable was missing, however, for everything but the operations related to writing the file header data. This PR fixes this bug.

I've been emailing with @illorenzo7 and the NASA HECC staff about this already today, so I'm assigning the review to him.

-Nick

p.s. I also removed a commented line of debugging code.

[illorenzo7]

@feathern This looks good, and I am starting to understand some of the issues my job experienced today (i.e., unable to open a file from disk but Rayleigh still was trying to write to that file). One question: in our conversation with Johnny you said the error was "due to an 'if' statement that didn't include all of the code meant to be contained in the conditional." But here you made a new if block. Is there a reason 781-783 can't be included in the prior if-block (which also has the "responsible" variable)?

[feathern]

It's not actually the same conditional. One is (responsible and file_open), while the other is just (file_open). The "responsible" node writes the header information (timestep, time, record number) for the record, so we don't want all processors doing it. Also, I'm really just trying to patch something problematic quickly right now -- we need to work on various aspects of this at the hackathon (such as the 'wait' feature we discussed).
-Nick

[illorenzo7]

Sounds good! Mainly I was just curious, I figured the separate blocks were intentional. Merging.