output_partial_domain for post-processing

[ChrisZYJ]

Description

Adds an option to output only part of the domain during post-processing.

Type of change

• New feature (non-breaking change which adds functionality)

Scope

• This PR comprises a set of related changes with a common goal

How Has This Been Tested?

• Works as expected when post-processed using Matlab binary reader.
• Passes the original tests with post-processing enabled (with -a)

Checklist

• I have added comments for the new code
• I added Doxygen docstrings to the new code
• I have made corresponding changes to the documentation (docs/)
• I have added regression tests to the test suite so that people can verify in the future that the feature is behaving as expected
• I have added example cases in examples/ that demonstrate my new feature performing as expected.
  They run to completion and demonstrate "interesting physics"
• I ran ./mfc.sh format before committing my code
• New and existing tests pass locally with my changes, including with GPU capability enabled (both NVIDIA hardware with NVHPC compilers and AMD hardware with CRAY compilers) and disabled
• This PR does not introduce any repeated code (it follows the DRY principle)
• I cannot think of a way to condense this code and reduce any introduced additional line count

[codecov]

Codecov Report

Attention: Patch coverage is 20.73171% with 65 lines in your changes missing coverage. Please review.

Project coverage is 44.70%. Comparing base (e4b8976) to head (c7bc283).

Files with missing lines	Patch %	Lines
src/post_process/m_data_output.fpp	0.00%	41 Missing ⚠️
src/post_process/m_start_up.f90	29.16%	17 Missing ⚠️
src/post_process/m_global_parameters.fpp	50.00%	6 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #768      +/-   ##
==========================================
- Coverage   44.72%   44.70%   -0.02%     
==========================================
  Files          62       62              
  Lines       17555    17599      +44     
  Branches     2044     2056      +12     
==========================================
+ Hits         7851     7868      +17     
- Misses       8439     8465      +26     
- Partials     1265     1266       +1     

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

[sbryngelson]

@ChrisZYJ thanks this appears very useful! I'm curious if this works for a couple different scenarios (have you verified):

• Serial vs serial output
• Format == 1 and 2
• Stretched grids

[ChrisZYJ]

It works with stretched grids and both serial and parallel outputs. However, it only works for format == 2 (binary) and not format == 1 (silo). The silo format requires more careful data handling, so perhaps that could be completed in another PR.

I've documented the scenarios where it doesn't work yet in the documentation and added prohibitions in the checkers.

[sbryngelson]

@ChrisZYJ thanks this makes sense. May I ask how you are handling your binary output files? Matlab/Python or into Visit/Paraview? I think this would be useful to either document or perhaps even put a helper script in the misc/ directory for others.

[ChrisZYJ]

I've been doing it in Matlab using the f_binary_reader.m function, which is already in the /misc directory. I could document it and add my wrapper function to /misc later if needed.

[sbryngelson]

Thanks @ChrisZYJ. I find using the binary files rather annoying. If we had a more broad way of doing it (and could suggest to the user when and how to do it) that would be useful.

I'm glad to merge the PR but we have two big PRs that are very near merging that I don't want to disrupt. Hopefully can merge this in a couple days.

[ChrisZYJ]

Yeah, I also find binary files quite cumbersome to work with. While I'm not sure what a broader way to handle them would be, I can add some documentation and helper scripts in another PR if you find those helpful.

I'm in no hurry to merge. This PR should be quite independent from everything else, and I could easily merge it into them later if needed.

[sbryngelson]

Yeah, I also find binary files quite cumbersome to work with. While I'm not sure what a broader way to handle them would be, I can add some documentation and helper scripts in another PR if you find those helpful.

I'm in no hurry to merge. This PR should be quite independent from everything else, and I could easily merge it into them later if needed.

That would be very useful indeed. I hope to merge this soon but don't want to risk messing up these larger long-standing PRs right now.