smdogroup / tacs

Finite-element library for analysis and adjoint-based gradient evaluation

TACS Overview

The Toolkit for the Analysis of Composite Structures (TACS) is a parallel finite-element code for analysis and gradient-based design of advanced structures. Originally, TACS was primarily designed as a tool for the analysis of shell structures, such as wing-boxes. More recently it has been extended to perform topology optimization of large three-dimensional structures using gradient-based methods.

TACS has been under continuous development since 2010 by the Structural and Multidisciplinary Design Optimization group at Georgia Tech and by the Multidisciplinary Design Optimization Lab at the University of Michigan.

Online documentation and examples are located at https://smdogroup.github.io/tacs/

How to cite TACS

If you use TACS, please cite one or more of the following papers.

This paper describes the time-dependent flexible multibody dynamics and adjoint capabilities implemented in TACS:

K. Boopathy and G. J. Kennedy. "Parallel Finite Element Framework for Rotorcraft Multibody Dynamics and Discrete Adjoint Sensitivities", 2019, https://doi.org/10.2514/1.J056585

This paper describes the core functionality of TACS, including the adjoint-based gradient evaluation techniques it implements:

Kennedy, G. J. and Martins, J. R. R. A, "A parallel finite-element framework for large-scale gradient-based design optimization of high-performance structures", Finite Elements in Analysis and Design, 2014, doi:http://dx.doi.org/10.1016/j.finel.2014.04.011

These papers describe in detail the aggregation functional implementation in TACS:

Kennedy, G. J. and Hicken, J. E., "Improved Constraint-Aggregation Methods", Computer Methods in Applied Mechanics and Engineering, 2015, doi:http://dx.doi.org/10.1016/j.cma.2015.02.017

Kennedy, G. J., "Strategies for adaptive optimization with aggregation constraints using interior-point methods", 2015, doi:http://dx.doi.org/10.1016/j.compstruc.2015.02.024

Setting up and installing TACS through anaconda

The easiest way to get started with TACS is through a conda install in an Anaconda environment. Conda packages are available for MacOS and Linux platforms. To get started, run the following in a conda terminal:

conda create -n TACS -c conda-forge python=3.9 mamba
conda activate TACS
mamba install -c conda-forge -c smdogroup tacs

This will create an environment named "TACS" and install the tacs package and all necessary dependencies. Once installed, the user will have access to all TACS C++ and python libraries.

The best way to get started is to check out and run the files in the examples/ folder. For instance, running the script under the examples/crm directory:

mpirun python analysis.py

The conda install also sets up the f5totec and f5tovtk executables in the user's conda environment. So TACS-generated .f5 solution files can be converted into a format for viewing in Tecplot or Paraview using the following respective commands:

f5totec cruise_000.f5

or

f5tovtk cruise_000.f5

This will generate a .plt or .vtk file respectively.

Setting up and installing TACS from source

In addition to a working implementation of MPI, BLAS and LAPACK, TACS requires Metis 5.1.0 for mesh partitioning. The 5.1.0 version of Metis can be obtained here. TACS can optionally use the approximate minimum degree ordering routines from AMD/UFConfig. These were distributed separately, but can now be obtained from SuiteSparse package. If you use AMD, be sure to define the TACS_HAS_AMD_LIBRARY flag within the Makefile.in configuration file.

To convert TACS FH5 output files to tecplot-compatible files, you must install TecIO. This can be placed in the tacs/extern directory. There is also a FH5 to VTK converter as well that produces (large) ASCII files.

Once the external dependencies are installed, copy Makefile.in.info to Makefile.in. Open Makefile.in and follow the directions within to set the variables. In particular, set the following:

1. TACS_DIR: the root directory of TACS
2. CXX: the C++ compiler - must be MPI-enabled
3. LAPACK_LIBS: the linking arguments for the LAPACK libraries
4. METIS_INCLUDE/METIS_LIB: the include/linking arguments for METIS
5. AMD_INCLUDE/AMD_LIBS: the include/linking arguments for AMD

Note that the default values can often be used without modification. Of all these options, it is most important for performance reasons to link to an optimized version of LAPACK, if possible.

The C++ interface can then be compiled by running the make command from the tacs root directory:

make

Setting up the Python interface

The python interface can be installed after the C++ interface has been compiled. The python interface (and all dependencies) can be created with a call to setup.py. The setup.cfg.info contains the recommended defaults for the configuration script. For development, create a local development installation by executing

pip install -e .\[all\]

This command is also executed by the command make interface.

If the user does not intend to modify the source code and wishes to install the interface to their python site-packages, they can instead run

pip install .\[all\]

Converting FH5 files

The utility f5totec can be used to convert the .f5 files generated by TACS to tecplot .plt files. This utility is located under tacs/extern/f5totec/. I find it convenient to create a symbolic link to f5totec in a bin directory.

Building docs

In addition to the publicly hosted docs (available here), users can build the TACS docs locally. Source code for the docs are located under the docs directory. To compile the docs in html format, run the following command from the docs directory:

make html BUILDDIR=.

The docs can then be viewed by opening the index.html file:

open ./html/index.html

Contributing to TACS development

We welcome users who wish to propose new bugfixes/feature additions for the TACS codebase. All propositions for feature additions should be made as a pull request (PR) through TACS' GitHub page. PR's should be succinct in describing the fix/feature they intend to add, and the code changes should pertain to that specified goal (avoid feature creep). Before finalizing their PR, we ask that developers run the following checks on their end:

