smdogroup / funtofem Goto Github PK
View Code? Open in Web Editor NEWAdaptable framework for aerothermoelastic analysis and adjoint-based gradient evaluation
License: Apache License 2.0
Adaptable framework for aerothermoelastic analysis and adjoint-based gradient evaluation
License: Apache License 2.0
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.
Need to add options for symmetry boundary conditions in the available BC's to pass to AFLR.
TacsOnewayDriver
classLet TS be Transfer scheme
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
TODO
: try this with the diamond wedge case in node 1, y and z directions (two separate runs)Clean up python import statements across FUNtoFEM to be more specific; avoid importing with "*".
Add aims/wrappers into main funtofem driver and use class methods or a subclass called funtofem shape driver.
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.
I cloned the funtofem
repository.
I created a new Python virtual environment and installed numpy
, cython
, and mpi4py
in it.
I installed FUNtoFEM using make
and make interface
.
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.
SolverInterface
class, as I would if I were developing a new interface.from pyfuntofem import SolverInterface
print('Hello, world!')
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.
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
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
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.caps2tacs
and caps2fun
automatically if you choose external_shape=False
.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?
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.
TacsSteadyInterface
or TacsUnsteadyInterface
using create_from_bdfNeed a way to classify the phases of the design history into:
Solutions: could think of some mathematical rules, use machine learning.
Alternative but weaker resolutions:
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)
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.
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
xa0
and xs0
TacsOnewayDriver
were off by 100%. Aerothermoelastic was very off tooIt 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?
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.
Callback method isn't returning the element callback inside the outer function.
Fun3dAeroDriver
that optimizes over aerodynamic analysis and aero DVs onlyA 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.