Custom GrowthRatios and more Schedule variables

[DavidAnderegg]

Purpose

~~This PR adds the ability to set custom growth ratios on each layer. Additionally, more 'schedule' variables are introduced.~~

This PR adjusts how some options work. Apart from prescribing a single value, it is now possible to define a list with per-layer values. Additionally, it is possible to instruct pyHyp to interpolate the value linearly throughout the extrusion.

This PR removes the volSmoothSchedule variable as the same functionality is now possible with volSmoothIter.

Lastly, a new variable growthRatios is introduced to explicitly set the growth ratio. If it is set, the marchDist option is ignored. This variable works like the other changes introduce here.

Expected time until merged

1 week

Type of change

• [ ] Bugfix (non-breaking change which fixes an issue)
• [x] New feature (non-breaking change which adds functionality)
• [x] Breaking change (non-backwards-compatible fix or feature) - volSmoothSchedule is now obsolete and was removed
• [ ] Code style update (formatting, renaming)
• [ ] Refactoring (no functional changes, no API changes)
• [ ] Documentation update
• [ ] Maintenance update
• [ ] Other (please describe)

Testing

I adjusted the naca0012_rans and corner test to include an 'interpolation' and a 'per-layer' case. I also added a test for nConstantStart and nConstantEnd options. And finally, i added a test for simpleOCart with xBounds and no nearfield mesh.

~~Here are the new ref-files for the new tests: schedule_ref_files.zip~~

Here are the new ref-files for the new tests: refFiles.zip

Checklist

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

[eirikurj]

@DavidAnderegg thanks for the PR. Will try to take a look as soon as I can. In the meantime, can you address the failing tests.

[DavidAnderegg]

@eirikurj The tests fail because new the ref files have not been added. I attached a .zip in the description of this PR.

[eirikurj]

My bad, I only read the description in a rush and saw the test are failing. I can update the reference files. I skimmed the PR content, and it looks good, but will do a more thorough pass later. I think it would be good if we can combine or refactor the RANS scripts to avoid code duplication. They are essentially all the same except for a few options. I suggest one of the two,

1. refactor the geometry generation out into its own file that can be imported or run.
2. use argparse with argument mode (or similar) to run each case and just update the relevant options based on the mode. This will have a smaller footprint.

[eirikurj]

I have updated the files. However, in line with my previous comment on refactoring the scripts I updated the names and inserted rans in the files i.e.,

naca0012_growth_ratios.cgns -> naca0012_rans_growth_ratios.cgns
naca0012_schedule.cgns      -> naca0012_rans_schedule.cgns

To avoid nightly builds failing, I named the archive with the updated files is pyhyp_ref_files_2024-09-04.tar.gz. You can update the script to pull this archive instead for testing. Once ready I will update the main.

[DavidAnderegg]

I agree, getting rid of the duplicated code is a good thing. I adjusted that and also fixed a tiny bug where the marchDistance is not computed when using custom growth ratios. I think this bug is more a testing issue because the test uses the marchDistance to compare the files.

Also, the ref file for the growth ratios needs to be updated: growth_ratios_ref.zip

[DavidAnderegg]

@eirikurj I thought about your comment regarding the modification of input-variables. I think the problem is that I pass the same variable in multiple versions to the fortran layer. E.g I pass splay and splaySchedule, which is the same, but the first time it is a scalar and the second time, it is an interpolation instruction. This leads to the need to figure out which one is used in the fortran layer which is the reason to this 'clusterfuck' you rightfully criticize.

I think a better approach would be to pass only one splay variable to the fortran layer. But instead of a scalar, this will be a list with the same number of entries as there are layers (similar to how growthRatios is implemented). For this to work, I would need to move the 'interpolate logic' to the python layer. But it would also add the benefit that one could specify 'splay' as a scalar, an interpolation or even an list of values for each layer.

I think this is a better approach. If you dont disagree, this is the path I will follow.

[DavidAnderegg]

@eirikurj I adjusted the code as explained in my previous comment. It is once again ready for review.

Please note: i also adjusted the description and added new ref-files.

[DavidAnderegg]

@anilyil, I adressed your comments. You might want to take a look again.

[DavidAnderegg]

@anilyil I know why this happens... Yes, I will look into it.

[DavidAnderegg]

@anilyil Grid Ratios for pyHypMulti print now correctly.

I also replaced that code with 'tabulate' because it is so much easier this way.

[DavidAnderegg]

@eirikurj I adressed your comments. I only resolved the ones where I knew what to do. The unresolved ones either need an answer or a small discussion.

Regarding the ref files, I edited the PR description and updated the link to the ref-files.

Regarding function description. I left out the ones in the examples. Let me know if I should add it there aswell.

[eirikurj]

@DavidAnderegg I address the outstanding comments, see them for detail. I will try to review the PR as soon as possible. Will keep you posted.

[anilyil]

@DavidAnderegg, does the new files break old tests or did you only add new files for the new tests? if we are not breaking any of the existing tests, I can upload the ref files now. If they break existing tests, we can attempt to do it within the same day we plan on merging the PR

[DavidAnderegg]

@anilyil The new ref files do break the old tests. This is because I extended the 'corner' case. So I suggest you wait with updating until the day this PR gets merged.

[DavidAnderegg]

@eirikurj I am sorry for the missing ref-file, I did not realize it... I addressed the comments that were clear. I also changed get-ref-files.sh to point towards pyhyp_ref_files_20241210.tar.gz.

Please let me know what you think regarding the not resolved points.

[codecov[bot]]

Codecov Report

Attention: Patch coverage is 95.45455% with 7 lines in your changes missing coverage. Please review.

Project coverage is 83.64%. Comparing base (a161009) to head (9d0dc94). Report is 2 commits behind head on main.

Files with missing lines	Patch %	Lines
pyhyp/pyHyp.py	96.02%	6 Missing :warning:
pyhyp/utils.py	66.66%	1 Missing :warning:

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #94      +/-   ##
==========================================
+ Coverage   79.24%   83.64%   +4.39%     
==========================================
  Files           4        4              
  Lines         424      538     +114     
==========================================
+ Hits          336      450     +114     
  Misses         88       88              

Flag	Coverage Δ
	?

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

:rocket: New features to boost your workflow:

• :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[DavidAnderegg]

Regarding the failed tests. This is very strange to me. Everything passes except for test_all_examples.py:TestExamples.testCorner . To further add to the confusion, this test also passes on u22-gcc-ompi-latest but fails on the other 3 images. I can reproduce this error locally, but I am a bit lost on how to debug it. Any suggestions are welcome...

Edit: ~When i run the underlying file runCorner.py manually, the output is the same. But when this exact file is called from the test, the result is slightly different.~ I cant reproduce this, back to square 1...

[eirikurj]

Looks good, thanks for all your efforts on this!