Added function to get block info

[sseraj]

Purpose

I made a few changes mostly related to retrieving block information in Python:

• added a function called getBlockInfo that returns a dictionary of the block information
• refactored printBlockInfo to use getBlockInfo
• added a test for getBlockInfo
• converted some other tests to use BaseRegTest

Related PR on pyHyp: mdolab/pyhyp#52

Type of change

What types of change is it?
Select the appropriate type(s) that describe this PR

• 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

Explain the steps needed to test the new code to verify that it does indeed address the issue and produce the expected behavior.

Checklist

Put an x in the boxes that apply.

• I have run flake8 and black to make sure the code adheres to PEP-8 and is consistently formatted
• 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

[marcomangano]

Looks good! Just to double check, did you verify that the block info from the reference mesh is consistent with the grid file?

[sseraj]

Looks good! Just to double check, did you verify that the block info from the reference mesh is consistent with the grid file?

I had checked that the block info after these changes are the same as before the changes. I now just counted the block dimensions in Tecplot and the number themselves look correct

[codecov]

Codecov Report

❗ No coverage uploaded for pull request base (master@cc29c74). Click here to learn what that means.
The diff coverage is n/a.

❗ Current head cf97c26 differs from pull request most recent head ceb1928. Consider uploading reports for the commit ceb1928 to get more accurate results

@@            Coverage Diff            @@
##             master      #43   +/-   ##
=========================================
  Coverage          ?   12.76%           
=========================================
  Files             ?        3           
  Lines             ?     2202           
  Branches          ?        0           
=========================================
  Hits              ?      281           
  Misses            ?     1921           
  Partials          ?        0           

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update cc29c74...ceb1928. Read the comment docs.

[ewu63]

@joanibal could you take a look when you have a chance? There are 2 other PRs waiting on this so it'd be good to get this in.

[eirikurj]

Overall, this is fine, just a few comments. Based on the response, I might push some minor updates if that is ok.
@nwu63 mentioned that there are couples of PRs waiting on this, but there is only one linked here. What is the second one?

[ewu63]

@nwu63 mentioned that there are couples of PRs waiting on this, but there is only one linked here. What is the second one?

The second one is mdolab/pyhyp#48, which will finally show coverage after we switch to using BaseRegTest (and remove the os.system calls).

[sseraj]

Feel free to push changes. I think we should converge on the pyHyp tests before merging this though in case any other changes have to be made.

[joanibal]

I'm not a fan of this pattern. I'd rather have just one test, but that seem like a bigger issue than just this PR

[sseraj]

I think it makes sense to have separate tests for each function because then it is easy to see what is broken if the test fails. I don't like having a separate train function and ref file for each test though.

[ewu63]

What's left to be done here @sseraj?

[sseraj]

What's left to be done here @sseraj?

I'm converting this to a draft until we settle on how to test pyHyp. If we decide on using cgnsdiff then this can be merged after I make the minors edits suggested above. (The function won't end up being used in the pyHyp tests). Otherwise, we may want to add other utilities for the pyHyp tests like a sum over the coordinates in each direction as you suggested.

[sseraj]

We decided not to use this in the pyHyp tests, but I think it's worth merging anyway.

[eirikurj]

@sseraj, ok sounds good. I will push few changes.