-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update mach examples #100
Update mach examples #100
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
mphys_aero_opt.py passes when running with 1, 2, and 4 processors, but fails with 8 procs.
I'm not sure why.
/home/mdolabuser/.pyenv/versions/3.8.9/lib/python3.8/site-packages/openmdao/utils/options_dictionary.py:347: OMDeprecationWarning:'gradient method' is not a valid python name and will become an invalid option name in a future release. You can prevent this warning (and future exceptions) by declaring this option using a valid python name.
/home/mdolabuser/.pyenv/versions/3.8.9/lib/python3.8/site-packages/pygeo/parameterization/DVGeo.py:744: UserWarning: addGeoDVGlobal will be deprecated, use addGlobalDV instead
warnings.warn("addGeoDVGlobal will be deprecated, use addGlobalDV instead")
/home/mdolabuser/.pyenv/versions/3.8.9/lib/python3.8/site-packages/pygeo/parameterization/DVGeo.py:845: UserWarning: addGeoDVLocal will be deprecated, use addLocalDV instead
warnings.warn("addGeoDVLocal will be deprecated, use addLocalDV instead")
Traceback (most recent call last):
File "mphys_aero_opt.py", line 196, in <module>
prob.setup(mode="rev")
File "/home/mdolabuser/.pyenv/versions/3.8.9/lib/python3.8/site-packages/openmdao/core/problem.py", line 1014, in setup
model._setup(model_comm, mode, self._metadata)
File "/home/mdolabuser/.pyenv/versions/3.8.9/lib/python3.8/site-packages/openmdao/core/system.py", line 864, in _setup
self._top_level_post_sizes()
File "/home/mdolabuser/.pyenv/versions/3.8.9/lib/python3.8/site-packages/openmdao/core/group.py", line 809, in _top_level_post_sizes
comp._update_dist_src_indices(conns, all_abs2meta, abs2idx,
File "/home/mdolabuser/.pyenv/versions/3.8.9/lib/python3.8/site-packages/openmdao/core/component.py", line 959, in _update_dist_src_indices
meta_in['src_indices'] = indexer(slice(offset, end), flat_src=True,
File "/home/mdolabuser/.pyenv/versions/3.8.9/lib/python3.8/site-packages/openmdao/utils/indexer.py", line 1333, in __call__
idxer.set_src_shape(src_shape)
File "/home/mdolabuser/.pyenv/versions/3.8.9/lib/python3.8/site-packages/openmdao/utils/indexer.py", line 269, in set_src_shape
self._check_bounds()
File "/home/mdolabuser/.pyenv/versions/3.8.9/lib/python3.8/site-packages/openmdao/utils/indexer.py", line 606, in _check_bounds
raise IndexError(f"{self._slice} is out of bounds of the source shape "
IndexError: slice(13311, 13311, None) is out of bounds of the source shape (13311,).
@joanibal @bernardopacini We see the same error when running Mphys_DAFoam with OM 3.17. This was not a problem with OM 3.16. |
As @friedenhe mentioned, we have essentially this exact issue with DAFoam. For us it only seems to show up when running aerostructural cases, but it happens with any number of cores greater than 1. Given that you are able to run with 2 and 4 but not 8 cores, it seems likely due to how the mesh (or surfaces) are divided among the procs? |
Well, it's good to hear that you are having this issue too. It certainly look like an openMDAO issue to me. From the call stack it seems to be caused when the last proc has no input for a distributed input. It is interesting that the slice causes a size error given that it wouldn't return any values anyway since the range is zero. |
It looks like the related OpenMDAO issue is fixed and the script mentioned above does work on 8 processors on the latest commit of OpenMDAO. I also checked that it fails again on 3.17.0 with 8 processors. |
Can you take another look at this PR since OpenMDAO v3.18.0 fixed the parallel issue, @joanibal ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me.
This PR updates all of the examples and tests that include ADflow and pyGeo to use a consistent orientation where y is spanwise out and z is the lift direction. This differs from the default mach-tutorial case where z is spanwise out and y is the lift direction.
I have updated all examples and also provided readme files in the example directories of adflow on how to get the input files. I also uploaded the input file archive hosted by our AFS server. Finally, I have several additions to gitignore for convenience.
@joanibal, I had to re-train the aerostructural analysis test. Please make sure it looks good. @bernardopacini @friedenhe we can also update the DAfoam stuff here if you prefer.