smdogroup / funtofem Goto Github PK

Need to add options for symmetry boundary conditions in the available BC's to pass to AFLR.

• make a new class called Fun3dAeroDriver that optimizes over aerodynamic analysis and aero DVs only
• also include aerodynamic shape optimization using a wrapper class for the afrlAIM and fun3dAIM
• and once again add external shape variable option or the ability to build the aims outside of the wrapper classes if desired
• Should replace fun3d_client and make it deprecated
• Can preseed with initial structural displacements from the model but only oneway-coupled

In pyfuntofem body class, the struct_shape_term and aero_shape_term are initialized as dictionaries.
But in initialize_variables they are overwritten to single scenario (ns, nf) or (na, nf) arrays which overwrites earlier scenarios.
Therefore, this approach works for single scenario problems but won't work for shape variable optimization problems with multi scenarios.

• Mirror the conda/ folder in github/smdogroup/tacs
• Copy C++ header files from funtofem/ source code folder into include folder
• make the .so object and move to lib folder
• python files are moved to site-packages folder in conda
• setup conda package to deploy on new release
• Real and complex modes so that we conda install for testing if we want to

• Fix/enhance Fun3dClient for pure aerodynamic analysis in FUN3D through FUNtoFEM

There is an assertion in the body class to check if the analysis_type is recognized, I think this is redundant since there is already a method implemented to verify the analysis type that is called during initialize_transfer. But it shouldn't hurt anything for now--should modify in the future to be consistent.

Isn't this analysis type verification here redundant since we already run self.verify_analysis_type in initialize_transfer()?

Originally posted by @bburke38 in #86 (comment)

A build error/issue seems to have been introduced during some reorganization of the project in commit e256b5f. At that commit, I'm encountering the following error running 'make interface':

  Error compiling Cython file:
  ------------------------------------------------------------
  ...

  cdef extern from "mpi-compat.h":
         pass

  # Import the declarations required from the pxd file
  from TransferScheme cimport *
  ^
  ------------------------------------------------------------

  funtofem/TransferScheme.pyx:14:0: 'TransferScheme.pxd' not found

The following post seems relevant, particularly since the issue popped up around some reorganization:
https://stackoverflow.com/questions/35512157/error-compiling-cython-file-pxd-not-found-in-package

Not quite clear why it's popping up for us and not the main developers. We are not installing via conda. Commit 1329ed5 builds OK.

Need a way to classify the phases of the design history into:

1. moving towards xstar, significant changes in function values and design variables
2. oscillating around xstar due to remeshing noise

Solutions: could think of some mathematical rules, use machine learning.

Alternative but weaker resolutions:

• just use weaker opt tolerance and only do remeshing
• optimize first with remeshing script then with mesh morphing manually

• documentation for tacs oneway driver, new classes SolverManager, CommManager, etc.
• Complete the changes on updated-docs branch and pull request it to master

Hi,

I've been working on a new solver interface for FUNtoFEM, and I was a little bit confused about ownership and use of the Model object in the SolverInterface and FUNtoFEMDriver classes.

As I understand it now, a SolverInterface must have access to the Model object in its constructor. This is so that it can, for example, call initialize_aero_nodes for a given Body object in the Model and thus set the sizes of the data structures in that Body object before the driver calls initialize_variables on that Body object and creates those data structures. Otherwise, you end up with data structures of the default size zero, which isn't very helpful.

But that fact---that a SolverInterface must have access to the Model in its constructor---wasn't obvious to me at first. There isn't a model parameter in the constructor for the SolverInterface base class. And most of the member functions that make up the interface of the SolverInterface class, functions like initialize, include parameters scenario and bodies. That gave me the first impression that SolverInterface doesn't need its own "reference" to the Model, because the driver will just pass in the Scenario object or Body list from its own "reference" to the Model. And indeed that is how things work for the most part. Returning to the example of initialize, the driver calls _initialize_forward(scenario, self.model.bodies) which propagates the Body list from self.model, the driver's own "reference" to the Model, through to SolverInterface.initialize via the bodies parameter.

So my conclusion is that SolverInterface doesn't actually need its own access to Model for the most part, except crucially in its constructor when it needs to initialize the nodes in the Model's Body objects. That's a little confusing. But I understand it could be difficult to disentangle. I don't really have any prescriptions. But I thought it might be useful to log this in Issues in case anyone finds themselves similarly confused in the future.