1. Ensure that your modification works when TACS is compiled both in real (default) and complex mode. TACS can be compiled in complex mode using the following command:

   make complex; make complex_interface
   

2. Ensure that none of TACS current capabilities have been broken by running all unit tests (in real and complex mode) using Testflo. Testflo can be run by calling the following command from TACS' root directory:

   testflo ./tests
   

3. Add unit/integration tests that include coverage for any features that have been added to TACS' test library.
4. Run formatting checks on any modified C++ source/header code using clang-format.

   clang-format --style=Google -i filename.cpp
   

5. Run formatting checks on any modified Python code using Black.

   python -m black filename.py
   

6. If the change is a new feature, make sure that its expected use is described through a docstring and that it is added in a relevant section of the docs

tacs's Issues

tacs.constitutive.MaterialProperties method getMaterialProperties does not retrieve density

Looks like an easy fix in constitutive.pyx - I think the title says it all but rho is not retrieved with the method.

Add transient solver to MPHYS module

Issue Type

• Bug
• Enhancement

Description

We need to add a wrapper for the TransientProblem class to the mphys module library, for easier interface with OpenMDAO.
Ideally, this would implemented as a separate mphys builder, similar to what is currently done for StaticProblem.
For now, this transient builder doesn't need to support coupling, so an ExplicitComponent implementation would be acceptable.

Example

N/A

Environment

N/A

Seeding random number generator in checkNonLinear routine

The checkNonLinearRoutine uses a RNG to initialize a state variable vector to use in its procedure. This RNG isn't seeded and can therefore result unpredicted and unrepeatable behavior (even rarely), making debugging intermittently failing unit tests very difficult. To fix this the RNG should be seeded before being used in the routine, see the element tests for example.

Conda installation not up to date

I've noticed that the Anaconda install isn't current to the source code - when I tried to run buckling examples I found that the Buckling class can't be imported on my conda install (and isn't in the site-packages/tacs folder) but if I download the source then it is there.

Windows install instructions

Are there any Windows install instructions for TACs? I didn't explicitly see it stated that it's linux/OSX only, however I did see that there are only conda builds for those two so I wasn't sure

Orthotropic heat conduction in shell elements

Hi,

I believe the current version can handle heat conduction problems with isotropic thermal conductivities (kappa). Specifying kappa1 and kappa2 instead of kappa will resort to the predefined value of kappa in the code. Is there a way to use kappa1 and kappa2 in 2D and kappa1, kappa2 and kappa3 in 3D conduction problems?

Thanks,
Pranav

Tutorials for the other stiffness properties

Hi, there!

Sorry to ask this question.

I have a quick scan and learning about the TACS. It is a quite valuable structural analysis solver using the adjoint method.

During the study, I find several direct cases which use isoFSDTStiffness (a first-order shear deformation theory type element) properties. I am wondering if there are any other test cases for different type of elements, like the composite structure (as the meaning of the code name, TACS) or blade-stiffened panel (find it in the source code) ?

Just out of personal curiosity, no other meaning.

Initial conditions for transient problems

The current implementation of TransientProblem requires the setting of initial conditions via the setInitConditions() function. In this function the user can directly set all three initial conditions for states, first time derivative states, and second time derivative states. When integrating in time with TACSIntegrator, the initial states are copied directly for the initial time step. This doesn't seem correct, since at least one of the sets of states should be solved for at initial time through the solution of the ODE. Talking with @timryanb, he noted that this issue also changes depending on the type of analysis being done, elastic vs. thermal, since the thermal problem is first-order while the elastic problem is second-order.

For example, consider a transient elastic problem where the initial displacement and velocity are set to zero. For the case where there is a nonzero force at initial time, then the initial acceleration states would be nonzero and need to be solved for. However, if the user specified them to be zero like the displacement and velocity, then the initial acceleration states would be incorrect. This mismatch in initial states negatively affects the time marching solution. Starting from incorrect initial states will ruin the time-order accuracy of the time-marching scheme, so if high-order schemes like DIRK or ESDIRK are being used then this would be a problem.

Is this a known issue? Is there a reason behind the current implementation or a way to set up the transient problem to avoid this issue?

Using `getMat` within function results in segfaults

As part of #139 , I was trying to write a test which involved retrieving the Jacobian from a pytacs problem using the getMat method, which returns the matrix as a scipy BCSR matrix. However, I ran into segfaults whenever the matrix gets garbage collected, below is a minimal working example:

def test_mwe(self):
        """The function runs fine, but segfaults on exit"""
        prob = self.tacs_probs[0]
        mat = prob.K.getMat()

It seems like this segfault occurs whenever the result of getMat is garbage collected before the TACS matrix is, putting the same mat = prob.K.getMat() inside a couple of the examples scripts didn't cause any segfaults, but if it is done inside a function within a runscript then it does:

k = problem.K.getMat() # This call does not cause a segfault

def dummyFunc():
    k = problem.K.getMat()
    return
dummyFunc() # This one does

Add tests for MPHYS module

Issue Type

• Bug
• Enhancement

Description

Integration tests should be added for mphys wrapper to ensure functionality is maintained.

Example

N/A

Environment

N/A

Document parallel tacsAIM in caps2tacs

Segmentation fault with f5totec/f5tovtk

Hello,

