Custom GrowthRatios and more Schedule variables

DavidAnderegg commented 2 months ago

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 commented 2 months ago

@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 commented 2 months ago

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

eirikurj commented 2 months ago

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,

refactor the geometry generation out into its own file that can be imported or run.
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 commented 2 months ago

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 commented 2 months ago

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 commented 1 month ago

@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 commented 1 month ago

@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 commented 1 month ago

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

DavidAnderegg commented 3 weeks ago

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

DavidAnderegg commented 3 weeks ago

@anilyil Grid Ratios for pyHypMulti print now correctly.

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

mdolab / pyhyp