smdogroup / tacs Goto Github PK
View Code? Open in Web Editor NEWFinite-element library for analysis and adjoint-based gradient evaluation
License: Apache License 2.0
Finite-element library for analysis and adjoint-based gradient evaluation
License: Apache License 2.0
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
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.
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
)
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?
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
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:
Non-deterministic when run on >3-4 cores:
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:
Other notes:
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!
Add documentation for new MPHYS interface
N/A
N/A
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
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.
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.
pip install .
should correctly install all TACS modules and library dependencies to the user's site-packages
N/A
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?
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
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.
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.
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.
N/A
N/A
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
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
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
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.
Some examples of concepts that still need to be discussed:
N/A
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:
getIterCount
method to each one?Thanks
Ali
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.
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.
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
Integration tests should be added for mphys wrapper to ensure functionality is maintained.
N/A
N/A
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.
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.
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
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?
Looks like an easy fix in constitutive.pyx - I think the title says it all but rho is not retrieved with the method.
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.
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.
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.
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";
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?
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!
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
Probably something like how dv outputs are currently handled (failure0
, failure1
, etc.).
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.