I followed the instructions in the documentation to install tacs in with conda in a linux machine. Everything seems to be installed properly, but when I try to convert my f5 file using either fttotec or f5tovtk I get an exception:

(TACS) -bash-4.4$ f5tovtk solution.f5
Trying to convert FH5 file solution.f5 to vtk file solution.vtk
Segmentation fault (core dumped)

(TACS) -bash-4.4$ f5totec solution.f5
Trying to convert FH5 file solution.f5 to tecplot file solution.plt
Segmentation fault (core dumped)

I am using version tacs v. 3.2.0

In the case of f5tovtk I see that an empty file is created with the name solution.vtk, f5totec does not even create an output file.

Do you have any suggestions on how to solve this? I looked for tests on the source code but I could not find any.

Thanks in advance.

Numpy cannot be recognized and tests failed

Hi Guys,
I am working on the compiling on a cluster and errors appeared during the compiling process. I describe them here.

I can cmake the openfast successfully.
I then make it with error : Fatal Error: Cannot read module file 'pfunit_mod.mod' opened at (1), because it was created by a different version of GNU Fortran, compilation terminated.
After that I cannot run the utest and regression test.
However, the openfast and submodules have been compiled and built normally. I can run an example in the regression test successfully by manual. I try to run the regression test manually, but it showed fails with the message of lacking of Numpy.
I actually installed the Numpy as mentioned in the #384 by Andy, but the cluster shell environment can not recognize it even I tried to export it to the shell. The installed Numpy contains bin and lib folders with only three files in the bin. Can someone give me a hand on how to fix this problem? Thank You！

Non-determinism in primal solution and derivatives

When running a coupled aerostructural derivative check with DAFoam and MELD through MPhys, we noticed that identical runs of the same script / case led to different analytic derivatives (ignore the FD check, that is due to generally poor, but consistent convergence from DAFoam):

Run 1: 
Full Model: 'maneuver.struct_post.eval_funcs.ks_vmfailure' wrt 'dvs.sweep_wing'
     Reverse Magnitude: 1.176269e-03
          Fd Magnitude: 6.548034e-04 (fd:forward)

Run 2:
Full Model: 'maneuver.struct_post.eval_funcs.ks_vmfailure' wrt 'dvs.sweep_wing'
     Reverse Magnitude: 1.527612e-03
          Fd Magnitude: 6.548034e-04 (fd:forward)

We were not sure where this came from and tried to check the aero solver, load and displacement transfer, and structural solver. In the primal solve, we found slight differences between the results only after the first pass of the structural solution. We started printing out the norm of the flattened values passing through MELD. The first pass through the load transfer is consistent between runs:

Run 1: 
MELD Primal Load Transfer x_struct0 24702.433470988755
MELD Primal Load Transfer x_aero0 23658.198184194116
MELD Primal Load Transfer u_struct 0.0
MELD Primal Load Transfer f_aero 8100.573476032763
MELD Primal Load Transfer f_struct 1700.082296927264

Run 2:
MELD Primal Load Transfer x_struct0 24702.433470988755
MELD Primal Load Transfer x_aero0 23658.198184194116
MELD Primal Load Transfer u_struct 0.0
MELD Primal Load Transfer f_aero 8100.573476032763
MELD Primal Load Transfer f_struct 1700.082296927264

But, the pass back through the displacement transfer receives a different vector of displacements, leading to a slightly different converged aerostructural solution:

Run 1: 
MELD Primal Disp Transfer x_struct0 24702.433470988755
MELD Primal Disp Transfer x_aero0 23658.198184194116
MELD Primal Disp Transfer u_struct 47.00897156793725
MELD Primal Disp Transfer u_aero 33.24244380757927

NL: NLBGS 5 ; 219.13182 1.42895947e-06 

Run 2:
MELD Primal Disp Transfer x_struct0 24702.433470988755
MELD Primal Disp Transfer x_aero0 23658.198184194116
MELD Primal Disp Transfer u_struct 47.00897157165467
MELD Primal Disp Transfer u_aero 33.24244381025362

NL: NLBGS 5 ; 219.131819 1.42895946e-06

We then started looking at simpler cases and found that TACS-only primal solves are deterministic up to 8 digits, especially when running in parallel. @A-CGray and I reproduced this on his computer as well, and found that typically 3+ procs were problematic, but serial cases run with python <scripy>.py were also nondeterministic on one day, but fine the next.

I tried out several of the examples to see which were deterministic, and @A-CGray scripted this on his computer as well using the following:

randVec = problem.assembler.createVec()
randVec.setRand()

for _ in range(20):
    problem.setVariables(randVec)
    # Solve state
    problem.getResidual(problem.res)
    initResNorm = problem.res.norm()
    problem.solve()
    uNorm = problem.u.norm()
    if comm.rank==0:
        print(f"{problem.name:>10s}: {uNorm=:.16e}, {initResNorm=:.16e}")

The test was to run the solver repeatedly with the same starting point and see if it was consistent. This led to the following results:

Output from slot_3d example


