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.

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)

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

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.

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.

uCRM_coarse.zip

Any help is appreciated.

Thanks

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)

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.

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.

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

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.

Time-domain problems driven by OpenMDAO either with Dymos or with OpenMDAO as a black box for each time step.

Summary of the issue

In 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.

Recreating the issue

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.

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".

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.

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.

Extend ADflow component from propulsion optimization work for FSI.

Initial implementation with mesh warping and flow solver as a single component.

Need to reorganize the documentation to accommodate the different types of MPhys users:

• Users - want to apply existing Builders to their applications
• Builder developers - want to connect their codes to Mphys. Don't need to know all the inner workings of Mphys. May be coming with little to no OpenMDAO experience
• Mphys developers - developing directly in Mphys, establishing new standardized scenarios.

We need sufficient resources for each type of user.

• “Users” don’t get lost having to filter through developer-related docs to find what they need
• Link to OpenMDAO documentation when describing use of more advanced features
• Link to John Jasa’s training where appropriate for people without MDAO backgrounds

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.

adflow_error.txt

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.

• check partials
• check operations when aerodynamic and structural comms are not the same

As currently coded, a new assembler must be written for every combination of structural solver, flow solver, and transfer scheme.

• Add U Mich shape parameterization component
• Add massoud 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!

• check partials
• general f5 output
• use individual functions with names instead of single f_struct list
• functions on subdomain
• Create separate OM component for TACS mass function
• Python dictionary for design variables. 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] }

• TACS and ADflow both running on all procs
• TACS running on a subset of the ADflow procs
• TACS and ADflow running on different sets of procs
• Multiple FSI coupling groups running on the same sets of procs
• Multiple FSI coupling groups running on different sets of procs

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.

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.

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.

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.

testflo_report.txt

Add support for U Mich rigid link transfer scheme

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.

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

`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

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.

Approach 1: Single transfer scheme builder

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.

Approach 2: Multiple transfer scheme builders

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(...)].

Comments

Either way Mphys or the transfer scheme builder needs to get tagging information from the physics solvers.

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] }

• Change the examples in the public repo to only be open source geometries and codes. Examples in the repo should be runnable from the University of Michigan's public docker image. We will need to add TACS, FUNtoFEM and OpenAeroStruct to this image
• Move VLM examples to OpenAeroStruct
• add wget scripts for large mesh files or store all case files in a single location.
• provide instructions for converting docker image to singularity container for HPC users.
• Add CI to regularly (biweekly) run some set of examples using the docker image

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.

Add CI actions to check/apply the following:

• Add flake8 linting
• black formatting
• isort to sort imports

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.

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"

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