PRISME PRS_D4.in fails

[drjfloyd]

PRISME PRS_D4.in starts running in cedit and then fails. It looks like maybe the new cedit is trying to open the output files as read/write rather than read only.

[rmcdermo]

Jason, having a hard time reproducing this. Could it be that you are in Program Files on the Windows machine and it will not let your write? I am opening the input file within a repo in my user directory. I'll go try Windows next.

[rmcdermo]

Things are also ok on Windows for me. Maybe we can jump on a call and walk through the flow you are using to hit this.

[mcgratta]

I ran the case with Windows and it worked. I downloaded the latest bundle.

[mcgratta]

If the code is choking on the TAIL line, I wonder if this involves an EOF or EOL?

[drjfloyd]

I am running out of the CFAST/Validation/PRISME folder. As you can see in the image it ran out to 350 s before it failed. Outputs are written every 10 s. If the issue was a directory permisison error, CFAST would have died before the first timestep when trying to write the file headers. The TAIL error may be a red herring of from the crash on the file read error. If I run CFAST from a prompt, where only CFAST is trying to access the files, it runs fine and there is no TAIL error. Error 46 is the file lock error. I am running the test bundle from 11 hours ago.

I tried it again just now and same issue.

[drjfloyd]

copilot is suggesting this which seems to be working:

    def poll_cfast_status(self):
        if self.cfast_status_path is None or not self.cfast_status_path.exists():
            return
        for qq in range(3):

           try:
               text = self.cfast_status_path.read_text(
                   encoding="utf-8",
                   errors="replace",
               ).strip()
           except PermissionError:
              time.sleep(0.01)
           except OSError:
               return
           text = self.cfast_status_path.read_text(encoding="utf-8",errors="replace",).strip()
        if not text:
            return

[mcgratta]

BTW, the error statements are written by CFAST. Look in cfastexit.f90.

[drjfloyd]

I pushed that up. It ran multiple times without issue, then tried one more time after pushing it up and it died but at a different time.

[rmcdermo]

I need to be able to reproduce this on our end to work on it. If the above did not fix it for good, probably better to have it dying early, I'd revert. I really don't know what that code is doing.

[drjfloyd]

I found a better approach that seems to be working.

[drjfloyd]

In the new approach if there is a permission error it returns. So there may be occasional skips in updating the screen log (which a user probably won't even notice) but CFAST won't crash out.

[mcgratta]

Even though CFAST ran from the command line, maybe we should clean up the I/O in the CFAST Fortran code itself. For example, do we need to explicitly delete files:

    cfastexit.f90

    subroutine delete_output_files (outputfile)

    character(len=*), intent(in) :: outputfile
    integer :: fileunit, ios
    logical doesthefileexist

    inquire (file=outputfile, exist=doesthefileexist)
    if (DoesTheFileExist) then
        open (newunit=fileunit, iostat=ios, file=outputfile, status='old')
        if (ios==0) then
            close(fileunit, status='delete', iostat=ios)
            if (ios/=0) then
                write (errormessage,'(a,i0,a)') 'Error opening output file, returned status = ', ios, &
                    '. File may be in use by another application.'
                call cfastexit('delete_output_files',1)
            end if
        end if
    end if

    return
    end subroutine delete_output_files