[9] TACSBlockCyclicMat: (6423,6423) Initial density: 0.832 factor fill in: 0.119
load_set_000: uNorm=3.1102406253022369e-03, initResNorm=4.5878651244647644e+10
load_set_000: uNorm=3.1102406123293758e-03, initResNorm=4.5878651244647644e+10
load_set_000: uNorm=3.1102406123293758e-03, initResNorm=4.5878651244647644e+10
load_set_000: uNorm=3.1102405960886136e-03, initResNorm=4.5878651244647644e+10
load_set_000: uNorm=3.1102406234748215e-03, initResNorm=4.5878651244647644e+10
load_set_000: uNorm=3.1102406229065651e-03, initResNorm=4.5878651244647644e+10
load_set_000: uNorm=3.1102406001658109e-03, initResNorm=4.5878651244647644e+10
load_set_000: uNorm=3.1102406133390252e-03, initResNorm=4.5878651244647644e+10
load_set_000: uNorm=3.1102406123291494e-03, initResNorm=4.5878651244647644e+10
load_set_000: uNorm=3.1102406141400342e-03, initResNorm=4.5878651244647644e+10
load_set_000: uNorm=3.1102406437929267e-03, initResNorm=4.5878651244647644e+10
load_set_000: uNorm=3.1102406079585327e-03, initResNorm=4.5878651244647644e+10
load_set_000: uNorm=3.1102406018139010e-03, initResNorm=4.5878651244647644e+10
load_set_000: uNorm=3.1102406079068340e-03, initResNorm=4.5878651244647644e+10
load_set_000: uNorm=3.1102406123293758e-03, initResNorm=4.5878651244647644e+10
load_set_000: uNorm=3.1102406045341430e-03, initResNorm=4.5878651244647644e+10
load_set_000: uNorm=3.1102406196805662e-03, initResNorm=4.5878651244647644e+10
load_set_000: uNorm=3.1102406217764444e-03, initResNorm=4.5878651244647644e+10
load_set_000: uNorm=3.1102406022091790e-03, initResNorm=4.5878651244647644e+10
load_set_000: uNorm=3.1102406003855588e-03, initResNorm=4.5878651244647644e+10

The initial residual is consistent, but the norm of the solution is not. We tried many of the examples and found that:

Deterministic:

• Spring mass
• Beam
• Annulus (floating point exception with 16 procs)

Non-deterministic when run on >3-4 cores:

• CRM
• Fuselage
• MACH tutorial wing
• Plate
• Slot_3d

Out of curiosity, I tried the CRM example with Valgrind and found that with 16 procs there were two invalid reads. Fewer proc counts did not have this issue, but Valgrind might also miss invalid reads depending on if the memory is allocated or not.

==796863== Invalid read of size 4
==796863== at 0x6099B8B9: TACSBlockCyclicMat::get_block_owner(int, int) const (TACSBlockCyclicMat.h:142)
==796863== by 0x60992954: TACSBlockCyclicMat::merge_nz_pattern(int, int*, int*, int) (TACSBlockCyclicMat.cpp:554)
==796863== by 0x60990A07: TACSBlockCyclicMat::TACSBlockCyclicMat(ompi_communicator_t*, int, int, int, int const*, int, int const*, int const*, int, int, int) (TACSBlockCyclicMat.cpp:177)
==796863== by 0x609ABE04: TACSSchurPc::TACSSchurPc(TACSSchurMat*, int, double, int) (TACSSchurMat.cpp:1096)
==796863== by 0x6077EA3D: __pyx_pf_4tacs_4TACS_2Pc___cinit__ (TACS.cpp:34395)
==796863== by 0x6077EA3D: __pyx_pw_4tacs_4TACS_2Pc_1__cinit__ (TACS.cpp:34155)
==796863== by 0x6077EA3D: __pyx_tp_new_4tacs_4TACS_Pc(_typeobject*, _object*, _object*) (TACS.cpp:89770)
==796863== by 0x2589C6: _PyObject_MakeTpCall (in /usr/bin/python3.10)
==796863== by 0x25214F: _PyEval_EvalFrameDefault (in /usr/bin/python3.10)
==796863== by 0x2629FB: _PyFunction_Vectorcall (in /usr/bin/python3.10)
==796863== by 0x24B45B: _PyEval_EvalFrameDefault (in /usr/bin/python3.10)
==796863== by 0x257C13: _PyObject_FastCallDictTstate (in /usr/bin/python3.10)
==796863== by 0x26CB04: ??? (in /usr/bin/python3.10)
==796863== by 0x258A1B: _PyObject_MakeTpCall (in /usr/bin/python3.10)

