ParmParse:addFile: User-Friendly Error

[ax3l]

Summary

If a file added via ParmParse:addFile does not exist, we did not yet receive a user-friendly error message. This fixes this in a way that does not hammer the file system from all MPI ranks.

Additional background

Follow-up to #2842 #2936 #3440

X-ref: ECP-WarpX/WarpX#5283 ECP-WarpX/impactx#704

Checklist

The proposed changes:

• fix a bug or incorrect behavior in AMReX
• add new capabilities to AMReX
• changes answers in the test suite to more than roundoff level
• are likely to significantly affect the results of downstream AMReX users
• include documentation in the code and/or rst files, if appropriate

[WeiqunZhang]

I thought it's going to say something like Couldn't open file: xxxx. Is that a python thing that the error message gets lost? Or is it you want ParmParse::addFile to be explicitly mentioned (instead of looking it up in Backtrace files)?

Anyway there is a function called amrex::FileExists that you can use. Also do we need bcast the information and print on all processes? If the I/O process aborts, it will abort other processes too.

[WeiqunZhang]

So it could just

if (ParallelDescriptor::IOProcessor()) {
    AMREX_ALWAYS_ASSERT_WITH_MESSAGE(FileExists(filename), "xxxxxx");
}

[ax3l]

Thanks! Yes the error message I got so far looks not as clean as it could be.

If we do the check & abort inside an if(IOProc) then technically another MPI process could front-run the check and maybe obfuscate the error message again at scale (or even trigger abort before the clear error messsage is thrown). The BCast is a bit safer... What do you think?

[AlexanderSinn]

To prevent other errors later, a barrier should be enough.

[WeiqunZhang]

There is already a barrier after this in reading and bcast the file, which also produce Couldn't open file: xxxx if I/O fails.

[WeiqunZhang]

My point is the fewer lines of code, the better, unless the code is hard to read.