--Jan

• when constructing oneway driver with class method prime_loads_from_file get zero derivatives
• requested by Neal Novotny

• combine the two interfaces into one file
• Add a base class TacsInterface with no constructor with classmethod create_from_bdf
• The class method will figure out whether all scenarios are steady or unsteady in the model and create the appropriate class TacsSteadyInterface or TacsUnsteadyInterface using create_from_bdf
• Move tacs integration settings to scenario class so that the create_from_bdf methods are identical

• In flat plate test case, got dGdxa0^T psi_G in y and z directions were flipped with a negative sign. Is this because the swap_yz was on? Do we need to make a warning for not using swap_yz when extracting aero coordinate derivatives. Why was there also a negative sign?
• TODO: try this with the diamond wedge case in node 1, y and z directions (two separate runs)
• Subsonic flat plate derivative tests, caveat swap_yz = .true. was on:
  test-fun3daero-coords.txt

• work on su2_interface.py
• make an associated unittest and get to machine precision

• Confusing when there are very similar classes that are separate. Would be nice to reduce the number of files in our code.
• Tricky because they both use different constructors, but might be possible. Need to look into special python features for this or classes that hold class attributes.
• Maybe class within a class or some kind of feature like that? Unclear how best to do this
• Class with properties of other classes TacsOnewayDriver.read(model) figures out whether shape variables are included and returns a class of appropriate type => TacsSteadyAnalysisDriver or TacsSteadyShapeDriver, then you build that. So all in all it would be `TacsOnewayDriver.build(model).prime_loads(args) instead of separate construction of classes

# long version, read method figures out which class to make and returns the class itself, not the object
tacs_driver_class = TacsOnewayDriver.read(model)
tacs_driver = tacs_driver_class.prime_loads(args)

# simplified version 
tacs_driver = TacsOnewayDriver.read(model).prime_loads(args)

In general, the finite difference checks used in the real mode should use the same tolerances. Right now, specific tests require higher or lower tolerances to pass.

• Wrap MPI code that deals with ESP/CAPS fun3dAIM, aflrAIM on serial
• include aim interfaces in funtofem driver and or aero funtofem driver
• auto-registration of funtofem variables through interface to aims for the flow aims (similar to tacs model)
• potentially a fun3d_model class that is registered to the funtofem model?

• uses out of date method for compute_partials
• add features to write design history to a file, add analysis_dir options, model options, etc.
• add feature to plot optimization history

• compute dw/dt at each time
• store unsteady adjoints dPiston_adj or something in the class
• These features already exist in a branch of sean-engelstad/funtofem
• Need to fix bug that derivatives are only down to 1e-2 instead of 1e-11

• change to OnewayStructDriver
• agnostic to other struct solvers and AIMs

• Ability to run pre_analysis and post_analysis outside of the main solve_forward and solve_adjoint loops of the Fun3dOnewayDriver and FuntofemShapeDriver through an external_shape flag.
• Warning: the user will have to move files to the appropriate directories such as the ugrid file and TACS mesh files in the remeshing and morphing case. These operations are handled by caps2tacs and caps2fun automatically if you choose external_shape=False.

• in fun3d_interface.py, the rigid transform adjoints are commented out since they have not been kept up
• Want to get them working again

• use github niceplots to improve the color scheme, font size, etc. of optimization plots
• This way they will be automatically ready for insertion into a paper.
• or just use color maps like jet and put legend on rhs

• capability for composite functions which are dependencies of analysis functions
• ex: if lift, drag, mass are analysis functions from the aerodynamic and structural functions respectively, the takeoff gross weight (TOGW) would be computed from these
• methods _get_analysis_functions in the model used in the interfaces instead of _get_functions
• method _get_composite_functions in the model
• methods _solve_forward_composite and _solve_adjoint_composite will compute derivatives and values of composite funcs from analysis funcs, used in drivers
• include subclass CompositeFunction of Function and takes in method handles name, evaluate, evaluate_grad in constructor each dictionary based functions
• Class methods like TOGW for composite function class, etc
• Two classes CompositeFunction: made up of other functions of the same scenario
• AggregateFunction: combines information of same function name among scenarios

Add aims/wrappers into main funtofem driver and use class methods or a subclass called funtofem shape driver.

• Add coordinate derivatives for aero and structural disciplines to the MeldThermal class
• Should just involve differentiating the weight matrix involved in the T and Q residuals w.r.t. xa0 and xs0
• Will have to add to MeldThermal.cpp, TransferScheme.pxd, TransferScheme.pyx, and the body.py file
• Discovered these features are missing because the aerothermal coordinate derivatives in my coordinate derivatives unittest for the TacsOnewayDriver were off by 100%. Aerothermoelastic was very off too

Let TS be Transfer scheme

• Coordinate derivatives for aero and struct shape come from TS adjoints at each time step, but we currently only add them at the final time step in the driver.
• Resolution: include add_coordinate_derivatives calls in the funtofem_nlbgs driver => _solve_unsteady_adjoint
• Then at some point want to make the tacs oneway driver be able to do unsteady shape derivatives and this would be important for that

• add new unittest for Fun3d unsteady with tacs unsteady

• Add unsteady analysis with _solve_steady_forward, _solve_unsteady_forward to the TacsOnewayDriver class
• Add equivalent unittests

Hi,

I'm getting this error (and a couple others) on when I install FUNtoFEM in a "clean" environment. I recorded my terminal session to show you how I arrived at it, and I've attached it here. It's not exactly pleasant to read, so I'll try and summarize the main points out of it.

1. I cloned the funtofem repository.

2. I created a new Python virtual environment and installed numpy, cython, and mpi4py in it.

3. I installed FUNtoFEM using make and make interface.

4. I tried to run examples/functionality/stand_alone/cloud.py and I got the following error.

Traceback (most recent call last):
  File "/home/jank/Packages/funtofem/examples/functionality/stand_alone/cloud.py", line 76, in <module>
    aero_loads = np.zeros(3 * aero_nnodes, dtype=TransferScheme.dtype)
TypeError: expected a sequence of integers or a single integer, got '12.0'

I ran this example really just to see if this bug was still here. It appeared as a consequence of the division operator changing from Python 2 to Python 3. This example isn't important, and I imagine the other division operator-related TypeError bugs have been caught by now. But I thought I would call it out.

5. I created a barebones example to try importing the SolverInterface class, as I would if I were developing a new interface.

from pyfuntofem import SolverInterface

print('Hello, world!')

6. I ran that example and got the following error.

Traceback (most recent call last):
  File "/home/jank/Packages/funtofem/examples/test_interface_import.py", line 1, in <module>
    from pyfuntofem import SolverInterface
  File "/home/jank/Packages/funtofem/pyfuntofem/__init__.py", line 30, in <module>
    from .driver import *
  File "/home/jank/Packages/funtofem/pyfuntofem/driver/__init__.py", line 10, in <module>
    tacs_loader = importlib.util.find_spec("tacs")
AttributeError: module 'importlib' has no attribute 'util'

I first encountered this a couple of weeks ago. I found that, according to this post, it's a peculiarity of importlib that the util module may or may not load as you expect on some systems. I just changed import importlib to import importlib.util to make sure the util module gets loaded. It may just be the Docker container I'm running it on, which is why I didn't mention it sooner. But I thought I might as well now.

7. After applying that fix, I ran the example again and finally got the error I was originally looking for.

Traceback (most recent call last):
  File "/home/jank/Packages/funtofem/examples/test_interface_import.py", line 1, in <module>
    from pyfuntofem import SolverInterface
  File "/home/jank/Packages/funtofem/pyfuntofem/__init__.py", line 33, in <modul
e>
    from .interface import *
  File "/home/jank/Packages/funtofem/pyfuntofem/interface/__init__.py", line 31, in <module>
    from .solver_manager import *
  File "/home/jank/Packages/funtofem/pyfuntofem/interface/solver_manager.py", line 5, in <module>
    from .tacs_interface import TacsSteadyInterface
  File "/home/jank/Packages/funtofem/pyfuntofem/interface/tacs_interface.py", line 26, in <module>
    from tacs import pytacs, TACS, functions
ModuleNotFoundError: No module named 'tacs'

If I install TACS, the error naturally goes away. And I suppose people installing FUNtoFEM using Conda will never see it. But for the case of a developer who is writing a new solver interface for FUNtoFEM---one that has nothing to do with TACS---this TACS dependency error in FUNtoFEM will be noticeable and will probably seem a little strange. I don't know if this is an issue to be resolved. Maybe the solution is really to insist that FUNtoFEM users, FUNtoFEM developers, and everyone else who can be convinced just install TACS.

--Jan

reproduce_tacs_module_not_found_error.txt

• add back in rigid adjoint transfers in fun3d_interface.py

Callback method isn't returning the element callback inside the outer function.

• Some derivatives or features don't seem like they will work in multi scenario problems like functions with same name. Fix this
• Write unit tests for funtofem driver with multi scenario problems to debug and for CI

• ability to define CompositeFunctions with variables in them too for constraint functions
• add variables arg into CompositeFunction constructor, derivatives 0 or 1 no need to complex step these

• make unit tests for fun3d_interface + tacs unsteady interface with unsteady scenarios

• Need to finalize and verify the adjoints iteration of TacsUnsteadyInterface
• Write unit tests with TestAerodynamicSolver + TacsUnsteadyInterface and a funtofem driver on top

• no longer pass in tacs aim or store it, just get it from tacs model
• only have one prime_loads method
• option to prime from funtofem driver or fun3d oneway driver

• old adjoint tests in examples directory are deprecated
• cleanup folder structure

Clean up python import statements across FUNtoFEM to be more specific; avoid importing with "*".

• fun3d flow and adjoint iterate calls seem to take in step number but we don't provide them
• double check this

Trying to import a funtofem module:
from funtofem.model import FUNtoFEMmodel, Variable, Scenario, Body, Function

results in:
ModuleNotFoundError: No module named 'mphys'

Seems like a dependency upon 'mphys' may have worked its way in?

It seems like there are some variables in the Makefile.in.info that aren't being used. At least grep-ing for them across the project doesn't turn up any other uses.

PYTHON_INCLUDE
PYTHON_LIB
NUMPY_DIR
MPI4PY_DIR
F2F_LIB
F2F_LD_FLAGS

Consider removing if no longer necessary?

• speaks for itself mostly
• may need to add a low_fidelity in_house aero solver or from another source to the piston theory so that we can have reasonable examples
• figure out where to store fun3d examples

• Make a more realistic piston theory interface that operates on the structure geometry (aero_X copied from struct_X)
• Make examples using the piston theory interface in the github examples/ folder
• Include optimization, analysis, steady/unsteady, etc. for these examples
• Maybe also include a panel method for base pressure distribution and then piston theory for aeroelastic contributions to pressure

• In new work on tacs unsteady interface and unit tests, the aeroelastic passes to 1e-7 while aerothermal and aerothermoelastic derivatives only get to 1e-3 rel error

Right now, transfer scheme files are not included in pyFUNtoFEM but are located separately in FUNtoFEM. However, the transfer schemes are a necessary component to make pyFUNtoFEM run and so should be included in any package or distribution of pyFUNtoFEM.

Numpy import error when building funtofem after make interface step found by @A-CGray.

pip install -e .
Obtaining file:///home/sengelstad6/git/funtofem
  Preparing metadata (setup.py) ... error
  error: subprocess-exited-with-error
  
  × python setup.py egg_info did not run successfully.
  │ exit code: 1
  ╰─> [6 lines of output]
      Traceback (most recent call last):
        File "<string>", line 2, in <module>
        File "<pip-setuptools-caller>", line 34, in <module>
        File "/home/sengelstad6/git/funtofem/setup.py", line 6, in <module>
          import numpy
      ModuleNotFoundError: No module named 'numpy'
      [end of output]
  
  note: This error originates from a subprocess, and is likely not a problem with pip.
error: metadata-generation-failed

× Encountered error while generating package metadata.
╰─> See above for output.

note: This is an issue with the package mentioned above, not pip.
hint: See above for details.
make: *** [Makefile:37: interface] Error 1

@sean-engelstad (myself) found a solution to this issue with the following conda installation steps. Should we add a note to the README about this or is there another fix?
Pre-build steps

conda create -n F2F python=3.8
conda activate F2F
conda install -c conda-forge numpy mpi4py cython
conda install gxx_linux-64=9.3.0 -q -y

Then you either do the real build

cd ~/git/funtofem
make clean
make
make interface

Or the complex-mode build

cd ~/git/funtofem
make clean
make complex
make complex_interface

• OptimizationManager class should only have to take in the driver and will copy comm, model args from attributes of the driver.

• Move FuntofemComponent class for OpenMDAO into the pyfuntofem/optimization folder since it is for optimization