Mesh check error printout

[hajdik]

Purpose

This changes the logic for error printouts for boundary condition checks and topology errors so all errors present in the mesh will print out.

These checks are:

• Boundary condition specified on something that isn't a physical boundary
• Corner topology error
• Node topology error
• Missing boundary condition for corner node

The previous behavior was to exit when the first issue arose, making it hard to fix multiple errors at once. Now if one or more errors is found the original error message prints out for each and then after everything is checked a general error is printed and pyHyp exits with relevant information, either:
ERROR: pyHyp exited due to one or more issues with mesh boundary conditions. See above error printouts. or
ERROR: pyHyp exited due to one or more issues with mesh topology. See above error printouts.

I also changed the printout that shows up at the start of a case. Originally it printed the case name as the name of the input file, but when running pyHyp with patch input there's no input file. I changed this to print the output file when there isn't an input file.

Expected time until merged

None

Type of change

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (non-backwards-compatible fix or feature)
• Code style update (formatting, renaming)
• Refactoring (no functional changes, no API changes)
• Documentation update
• Maintenance update
• Other (please describe)

Testing

Run this with a broken mesh to see if all expected errors are printed out

Checklist

• I have run flake8 and black to make sure the Python code adheres to PEP-8 and is consistently formatted
• I have formatted the Fortran code with fprettify or C/C++ code with clang-format as applicable
• I have run unit and regression tests which pass locally with my changes
• I have added new tests that prove my fix is effective or that my feature works
• I have added necessary documentation

[codecov]

Codecov Report

Attention: Patch coverage is 75.00000% with 1 line in your changes missing coverage. Please review.

Project coverage is 79.24%. Comparing base (ba26b6e) to head (6031b0b).
Report is 1 commits behind head on main.

Files	Patch %	Lines
pyhyp/pyHyp.py	75.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #81      +/-   ##
==========================================
- Coverage   79.48%   79.24%   -0.24%     
==========================================
  Files           4        4              
  Lines         424      424              
==========================================
- Hits          337      336       -1     
- Misses         87       88       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[sseraj]

This needs some minor fixes and formatting with fprettify

[eirikurj]

From what I can tell, this looks good overall, although I dont have a case to test this. Just a few minor comments.

[eirikurj]

Sorry for the delay, couple of additional comments. BTW, do you have a mesh that we can add as tests that catch these cases?

[eirikurj]

Sorry for the delay, couple of additional comments. BTW, do you have a mesh that we can add as tests that catch these cases? Would also be good to add printout to the PR description. Create #92 to track that we should update to mpi_abort at some point.

[hajdik]

Do you have a mesh that we can add as tests that catch these cases?

I think I could find one that captures one of the errors somewhere in my computer backup but it's ~800k cells, probably too big for the tests. I never had a mesh that would trip all of the errors at once.

Would also be good to add printout to the PR description.

Are you saying to add the text that I added for the error printout so it's documented here?

[eirikurj]

Wow, if the input meshes are this large, then yes this is way too big. I was hoping for something manageable to improve testing. Right, triggering everything with an actual mesh is probably not realistic, and we probably need to do this in smaller pieces, or manufacture something. Ideally, we should unittests this, although this will take a lot more effort. Given that this is not a runtime critical application, I am approving for now. But if you have other ideas, feel free to create an issue or update this PR.

Are you saying to add the text that I added for the error printout so it's documented here?

Yes, I was just thinking of some type of documentation here as to what is expected as I dont have anything to run this with.

[gawng]

These changes look good and help with more informative error messages, but I do agree there ought to be some sort of small mesh test down the line to trigger these error messages though it is not critical.