==796863== Address 0xc66f0b6c is 4 bytes before a block of size 60 alloc’d
==796863== at 0x484A2F3: operator new[](unsigned long) (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==796863== by 0x6099385F: TACSBlockCyclicMat::init_proc_grid(int) (TACSBlockCyclicMat.cpp:777)
==796863== by 0x609902AA: TACSBlockCyclicMat::TACSBlockCyclicMat(ompi_communicator_t*, int, int, int, int const*, int, int const*, int const*, int, int, int) (TACSBlockCyclicMat.cpp:87)
==796863== by 0x609ABE04: TACSSchurPc::TACSSchurPc(TACSSchurMat*, int, double, int) (TACSSchurMat.cpp:1096)
==796863== by 0x6077EA3D: __pyx_pf_4tacs_4TACS_2Pc___cinit__ (TACS.cpp:34395)
==796863== by 0x6077EA3D: __pyx_pw_4tacs_4TACS_2Pc_1__cinit__ (TACS.cpp:34155)
==796863== by 0x6077EA3D: __pyx_tp_new_4tacs_4TACS_Pc(_typeobject*, _object*, _object*) (TACS.cpp:89770)
==796863== by 0x2589C6: _PyObject_MakeTpCall (in /usr/bin/python3.10)
==796863== by 0x25214F: _PyEval_EvalFrameDefault (in /usr/bin/python3.10)
==796863== by 0x2629FB: _PyFunction_Vectorcall (in /usr/bin/python3.10)
==796863== by 0x24B45B: _PyEval_EvalFrameDefault (in /usr/bin/python3.10)
==796863== by 0x257C13: _PyObject_FastCallDictTstate (in /usr/bin/python3.10)
==796863== by 0x26CB04: ??? (in /usr/bin/python3.10)
==796863== by 0x258A1B: _PyObject_MakeTpCall (in /usr/bin/python3.10)

To summarize:

• The initial residual is deterministic even when the solution is not
• The non-determinism is independent of element type / constitutive model
• Tightening the solver tolerance has no effect, nor does lowering compiler optimization
• Happens reliably with large, parallel problems (nproc > 2) (but, also happened in serial at times)

Other notes:

• We looked into the preconditioner and stiffness matrices and computed min / max / mean values, and these values were deterministic even when the results were not

Eigenvalue solver tests failing intermittently

One of the integration tests that relates to the eigenvalue solver ( test_shell_plate_modal.py) seem to fail intermittently. See these runs (here and here) for example.

The current theory is that the sporadic nature of the failure is being caused by the random number generator used in the GSEP algorithm here. Seeding the random number generator before running these tests may be a good way of fixing the issue.

Expose finite difference step size as an option in buckling problem

Would it be possible to expose the finite difference step size as a keyword argument when setting up a buckling problem? I think this could help resolve the issue of discrepancies between load factors/buckling modes between TACS and commercial codes.

Constructor Flexibility in caps2tacs with tacsAIM

• Create class methods for tacs aim and egads aim wrapper classes from the aims on root proc
• user could build these aims with dict of dicts on root proc, set to None on other procs
• Auto create caps2tacs objects by reading the dict of dicts of tacsAim.input.Load, tacsAim.input.Design_Variable, etc
• change constructor args for tacs aim to be aim with aim on root and None on other procs not caps problem object

Thermal Stress and Buckling Capability

It would be nice to have thermal buckling capability since it would aid in performing coupled thermal-structural analysis, including thermal stability. If TACS has the capability currently to perform static thermoelastic analysis, I believe thermal buckling can be directly done by using the differential stiffness generated with the stresses obtained from the thermoelastic analysis.

Initialize/Update pyTACS FEAAssembler from BDF object?

Is there a way to initialize or update a pyTACS object from a pyNastran BDF instance, rather than a BDF file?

I'm looking to run a large number of thermal deformation cases for various trade studies, and the runs only differ in initial temperature constraints.

Right now, for each run we are saving a separate BDF file with different SPC temperature cards assigned to it before running TACS. This is getting inefficient as our number of cases grows the file I/O becomes a large fraction of the runtime.

Optimization examples cannot be run due to not being updated for a long time

tacs/examples/crm/crm_opt.py cannot execute
There are still many unresolved issues with modifying this file based on the latest version of TACS.

For instance，
‘’‘
def getVarsAndBounds(self, x, lb, ub):
"""Set the values of the bounds"""
xvals = np.zeros(self.nvars, TACS.dtype)
self.assembler.getDesignVars(xvals)
x[:] = self.thickness_scale * xvals

    xlb = np.zeros(self.nvars, TACS.dtype)
    xub = np.zeros(self.nvars, TACS.dtype)
    self.assembler.getDesignVarRange(xlb, xub)
    lb[:] = self.thickness_scale * xlb
    ub[:] = self.thickness_scale * xub

’‘’
self.assembler.getDesignVars(xval)
TypeError: Argument 'x' has incorrect type (expected tacs.TACS.Vec, got numpy.ndarray)

I haven't found a solution yet. If you can update the optimization case, thank you very much！

Add ability to write out multiple failure values in f5

Probably something like how dv outputs are currently handled (failure0, failure1, etc.).

Document MPHYS interface

Issue Type

• Bug
• Enhancement

Description

Add documentation for new MPHYS interface

Example

N/A

Environment

N/A

Request: Add ESP/CAPS version check to caps2tacs tests

We're having issues updating the version of TACS used in our docker images because we currently use ESP120, which seems to be incompatible with caps2tacs:

Information: Dynamic Loader Error for tacsAIM.so
              tacsAIM.so: cannot open shared object file: No such file or directory
 EGADS Info: 0 Objects, 0 Reference in Use (of 0) at Close!
./tests/integration_tests/test_caps_thick_derivatives.py:TestCaps2TacsSizing.test_thickness_derivatives  ... FAIL (00:00:0.03, 252 MB)
Traceback (most recent call last):
  File "/home/***/repos/tacs/./tests/integration_tests/test_caps_thick_derivatives.py", line 31, in test_thickness_derivatives
    tacs_model = caps2tacs.TacsModel.build(
  File "/home/***/repos/tacs/tacs/caps2tacs/tacs_model.py", line 66, in build
    tacs_aim = TacsAim(caps_problem, comm)
  File "/home/***/repos/tacs/tacs/caps2tacs/tacs_aim.py", line 34, in __init__
    self._build_aim(caps_problem)
  File "/home/***/repos/tacs/tacs/caps2tacs/proc_decorator.py", line 12, in wrapped_method
    return method(self, *args, **kwargs)
  File "/home/***/repos/tacs/tacs/caps2tacs/tacs_aim.py", line 57, in _build_aim
    self._aim = caps_problem.analysis.create(aim="tacsAIM", name="tacs")
  File "/home/***/packages/ESP120/EngSketchPad/pyESP/pyCAPS/problem.py", line 2779, in create
    analysisObj = self._problemObj.makeAnalysis(aim,
  File "/home/***/packages/ESP120/EngSketchPad/pyESP/pyCAPS/caps.py", line 1705, in makeAnalysis
    _raiseStatus(stat, msg=msg, errors=capsErrs(nErr, errs))
  File "/home/***/packages/ESP120/EngSketchPad/pyESP/pyCAPS/caps.py", line 758, in _raiseStatus
    raise CAPSError(status, msg=msg, errors=errors)
pyCAPS.caps.CAPSError: EGADS_NULLOBJ: Failed to make AIM 'tacsAIM' with name 'tacs':

Would it be possible to add a check, either to the caps2tacs tests or to the module itself, so that the caps2tacs tests will be skipped not only if CAPS is not installed, but also if the CAPS version is incompatible with caps2tacs?

TACS' cython interface is not compatible with the latest major version

Cython just created a new major release, moving from v0.29 to v3.0.0, the current TACS cython interface does not compile with the new version (see #228 ).

There is a guide for migrating from cython 0.29 to 3.0 here which might be useful for fixing this

Demonstrate Exploded Views in caps2tacs

• rewrite caps2tacs examples with rule instead of loft (check sensitivities still work with that and if not then temporarily use blend)
• Add a script that creates exploded views as a demonstration

Building f5totec cannot link against libtacs

Attempting to build f5totec (e.g. cd extern/f5totec; make), the build seems to not be set up correctly to link the tacs library as shown by the following link error:

mpicxx f5totec.o /home/minion/local/tecio/install/libtecio*.a  -L/lib/ -Wl,-rpath,/lib -ltacs  /home/minion/local/metis/lib/libmetis.a -L/opt/intel/oneapi/mkl/2023.0.0/lib/intel64 -L/opt/intel/oneapi/mkl/2023.0.0/../../compiler/latest/linux/compiler/lib/intel64_lin -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -liomp5 -o f5totec
/usr/bin/ld: cannot find -ltacs
collect2: error: ld returned 1 exit status
make: *** [Makefile:9: f5totec] Error 1

I was able to fix by amending extern/f5totec/Makefile to include -L../../lib so that the linker would have visibility to the tacs library. I don't know if that is the preferred approach or if one should be building it differently.

Compiler errors for -std=C++17 compilers

I tried compiling TACS with the recent changes on my local machine (Apple clang version 15.0.0) and an HPC machine (icc (ICC) 18.0.3 20180410) but received compiler errors in TACSElementVerification, for the same lines of code (with slightly different errors depending on compiler). It seems to be related to the recent nonlinear solver PR.

On Apple clang (M2 chip):

tacs/src/elements/TACSElementVerification.cpp:23:8: error: 'auto' not allowed in function return type
inline auto TacsGetMatrixTypeName(ElementMatrixType matType) {
       ^~~~
tacs/src/elements/TACSElementVerification.cpp:26:14: error: cannot initialize return object of type 'int' with an lvalue of type 'const char[16]'
      return "Jacobian Matrix";
             ^~~~~~~~~~~~~~~~~
tacs/src/elements/TACSElementVerification.cpp:29:14: error: cannot initialize return object of type 'int' with an lvalue of type 'const char[12]'
      return "Mass Matrix";
             ^~~~~~~~~~~~~
tacs/src/elements/TACSElementVerification.cpp:32:14: error: cannot initialize return object of type 'int' with an lvalue of type 'const char[17]'
      return "Stiffness Matrix";
             ^~~~~~~~~~~~~~~~~~
tacs/src/elements/TACSElementVerification.cpp:35:14: error: cannot initialize return object of type 'int' with an lvalue of type 'const char[27]'
      return "Geometric Stiffness Matrix";
             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
tacs/src/elements/TACSElementVerification.cpp:38:14: error: cannot initialize return object of type 'int' with an lvalue of type 'const char[29]'
      return "Stiffness Product Derivative";
             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
tacs/src/elements/TACSElementVerification.cpp:41:10: error: cannot initialize return object of type 'int' with an lvalue of type 'const char[20]'
  return "Unknown Matrix Type";
         ^~~~~~~~~~~~~~~~~~~~~

On Linux machine with Intel compiler:

/tacs/src/elements/TACSElementVerification.cpp(23): error: invalid storage class for an inline function
  inline auto TacsGetMatrixTypeName(ElementMatrixType matType) {
         ^

/tacs/src/elements/TACSElementVerification.cpp(23): error #303: explicit type is missing ("int" assumed)
  inline auto TacsGetMatrixTypeName(ElementMatrixType matType) {
              ^

/tacs/src/elements/TACSElementVerification.cpp(26): error: return value type does not match the function type
        return "Jacobian Matrix";
               ^

/tacs/src/elements/TACSElementVerification.cpp(29): error: return value type does not match the function type
        return "Mass Matrix";
               ^

/tacs/src/elements/TACSElementVerification.cpp(32): error: return value type does not match the function type
        return "Stiffness Matrix";
               ^

/tacs/src/elements/TACSElementVerification.cpp(35): error: return value type does not match the function type
        return "Geometric Stiffness Matrix";
               ^

/tacs/src/elements/TACSElementVerification.cpp(38): error: return value type does not match the function type
        return "Stiffness Product Derivative";
               ^

/tacs/src/elements/TACSElementVerification.cpp(41): error: return value type does not match the function type
    return "Unknown Matrix Type";

Break up MPhys wrapper

The mphys_tacs.py file under tacs/mphys is getting a bit long and probably could be better named.
For better readability, we should break the file down into smaller submodules (builder.py, solver.py, functions.py?) with each component living in its own file. We can still keep the import statement at the user level the same using the __init__.py (i.e. from tacs.mphys import TacsBuilder)

Clean up Python setup procedure

Issue Type

• Bug
• Enhancement

Description

Cleanup Python setup procedure so that it is consistent with typical Python libraries. Right now, the only install option that is supported is in-place.

Example

pip install . should correctly install all TACS modules and library dependencies to the user's site-packages

Environment

N/A

KSM Solver choice and iteration count

We currently have an implementation of a nonlinear solver which works with the old version of TACS that I am attempting to transfer over to this newer version. In our solver, we check the number of iterations taken during each linear solve in order to decide whether to update the preconditioner. This was done using a getIterCount method inside the GCROT class, this method was not implemented in the GMRES or PCG classes although as far as I can see there is an iteration counting variable that could be output.

The problem I am running into now is that although GCROT, GMRES and PCG are all still defined in KSM.cpp, the python interface is currently hardcoded to return a GMRES object when asked for a KSM:

cdef class KSM:
    def __cinit__(self, Mat mat, Pc pc, int m,
                  int nrestart=1, int isFlexible=0):
        '''
        Create a GMRES object for solving a linear system with or
        without a preconditioner.

        This automatically allocates the requried Krylov subspace on
        initialization.

        input:
        mat:        the matrix operator
        pc:         the preconditioner
        m:          the size of the Krylov subspace
        nrestart:   the number of restarts before we give up
        isFlexible: is the preconditioner actually flexible? If so use FGMRES
        '''

        self.ptr = new GMRES(mat.ptr, pc.ptr, m, nrestart, isFlexible)
        self.ptr.incref()
        return

    def __dealloc__(self):
        if self.ptr:
            self.ptr.decref()
        return

I therefore have 2 questions:

• Are there some bugs with GCROT and PCG that are behind the reason for making only GMRES available through the python interface?
• If not, do you have anything against me adding the functionality to choose different KSM's through the interface and also adding a getIterCount method to each one?

Thanks

Ali

F5 Interpolation Bug for Coarse Meshes

• Interpolated dv1 values are alternating large positive and negative values
• The thickness values printed out into the F5/VTK files don't match the design variables in the TACSIsoShellConstitutive class whatsoever. The actual design variable values are sensible.
• Most likely just a visualization or interpolation problem in the post-processing step. Or it's not a bug and you just need a finer mesh, but that seems like a poor solution.

Add more examples to docs

Issue Type

• Bug
• Enhancement

Description

Add more examples to TACS docs that better demonstrate the variety of typical use cases.
The only current example is a static structural plate analysis.

Example

Some examples of concepts that still need to be discussed:

• Transient analysis
• Modal analysis
• Thermal analysis
• Wingbox example
• Optimization example

Environment

N/A

Implement analytic geometric stiffness calculation for shell elements

The geometric stiffness matrix used in the shell element class is currently approximated by finite differencing along the path of the nonlinear stiffness matrix. This leads to some error, loss in robustness, and speed penalty. Adding a routine to directly compute this matrix directly would eliminate these issues. This would also eliminate the need for #246.

f5toop2 converter

Since we have the ability to access data written in an f5 file in python using the FH5Loader class and pyNastran also has an OP2 writer available, it should be possible to write a relatively simple python script to translate the f5 data into an OP2 file format, which can then be loaded in NASTRAN-compatible commercial FEM software (Patran, FEMAP, etc.). We could make this script run like an executable from command line, so it could be called like f5totec/f5tovtk

installation failed: Cython.Compiler.Errors.InternalError: Internal compiler error: 'TacsDefs.pxi' not found

File "/Users/Sansara/tacs-master/setup.py", line 77, in
ext_modules=cythonize(exts, include_path=inc_dirs))
File "/Users/Sansara/opt/miniconda3/lib/python3.8/site-packages/Cython/Build/Dependencies.py", line 965, in cythonize
module_list, module_metadata = create_extension_list(
File "/Users/Sansara/opt/miniconda3/lib/python3.8/site-packages/Cython/Build/Dependencies.py", line 829, in create_extension_list
kwds = deps.distutils_info(file, aliases, base).values
File "/Users/Sansara/opt/miniconda3/lib/python3.8/site-packages/Cython/Build/Dependencies.py", line 684, in distutils_info
return (self.transitive_merge(filename, self.distutils_info0, DistutilsInfo.merge)
File "/Users/Sansara/opt/miniconda3/lib/python3.8/site-packages/Cython/Build/Dependencies.py", line 693, in transitive_merge
return self.transitive_merge_helper(
File "/Users/Sansara/opt/miniconda3/lib/python3.8/site-packages/Cython/Build/Dependencies.py", line 699, in transitive_merge_helper
deps = extract(node)
File "/Users/Sansara/opt/miniconda3/lib/python3.8/site-packages/Cython/Build/Dependencies.py", line 664, in distutils_info0
cimports, externs, incdirs = self.cimports_externs_incdirs(filename)
File "/Users/Sansara/opt/miniconda3/lib/python3.8/site-packages/Cython/Utils.py", line 54, in wrapper
res = cache[args] = f(self, *args)
File "/Users/Sansara/opt/miniconda3/lib/python3.8/site-packages/Cython/Build/Dependencies.py", line 552, in cimports_externs_incdirs
for include in self.included_files(filename):
File "/Users/Sansara/opt/miniconda3/lib/python3.8/site-packages/Cython/Utils.py", line 54, in wrapper
res = cache[args] = f(self, *args)
File "/Users/Sansara/opt/miniconda3/lib/python3.8/site-packages/Cython/Build/Dependencies.py", line 534, in included_files
include_path = self.context.find_include_file(include, None)
File "/Users/Sansara/opt/miniconda3/lib/python3.8/site-packages/Cython/Compiler/Main.py", line 285, in find_include_file
error(pos, "'%s' not found" % filename)
File "/Users/Sansara/opt/miniconda3/lib/python3.8/site-packages/Cython/Compiler/Errors.py", line 178, in error
raise InternalError(message)
Cython.Compiler.Errors.InternalError: Internal compiler error: 'TacsDefs.pxi' not found

Where should TacsDefs.pxi come from, and what should it contain? I am sure I have successfully installed mpi4py. Is this due to other reason?

Write out optimized bdf files including loads

Right now we don't provide users any methods for exporting their optimized models/loads back out in a BDF file format. In theory, this shouldn't be to difficult if we take advantage of pynastran's BDF class, which gets created in the pymeshloader. We'll have to figure out a way to propagate current dv information as well as problem loads back to the BDF class in order to update them in the BDF file before it is exported

output from writeSolution to VTK by default?

I see the default output is f5, and the f5tovtk has been great for converting for visualization purposes. Would it be possible to add an optional argument to writeSolution to allow vtk to be output automatically, or even directly from the BDF? it'd be nice if the default output was visualizable from an open-source analysis tool like Paraview. f5 are probably more compact but don't seem compliant with standard HDF5 readers, and feel like an intermediate step to being able to check results. and unlike tecplot, direct vtk outputs wouldn't require a prior TECIO-like installation for the user.

or to save space but still viewable from Paraview (this would probably be for down the road, pretty new format), could output as a VTK HDF file?

Add integration tests for thermal elements

Right now there are no integration tests to validate expected behavior of the ThermalShellElement class.
This element seems to be used regularly in the smdogroup/funtofem repo. So tests need to be added for these elements on the TACS side to make sure the changes we make here aren't breaking funtofem.

Quad16Shell Element Assumption

Currently when using the Quad16Shell element an assumption is made that the nodes in the element utilize a non-uniform spacing. This assumption can be seen in TACSShellElementQuadBasis.h in TacsLagrangeLobattoShapeFunction(), where once the order is greater than 3, Gauss-Lobatto points are used for evaluating the Legrange basis. This assumption requires the underlying mesh nodes to use the same spacing. Currently no check or warning is issued to the user to notify them of this. If a uniform node spacing is used with the Quad16Shell, the Legrange basis will not be evaluated at the nodes properly and will lead to incorrect results. If the mesh nodes are spaced appropriately, the element should work as expected.

pyTACS option `writeCoordinateFrame` is not supported

The writeCoordinateFrame options in pyTACS uses the TACS.OUTPUT_COORDINATES flag which no longer exists, resulting in an error if you set the option to True

plate example is not compatible with the code

bdf.getFuncGrad(num_design_vars, x, fvals, dfdx)
AttributeError: 'tacs.TACS.BDFIntegrator' object has no attribute 'getFuncGrad'

plate_adjoint.py and plate_dynamics.py has old functions which is modified by the update of the code

Add license file to repo

The c++ source code is labeled as using APACHE licensing I'm the header comments, but there isn't an actual license file available I'm the repo. We should include the license agreement as a markdown file, like what was done with smdogroup/funtofem

TACS Transient beam analysis test failing on arm64 docker images

We are trying to update our docker images to TACS 3.5.0 and seeing test failures, but only on our arm64 based containers. Unfortunately I can't recreate the issue as I don't have an M1/M2 mac.

integration_tests/test_trans_beam.py:ProblemTest.test_solve is failing with NaN function values, but the xpt and dv sens tests are passing.

These builds were previously working with TACS 3.3.1, so the breaking change has come since then. My first guess would be something in #250

See https://github.com/mdolab/docker/actions/runs/6619851520/job/18004906719#step:13:13931 for more details

Document ESP/CAPS interface, caps2tacs

• TACS has been integrated with ESP/CAPS, a CAD parametric geometry software.
• Add github documentation for the caps2tacs module which handles the interface

Metis download link is broken

The download link for METIS 5.1.0 included in the readme and docs (http://glaros.dtc.umn.edu/gkhome/metis/metis/download) is broken. We need to find an alternative place to send users to install the dependency. It seems like this might be the official github page for metis now, but it doesn't look like they have a tag for 5.1.0 and v5.1.1-DistDGL-v0.5 seems to lead to segfaults in our CI tests