openmdao / mphys Goto Github PK
View Code? Open in Web Editor NEWMultiphysics with OpenMDAO
License: Other
Multiphysics with OpenMDAO
License: Other
With the TACS functions calculated in the same component, the current version of OpenMDAO assumes 'mass' is a function of the structural displacements and calculates an extra adjoint
Extend ADflow component from propulsion optimization work for FSI.
Initial implementation with mesh warping and flow solver as a single component.
I've been running the MACH tutorials in the example folder for both the aero and aerostructural analyses. In serial execution, they behave pretty much as I would expect them to. However, when running in parallel, I get a bunch of warnings (maybe even errors, I can't tell) that look something like this:
[e09065d05ca4:00096] Read -1, expected 520704, errno = 1
I suspect that this is a message from ADflow, as it is output during CFD iterations, although I can't pinpoint where it comes from within ADflow.
After the analysis completes another series of warnings, this time for OpenMDAO, is put out that looks something like this (there are a lot more of them):
DeprecationWarning:'mp_group.s0.solver_group.struct.solver' <class TacsSolver>: Passing `src_indices` as an arg to `add_input` isdeprecated and will become an error in a future release. Add `src_indices` to a `promotes` or `connect` call instead.
The questions that arise (for me), are:
Are these warnings (the ADflow ones, in particular) concerning/potentially an issue, even if my solutions have completed so far? If so, does anyone have any pointers how to resolve the first set ADflow messages? And is there a recommended version of OpenMDAO to use with mphys at this point, to avoid deprecation issues?
Thanks in advance for your inputs!
Add support for U Mich rigid link transfer scheme
To make it easier to run all the test we should refactor the test to use an existing python test framework. I suggest testflo since it has the capability to perform MPI parallel tests and is used by OpenMDAO.
With DVConstraints, and possibly with DVGeometry wrapper as well, we compute and store a full Jacobian internally using complex step or parallel finite differences. However, we have been using the matrix-free Jacobian vector product API in OpenMDAO instead of the matrix-based API.
Our approach is not well suited with the mat-free API; we end up either needing to do full jacobian computations each time mat-free API is called, or we need to keep track of design changes and update the Jacobians once and re-use them for subsequent mat-free API calls.
Matrix-based API is the way to go here: OpenMDAO would automatically update the matrix-based Jacobians when the design is changed. The only work we need to do here is to expose our Jacobians to OpenMDAO in the correct format for each DV and output/constraint.
The code that exists in the repos can only be used to couple aerodynamics and structural disciplines. The existing code needs to be generalized to live up to the name "multi-physics".
With Mphys we typically trim a system by using AoA as a DV, and L=W as an optimization constraint.
This requires a full optimization to achieve a trimmed result, but it is possible to include the trimming math in the analysis. One possible approach is to use a Schur compliment approach like is being explored in aeropropulsive coupling
Hi,
I would like to assign multiple design surfaces to the designSurfaceFamily option in adflow.
aero_options = {
"designSurfaceFamily":"wingu",
}
In the options, there is only a possibility to assign either a string or None to the designSurfaceFamily
source. When I try to assign multiple surfaces I get an error which is expected based on the documentation (accepts only str
).
baseclasses.utils.error.Error:
| Error: Datatype for option designSurfaceFamily is not valid. Expected data |
| type (<class 'str'>, <class 'NoneType'>). Received data type is <class |
| 'list'>
In my CGNS mesh, the wing geometry that I would like to optimize contains multiple components which consist of surfaces namely: "wingu", "wingLE", "wingTE", "wingb"
. And fuselage
and tail
which are not a part of optimisation.
I would like to know if there is a workaround to solve this problem of assigning multiple design surfaces to the solver at once.
Attempting to consolidate all wing surfaces into a "wing" family using cgns_utils
proved challenging due to the inherent complexity of handling multiblock meshes.
Coraser version of the mesh is attached.
Any help is appreciated.
Thanks
the pygeo wrapper can be cleaned up substantially and we can also make the integration with the new api smoother.
In particular, during reverse mode derivative computations, it does unnecessary work when we have many thickness constraints, but pygeo still evaluates the full jacobian including the cfd surface nodes even though their seeds are zero.
The add_input within pygeo should be standardized so that the initial values default to the correct values. For example, "local" shape change parameters should be set to 0 by default. More details can be found at: #51 (comment)
At different flight conditions, control surface positions or other geometry changes may be needed for each scenario. We need to be able to support this.
One possible approach is to create a separate instance of the geometry in each scenario. This is the simplest approach but may lead to duplication of some computations on the non-moving surfaces.
An alternative approach is to have one main geometry parametrization component and pre-coupling geometry components in each scenario that adjust the moving surfaces.
`f_struct = f_struct_from_aero + f_inertial + f_fuel + ...
A question of naming conventions. Do we rename f_struct
as f_struct_from_aero
? or maybe call the left hand side of the above equation f_struct_total
Add CI actions to check/apply the following:
Time-domain problems driven by OpenMDAO either with Dymos or with OpenMDAO as a black box for each time step.
f_struct
listIn a Multipoint
group with 2 aerostructural scenarios, a and b, the totals from scenario a are incorrect while the totals from scenario b are correct. If the conditions (flight conditions, structural loading) of scenario b are changed to match those of scenario a, then the derivatives of both scenarios are correct. This suggests that some scenario specific state data from scenario b is mistakenly being used when computing the totals of scenario a.
The output below was all produced running in serial on the MDOLab's u22-gcc-ompi-latest docker container with the following packages
ubuntu 22.04
gcc 11.3.0
python 3.9.6
openmpi-4.1.4
petsc-3.18.3
Package Version
----------------------------- ---------
adflow 2.8.0
Cython 0.29.34
funtofem 0.2
numpy 1.21.5
numpy-stl 3.0.1
openmdao 3.20.0
scipy 1.7.3
tacs 3.2.0
The problem can be reproduced by running the mphys_as_2scenario.py
script in the examples/aerostructural/mach_tutorial_wing/adflow_meld_tacs
directory of this repo. I will attach a patch file below which adds a call to check_totals
to the script and makes the maneuver
scenario's aeroProblem more different from the cruise
aeroProblem to make the issue more clear.
aoa0 = 2.0
ap0 = AeroProblem(
name="cruise",
mach=0.85,
altitude=10000,
alpha=aoa0,
areaRef=45.5,
chordRef=3.25,
evalFuncs=["lift", "drag", "cl", "cd"],
)
ap0.addDV("alpha", value=aoa0, name="aoa", units="deg")
aoa1 = 5.0
ap1 = AeroProblem(
name="maneuver",
mach=0.5,
altitude=0,
alpha=aoa1,
areaRef=45.5,
chordRef=3.25,
evalFuncs=["lift", "drag", "cl", "cd"],
)
ap1.addDV("alpha", value=aoa1, name="aoa", units="deg")
Then, running python mphys_as_2scenario.py
produces:
-----------------
Total Derivatives
-----------------
'<output>' wrt '<variable>' | calc mag. | check mag. | a(cal-chk) | r(cal-chk)
---------------------------------------------------------------------------------------------------------------------
'cruise.aero_post.cd' wrt 'aoa0' | 6.9906e-04 | 1.6990e-03 | 9.9994e-04 | 5.8855e-01 >ABS_TOL >REL_TOL
'cruise.aero_post.cd' wrt 'aoa1' | 0.0000e+00 | 2.6275e-06 | 2.6275e-06 | 1.0000e+00 >ABS_TOL >REL_TOL
'maneuver.aero_post.cd' wrt 'aoa0' | 0.0000e+00 | 9.3675e-08 | 9.3675e-08 | 1.0000e+00 >REL_TOL
'maneuver.aero_post.cd' wrt 'aoa1' | 3.1859e-03 | 3.1860e-03 | 9.7114e-08 | 3.0481e-05 >REL_TOL
After updating to latest versions of some packages:
tacs-3.2.1
mphys-1.1.0
openmdao-3.26.0
funtofem master branch @2ff3f1c639ce2ce146cc3db670abe3f90155c906
adflow main branch @b97914be9db29ab6c8f362099618d4de9df39b54
The result is the same:
-----------------
Total Derivatives
-----------------
'<output>' wrt '<variable>' | calc mag. | check mag. | a(cal-chk) | r(cal-chk)
---------------------------------------------------------------------------------------------------------------------
'cruise.aero_post.cd' wrt 'aoa0' | 6.9906e-04 | 1.6990e-03 | 9.9994e-04 | 5.8855e-01 >ABS_TOL >REL_TOL
'cruise.aero_post.cd' wrt 'aoa1' | 0.0000e+00 | 2.6275e-06 | 2.6275e-06 | 1.0000e+00 >ABS_TOL >REL_TOL
'maneuver.aero_post.cd' wrt 'aoa0' | 0.0000e+00 | 9.3675e-08 | 9.3675e-08 | 1.0000e+00 >REL_TOL
'maneuver.aero_post.cd' wrt 'aoa1' | 3.1859e-03 | 3.1860e-03 | 9.7114e-08 | 3.0481e-05 >REL_TOL
Then, if I make ap1
identical to ap0
, the derivatives for ap0
are fixed:
aoa0 = 2.0
ap0 = AeroProblem(
name="cruise",
mach=0.85,
altitude=10000,
alpha=aoa0,
areaRef=45.5,
chordRef=3.25,
evalFuncs=["lift", "drag", "cl", "cd"],
)
ap0.addDV("alpha", value=aoa0, name="aoa", units="deg")
aoa1 = 2.0
ap1 = AeroProblem(
name="cruise",
mach=0.85,
altitude=10000,
alpha=aoa0,
areaRef=45.5,
chordRef=3.25,
evalFuncs=["lift", "drag", "cl", "cd"],
)
ap1.addDV("alpha", value=aoa1, name="aoa", units="deg")
-----------------
Total Derivatives
-----------------
'<output>' wrt '<variable>' | calc mag. | check mag. | a(cal-chk) | r(cal-chk)
---------------------------------------------------------------------------------------------------------------------
'cruise.aero_post.cd' wrt 'aoa0' | 1.6968e-03 | 1.6990e-03 | 2.2253e-06 | 1.3098e-03 >ABS_TOL >REL_TOL
'cruise.aero_post.cd' wrt 'aoa1' | 0.0000e+00 | 2.6275e-06 | 2.6275e-06 | 1.0000e+00 >ABS_TOL >REL_TOL
'maneuver.aero_post.cd' wrt 'aoa0' | 0.0000e+00 | 2.6358e-06 | 2.6358e-06 | 1.0000e+00 >ABS_TOL >REL_TOL
'maneuver.aero_post.cd' wrt 'aoa1' | 1.6966e-03 | 1.6992e-03 | 2.6407e-06 | 1.5541e-03 >ABS_TOL >REL_TOL
The same thing happens if ap0
is made identical to ap1
suggesting that this is not an issue with any specific analysis condition but instead with data from the second scenario being mistakenly used by the first.
Although here I am modifying the aeroProblems to demonstrate the issue, I don't believe the issue is specific to ADflow, since the 2 pt aero-only example in examples/aero_only/mach_tutorial_wing/adflow/mphys_aero_opt_2pt.py
produces accurate derivatives for both scenarios.
I'm adding an issue raised by others at the last meeting, so that it can be discussed further here.
The issue, as paraphrased by @kejacobson is
"So far we've assumed the thermal mesh is the same structural analysis mesh on the structures side, but in general that may not be true. We've got _a for aero variables, _s for structures, so we decided we need a new one for the thermal analysis."
and the current idea that came out of the meeting is
"Since we aren't limited to one letter, we thought we should clarify the existing descriptions too. So change existing variables with extensions: _a -> _aero , _s -> _struct, and add _therm for variables related the thermal problem"
I merged the PR that removed all of the src_indices from the wrappers and replaced it with shape by conn (#51). However, I did not realize a certain type of connections would be broken this way. I will now work towards resolving this issue in the short term, but users should keep this in mind. Currently, the master branch is broken for parallel models where a distributed component's output is connected to an input of a serial component where the input is shaped by connection. One example of this type of connection is in the adflow wrapper. The volume mesh and state connection to the adflow functionals group is broken for example.
To avoid this issue, checkout the latest tagged version. I will post updates here once I fix it in the short term, and another update when the shape by connection is fixed on the openmdao side.
The aeropropulsive scenario is currently only used for my benchmark optimization study. Once that is finalized and released, we should put a simplified version in mphys and possibly clean up the aeropropulsive scenario definition.
Once the meld wrapper is merged out of MPHYS, we should look at setting up a PyPI package for the library so users can pip install
it (like OpenMDAO). It really shouldn't be too difficult since all the code is pure Python.
@swryan would probably be a good source for how to do this.
The python dictionary will contain a list indices associated with certain components of types of components. This will allow the user to easily pull sets of design variables from the full TACS design variable array.
For example, tacs_dv = { 'stringers': [ 0,1,2,3,20,21], 'ribs': [4,5,6,22,23] }
It looks like pyGeo's mphys wrapper had a breaking API change at some point, but the changes never got updated in the examples.
I was able to fix one of the examples in PR #128
But it looks like there are other examples (here, here, and here, and others) that need to be gone through and fixed as well.
I've been trying to run the MACH aero example (examples/mach_tutorials/aero). However, while the solver is being set up, idwarp complains that the options specified in the example are not idwarp options. Are there specific ADflow/idwarp versions that are compatible with mphys at this point (I am running ADflow 2.3)?
Attached is the detailed error log. Any pointers would be appreciated.
Thanks.
The addition of flight conditions with the adflow wrapper should be standardized so that we can use the common naming convention with other aero solvers. currently, adflow still uses aeroproblems during configure and this requires extra manual connections.
Also with these changes, we can clean up the wrapper a bit and remove the unnecessary methods that were called in configure.
Python already provides a clear way of using namespaces through modules.
As a result the mphys_
prefix for files, classes, and methods used in the mphys module is redundant.
I propose removing the mphys_
prefix present throughout the code within the mphys repo. Although, for files like mphys_adflow.py
which will eventually be moved back to the main code repo I think it does make sense to keep the prefix since it will be moved outside of the module eventually.
When doing large optimizations, particular with time-domain analysis, the full optimization will not fit into the time limits set by most HPC clusters. The approach is then to have the optimization running on the login nodes, dispatching analyses and sensitivity computations to the compute nodes. Ideally we would have a user-friendly way to handle this. A couple of libraries to aid in this are dask, and pbs4py
Hi,
While running the aero structural case found in \examples\aerostructural\mach_tutorial_wing\adflow_meld_tacs
the following error appears:
Traceback (most recent call last):
File "mphys_as_2scenario.py", line 11, in <module>
from funtofem.mphys import MeldBuilder
ModuleNotFoundError: No module named 'funtofem.mphys'
Traceback (most recent call last):
File "mphys_as_2scenario.py", line 11, in <module>
from funtofem.mphys import MeldBuilder
ModuleNotFoundError: No module named 'funtofem.mphys'
Traceback (most recent call last):
File "mphys_as_2scenario.py", line 11, in <module>
from funtofem.mphys import MeldBuilder
ModuleNotFoundError: No module named 'funtofem.mphys'
Traceback (most recent call last):
File "mphys_as_2scenario.py", line 11, in <module>
from funtofem.mphys import MeldBuilder
ModuleNotFoundError: No module named 'funtofem.mphys'
Modules funtofem and mphys are installed in the system.
Please help me with fix this error. Thanks
To ensure functionality of the code doesn't silently break, we should be using CI. This is especially import for projects with many collaborators as it is unlikely that one person will understand how their change will affect each of the features added by others.
I suggest Travis CI because it has been used successfully by the MDOLab and the OpenMDAO dev-team.
As currently coded, a new assembler must be written for every combination of structural solver, flow solver, and transfer scheme.
For some computations, such as certain transfer schemes, integrations, or geometry constraints, mesh connectivity information will need to be shared across builders.
In order to do this, we need conventions that define mesh connectivity information and then standardized interfaces for accessing the data.
For a convention starting point, NASTRAN and CGNS share the same definitions for winding (order of nodes) in elements.
Use Readthedocs.com or an alternative service to provide a place to view the documentation without needing to build it locally. This will also serve as means to publicize the code.
Come up with an approach to handling multiple bodies in a multiphysics problem. For example, an aerostructural case with a wing and tail, where the wing and tail may need separate transfer scheme components.
Identify the different bodies through tagging (handling in OpenMDAO metadata or externally via an Mphys Builder method). The transfer scheme developer can then decide if the transfer scheme group has a separate transfer scheme component for each body or handle that logic inside of a single transfer scheme.
Let Mphys slice the vectors according to bodies and have the multiphysics scenario add components from the transfer scheme builders for each body in a loop and do the sliced connections to each transfer scheme.
This approach may result in more changes to exist Mphys Scenarios, variable naming conventions etc. It could make Scenario classes and resulting coupled matrix structures more complex if the filtering step is an OM component, but make it easier for the user to select which transfer scheme is applied to each body, e.g., xfer_builders = [MeldBuilder(...), BeamXferBuilder(...)]
.
Either way Mphys or the transfer scheme builder needs to get tagging information from the physics solvers.
After PR #51 is merged, most of the code will be using shape by connection to size the inputs to components. The convention originally followed was to explicitly size all outputs and have as many inputs as possible be shaped by connection. However, there is a possibility to utilize the feature even more by relaxing this convention. We should look into possible simplification of the code by using the copy_shape feature, while still using the "downstream" mode of shape information transfer. For examples, see: #51 (comment) and #51 (comment) and #51 (comment)
It seems that a number of mphys tests fail "out of the box". Using MDOLab's u22-gcc-ompi-stable docker container, and running testflo .
in mphys/tests
gives the following:
The following tests failed:
test_dafoam_aero.py:
test_dafoam_aerostruct.py:
test_dafoam_derivs.py:
test_meld_derivs.py:TestXferClasses.test_derivatives
test_tacs_derivs.py:TestTACS.test_derivatives
test_tacs_partials.py:TestTACS.test_derivatives
I think the first three tests fail because the docker container does not include dafoam (please correct me if I'm wrong). However, should I be concerned with the last three tests? Or can I presume that mphys is installed correctly? Attached is the testflo_report.
Need to reorganize the documentation to accommodate the different types of MPhys users:
We need sufficient resources for each type of user.
wget
scripts for large mesh files or store all case files in a single location.After POEM 46 in merged into OpenMDAO, adjust integration tests to check that distributed solvers like TACS and MELD work properly when run on multiple procs.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.