juliatopopt / topopt.jl Goto Github PK

A package for binary and continuous, single and multi-material, truss and continuum, 2D and 3D topology optimization on unstructured meshes using automatic differentiation in Julia.

Home Page: https://juliatopopt.github.io/TopOpt.jl/

License: Other

Julia 96.18% GLSL 0.33% Jupyter Notebook 3.49%

automatic-differentiation beso buckling civil-engineering continuum-mechanics engineering-design generative-design geometry-optimization mechanical-engineering multimaterial

topopt.jl's Introduction

TopOpt.jl

TopOpt is a topology optimization package written in Julia. To learn more and see some examples, visit the documentation. Numerous examples can also be found in the test/examples and test/wcsmo14 directories.

Installation

To install TopOpt.jl, run:

using Pkg
pkg"add TopOpt"

To additionally load the visualization submodule of TopOpt, you will need to install GLMakie.jl using:

pkg"add Makie, GLMakie"

To load the package, use:

using TopOpt

and to optionally load the visualization sub-module as part of TopOpt, use:

using TopOpt, Makie, GLMakie

Features available

All the following features are available in TopOpt.jl but the documentation is currently lacking! Feel free to open an issue to ask about how to use specific features.

Optimizaton domains

2D and 3D truss domains
2D and 3D continuum domains
Unstructured ground mesh
Linear and quadratic triangle, quadrilateral, tetrahedron and hexahedron elements in ground mesh
Fixed and non-design domain support
Concentrated and distributed loads
Multi-material design parameterisation

High level algorithms and penalty types

The following high level topology optimization algorithms and penalty types are available.

Solid isotropic material with penalization (SIMP)
Rational approximation of material properties (RAMP)
Continuation SIMP/RAMP
Bi-directional evolutionary structural optimization (BESO) with soft-kill
Topology optimization of binary structures (TOBS)

Differentiable functions

There are numerous functions in TopOpt.jl that are defined in a differentiable way and you can use them in the objectives or constraints in topology optimization formulations. In TopOpt.jl, you can build arbitrarily complex objective and constraint functions using these differentiable functions as building blocks or lego pieces chaining them in any arbitrary way. The gradient and jacobian of the aggregate Julia function defined is then obtained using automatic differentiation. For a detailed account of the functions available, see the relevant section in the documentation.

Linear system solvers

Direct sparse Cholesky decomposition based linear system solver
Preconditioned conjugate gradient method with matrix assembly
Matrix-free preconditioned conjugate gradient method

Optimization algorithms

We use Nonconvex.jl for the optimization problem definition and solving. The following algorithms are all available using Nonconvex.jl.

Method of moving asymptotes
All the algorithms in NLopt
Ipopt
First order augmented Lagrangian algorithm
Nonlinear semidefinite programming for buckling constrained optimization
Basic surrogate assisted optimization and Bayesian optimization
Integer nonlinear programming (design variables guaranteed to be integer)
Sequential integer linear programming in the topology optimization for binary structures (TOBS) algorithm

Handling uncertainty

Handling load uncertainty in compliance-based topology optimization
Reliability-based topology optimization

Visualization and post-processing

End-to-end topology optimization from INP file to VTK file
Interactive visualization of designs and deformation using Makie.jl
Interactive visualization of designs using Dash apps and DashVtk

Citation

To cite this package, you can cite the following 2 conference publications.

TopOpt.jl: An efficient and high-performance package for topology optimization of continuum structures in the Julia programming language

@inproceedings{tarek2019topoptjl,
  title={TopOpt.jl: An efficient and high-performance package for topology optimization of continuum structures in the Julia programming language},
  author={Tarek, Mohamed},
  booktitle={Proceedings of the 13th World Congress of Structural and Multidisciplinary Optimization},
  year={2019}
}

TopOpt.jl: Truss and Continuum Topology Optimization, Interactive Visualization, Automatic Differentiation and More

@inproceedings{huang2021topoptjl,
  title={TopOpt.jl: Truss and Continuum Topology Optimization, Interactive Visualization, Automatic Differentiation and More},
  author={Huang, Yijiang and Tarek, Mohamed},
  booktitle={Proceedings of the 14th World Congress of Structural and Multidisciplinary Optimization},
  year={2021}
}

Contribute

We always welcome new contributors! Feel free to open an issue or reach out to us via email if you want to collaborate. There are plenty of things to do including beginner friendly tasks and research-oriented tasks. You can help us create the best topology optimization ecosystem in the world! Some beginner-friendly ideas you could be working on include:

Level set design parameterization
Lattice design parameterization
Local volume constraints
Supporting rectilinear grids
Wrapping OpenLSTO_jll which is the precompiled binary for M2DOLab/OpenLSTO
Wrapping TopOpt_in_PETSc_jll which is the precompiled binary for topopt/TopOpt_in_PETSc
Robust optimization
Stochastic optimization

Questions?

If you have any questions, join us on on the #topopt channel in the Julia slack, open an issue or shoot us an email.

topopt.jl's People

Contributors

Stargazers

Watchers

topopt.jl's Issues

fluid–thermal topology optimization

Has anyone tried to use TopOpt to solve fluid–thermal topology optimization problems?
I am trying to write a program for the topology optimization of liquid-cooling heat sink with julia.

Reliability based topology optimisation

This is an umbrella issue to discuss plans towards reliability based topology optimisation.

Barrier function formulation to include buckling constraints in truss topopt

PR #58 paves our way towards including buckling constraints in truss topopt via a barrier function formulation. The next steps in this direction would include:

(1) Formulate the gradient of the barrier function -c*logdet(Ke + s * Kg), where c>0 is the multiplier, Ke is the first-order stiffness matrix and Kg the geometric stiffness matrix. Note that this function approach inf as Ke+s*Kg is not positive-definite.
(2) Then we write an outer loop with a decreasing sequence of c and use MMA to optimize the composite function obj - c*logdet(Ke + s*Kg).

To achieve these, I think a truss_buckling_logdet.jl module will be added to the Functions folder which contains function evaluation and ChainRulesCore.rrule, in a way similar to the MacroVonMisesStress function,

Automatic differentiation based refactor

A lot of the time in developing a new function for topology optimization, e.g. compliance, a stress measure, aggregated stress, etc. goes into defining the gradient of this function wrt the topology decision variables.

Currently in TopOpt, I have the convention of func(x, grad) for every function-like struct. This means that I have to essentially build grad from scratch for every function. This was chosen for its simplicity and to allow the pre-allocation of memory. However, the bottleneck in TopOpt is in the computation of the function value and gradient and not in the allocation, so we don't quite need pre-allocation.

For functions that are closely related like local stress and aggregated stress for example, reusing the transpose of the Jacobian of the local stress function in the computation of the gradient of the global stress would be practically re-inventing reverse-mode automatic differentiation. Relying on automatic differentiation can allow us to chain functions together, e.g. x |> filter |> interpolate |> penalize |> project |> von_mises |> norm without having to manually define the gradient of the norm of the von Mises stress of the projected, penalized, interpolated, filtered design, it gets tedious! We can also make use of arbitrary Julia functions as part of our objectives and/or constraints. This creates a total separation between the optimization algorithm and the topology optimization functions, which is something the current design doesn't fully achieve.

Chordal decomposition + barrier method + augmented Lagrangian algorithm for large scale buckling constraints

Now that we have a differentiable assembly operator, we can use to do chordal decomposition by breaking down the large scale sparse SDP constraint into a bunch of small SDP constraints. We still need an equality constraint to specify that the relationship between the large scale sparse matrix K + c * Ksigma == assembleK(Ms) where Ms is the vector of small matrix decision variables of the same size as the element stiffness matrices, i.e. Ms[1] is of size ndofs_per_element x ndofs_per_element. With this formulation, we can then use SDPBarrierAlg of a PercivalAlg to solve the problem efficiently.

Support Percival.jl

This issue tracks the blocking PRs for using Percival.jl's implementation of the first order augmented Lagrangian algorithm with TopOpt.jl through Nonconvex.jl.

Issues installing when QuadraticModels.jl is installed

Hello,

I just wanted to let you know that there seem to be a clash between the installation of the TopOpt.jl and QuadraticModels.jl coming from NonconvexPercival.jl. Here is the output that I get when trying to install TopOpt.jl (when QuadraticModels.jl is installed)

(@v1.7) pkg> add TopOpt
   Resolving package versions...
ERROR: Unsatisfiable requirements detected for package NonconvexPercival [4296f080]:
 NonconvexPercival [4296f080] log:
 ├─possible versions are: 0.1.0-0.1.1 or uninstalled
 ├─restricted by compatibility requirements with Percival [01435c0c] to versions: uninstalled
 │ └─Percival [01435c0c] log:
 │   ├─possible versions are: 0.1.0-0.5.0 or uninstalled
 │   ├─restricted by compatibility requirements with NLPModelsModifiers [e01155f1] to versions: [0.1.0, 0.4.0-0.5.0] or uninstalled
 │   │ └─NLPModelsModifiers [e01155f1] log:
 │   │   ├─possible versions are: 0.1.0-0.6.0 or uninstalled
 │   │   ├─restricted by compatibility requirements with NLPModels [a4795742] to versions: [0.1.0-0.2.0, 0.4.0-0.6.0] or uninstalled
 │   │   │ └─NLPModels [a4795742] log:
 │   │   │   ├─possible versions are: 0.6.0-0.18.4 or uninstalled
 │   │   │   ├─restricted by compatibility requirements with QuadraticModels [f468eda6] to versions: [0.13.0-0.15.0, 0.17.0-0.18.4]
 │   │   │   │ └─QuadraticModels [f468eda6] log:
 │   │   │   │   ├─possible versions are: 0.1.0-0.7.3 or uninstalled
 │   │   │   │   ├─restricted to versions * by an explicit requirement, leaving only versions 0.1.0-0.7.3
 │   │   │   │   └─restricted by compatibility requirements with Requires [ae029012] to versions: 0.4.0-0.7.3 or uninstalled, leaving only versions: 0.4.0-0.7.3
 │   │   │   │     └─Requires [ae029012] log:
 │   │   │   │       ├─possible versions are: 0.5.0-1.3.0 or uninstalled
 │   │   │   │       └─restricted by compatibility requirements with TopOpt [53a1e1a5] to versions: 1.1.0-1.3.0
 │   │   │   │         └─TopOpt [53a1e1a5] log:
 │   │   │   │           ├─possible versions are: 0.4.0-0.5.2 or uninstalled
 │   │   │   │           ├─restricted to versions * by an explicit requirement, leaving only versions 0.4.0-0.5.2
 │   │   │   │           ├─restricted by compatibility requirements with Nonconvex [01bcebdf] to versions: [0.4.0-0.4.1, 0.5.0-0.5.2] or uninstalled, leaving only versions: [0.4.0-0.4.1, 0.5.0-0.5.2]
 │   │   │   │           │ └─Nonconvex [01bcebdf] log:
 │   │   │   │           │   ├─possible versions are: 0.1.0-1.0.2 or uninstalled
 │   │   │   │           │   ├─restricted by compatibility requirements with TopOpt [53a1e1a5] to versions: [0.2.0-0.3.0, 0.5.2, 1.0.0-1.0.2]
 │   │   │   │           │   │ └─TopOpt [53a1e1a5] log: see above
 │   │   │   │           │   ├─restricted by compatibility requirements with NLPModelsModifiers [e01155f1] to versions: [0.1.0-0.3.0, 0.7.3-1.0.2] or uninstalled, leaving only versions: [0.2.0-0.3.0, 1.0.0-1.0.2]
 │   │   │   │           │   │ └─NLPModelsModifiers [e01155f1] log: see above
 │   │   │   │           │   └─restricted by compatibility requirements with Percival [01435c0c] to versions: [0.1.0, 0.6.0-1.0.2] or uninstalled, leaving only versions: 1.0.0-1.0.2
 │   │   │   │           │     └─Percival [01435c0c] log: see above
 │   │   │   │           └─restricted by compatibility requirements with Nonconvex [01bcebdf] to versions: 0.5.0-0.5.2 or uninstalled, leaving only versions: 0.5.0-0.5.2
 │   │   │   │             └─Nonconvex [01bcebdf] log: see above
 │   │   │   └─restricted by compatibility requirements with QuadraticModels [f468eda6] to versions: [0.15.0, 0.17.0-0.18.4]
 │   │   │     └─QuadraticModels [f468eda6] log: see above
 │   │   └─restricted by compatibility requirements with QuadraticModels [f468eda6] to versions: [0.2.0, 0.4.0-0.5.1]
 │   │     └─QuadraticModels [f468eda6] log: see above
 │   └─restricted by compatibility requirements with NLPModels [a4795742] to versions: 0.4.0-0.5.0 or uninstalled
 │     └─NLPModels [a4795742] log: see above
 └─restricted by compatibility requirements with TopOpt [53a1e1a5] to versions: 0.1.0-0.1.1 — no versions left
   └─TopOpt [53a1e1a5] log: see above

If relevant here is my system information:

julia> versioninfo()
Julia Version 1.7.2
Commit bf53498635 (2022-02-06 15:21 UTC)
Platform Info:
  OS: macOS (arm64-apple-darwin21.2.0)
  CPU: Apple M1 Pro
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-12.0.1 (ORCJIT, cyclone)

Lattice topology optimization

Doing lattice topology optimization is as simple as defining a transformation that takes a vector of decision variables for a lattice element and returns a vector where elements are replicated. This can be encoded as a new problem type which has this transformation function as part of it. The transformation function can then be called in the objective and constraints.

Minimal FEA API

We need to define an FEA API for topology optimisation that upstream FEA packages can define to become compatible with TopOpt.jl. We can call it AbstractTopOpt.jl or something like this. This should be the minimal set of functions used in TopOpt.jl from the FEA package. We can then define the API for JuAFEM, Gridap, JuliaFEM (aka Ferrite), etc. The API definitions can live in individual packages or in TopOpt.jl using Requires.

Wrap the output of each function in a struct and use for dispatch

I thought quite a bit about the design of TopOpt and there is one thing I dislike. Let's take compliance as an example. Depending on the level of modularity that a user wants, the user may want to either:

Go from design variables to compliance directly
Go from design variables to displacements and the compute compliance using dot product with the load
Go from design variables to element stiffness matrices and displacements then compute element compliances followed by a sum to get the full compliance

The reason for these levels of modularity is that the displacement may be required for another computation or to apply a constraint on the displacement. Or the element stiffness matrices may be required to do buckling for instance. We can have functions for all these but calling these functions can cause the re-evaluation of the same quantities multiple times which can be inefficient compared to evaluating each quantity once and reusing it to compute the compliance, stress tensors, buckling matrix, etc. This requires that the comp::Compliance function should have multiple methods where each method is aware of what inputs are given to it, because it's not always going to be the design variables x. Multiple dispatch can be used to tell comp what the input types are by wrapping the inputs in a struct. For example:

comp(DesignVariables(x))

will be the current compliance.

comp(DisplacementResult(u))

just returns the dot product of u and f (assumed constant).

comp(DisplacementResult(u), Load(f))

can be used to return the dot product where f is itself a decision variable for some reason.

comp(ElementCompliance(cs))

can be used to return the sum of cs. We can alternatively make the functions return these structs to avoid having the users wrap the outputs themselves. This will be more magical where I can do:

d = DesignVariables(x)
Kes = element_kes(d)
K = assemble_K(d, Kes)
u = disp(K)
st = stress_tensor(u)

and it should all just work as expected because disp knows that K is the assembled stiffness matrix and stress_tensor knows that u is the displacement vector. The magical part is that the above should work but also the following should work:

d = DesignVariables(x)
st = stress_tensor(d)

computing the stress tensors directly from d using the correct method.

Mixed integer optimisation

When MINLP is supported in Nonconvex (soon), we can use it to get binary designs. This will generalise the SIMP approach because we can still use a penalty but if it fails to get a binary solution, branch and bound will brute-force the hell out of it.

Physics informed neural networks

We should be able to use https://github.com/SciML/NeuralPDE.jl to replace the linear system solve and therefore generalize our approach to arbitrary physics problems.

Stochastic topology optimisation

If the load follows a certain distribution, one may want to minimise or constrain the mean objective, standard deviation or a weighted sum.

Plate and shell FEA models

In parellel to #46 , it'd be nice to have shell and plate FEA model implemented here too. Another FEA (Ferrite) exercise...

Out of core topology optimisation

Currently the problem sizes we can solve are limited to those that can fit in the RAM. This is a limitation that I don't like. In theory, we can use something mmap (like https://docs.julialang.org/en/v1/stdlib/Mmap/#Mmap.mmap) to map an array to a file in the memory. Then we can loop over the array and Julia will load the data in chunks from the file.

Enable the use of FinETools.jl or JuliaFEM.jl for FEA

It would be nice to not depend entirely on JuAFEM for the FEA. Having a layer of abstraction over JuAFEM, FinETools and JuliaFEM inside TopOpt means that we can benefit from all these amazing packages' features. JuliaFEM in particular seems to support distributed FEA and FinETools has a good variety of physics problems implemented. Relevant: #5

Load swapping and unrelated results

While trying to come up with a way of generating random FEA problems and running topological optimization on them, I ran into a strange issue. Sometimes, judging by the von Mises field, the 2 loads applied seem to have swapped their positions (see figure below). And less frequently the von Mises field doesn't seem to be related to the initial FEA problem at all.

issue.zip

The attached zip contains the sufficient files to reproduce the problem.

Bring back the GPU support

GPU support was dropped at some point when refactoring the code-base. I think we should bring it back.

Implement problems other than linearly elastic quasi-static problems

It would be nice to have problems other than linearly elastic problems. Some candidates include:

Compliant mechanisms,
Heat equation problems, and
Electro-mechanical systems.

Topology to shape optimisation

ERROR: Unsatisfiable requirements detected for package VTKDataTypes

Hi,

ERROR: Unsatisfiable requirements detected for package VTKDataTypes

Best,

Bring back adaptive CSIMP

In #126, the adaptive CSIMP algorithm from https://www.sciencedirect.com/science/article/pii/S0045782520300621?via%3Dihub was removed to simplify the code. I am opening this issue to track that we need to bring it back.

“Pkg.resolve()”.

Hello,

I cannot solve this problem using “Pkg.resolve()”. I have installed CatViews.......

ERROR: LoadError: LoadError: ArgumentError: Package TopOpt does not have CatViews in its dependencies:

If you have TopOpt checked out for development and have
added CatViews as a dependency but haven't updated your primary
environment's manifest file, try Pkg.resolve().
Otherwise you may need to report an issue with TopOpt

Level set methods

This is an umbrella issue to discuss implementation strategies for the level set topology optimisation methods.

Replace INP to Ferrite parser

https://github.com/Ferrite-FEM/FerriteMeshParser.jl now has INP parsing, could be worth looking into replacing the parser in TopOpt.

WARNING: could not import Visualization.visualize into Main

I am succesfully able to run the optimization. I also get a result. However, when trying to visualize things I get the following:

Input:

using Pkg; Pkg.add("Makie")  
import TopOpt.TopOptProblems.Visualization: visualize

Output:

Resolving package versions...   No Changes to `~/Documents/TopOpt.jl/Project.toml`   
No Changes to `~/Documents/TopOpt.jl/Manifest.toml` 
WARNING: could not import Visualization.visualize into Main

Visualization does not work for LBeam

ERROR: AssertionError: S <= length(x)
Stacktrace:
  [1] Vec
    @ ~\.julia\packages\GeometryBasics\OWi7v\src\fixed_arrays.jl:40 [inlined]
  [2] _broadcast_getindex_evalf
    @ .\broadcast.jl:648 [inlined]
  [3] _broadcast_getindex
    @ .\broadcast.jl:621 [inlined]
  [4] getindex
    @ .\broadcast.jl:575 [inlined]
  [5] macro expansion
    @ .\broadcast.jl:984 [inlined]
  [6] macro expansion
    @ .\simdloop.jl:77 [inlined]
  [7] copyto!
    @ .\broadcast.jl:983 [inlined]
  [8] copyto!
    @ .\broadcast.jl:936 [inlined]
  [9] copy
    @ .\broadcast.jl:908 [inlined]
 [10] materialize
    @ .\broadcast.jl:883 [inlined]
 [11] (::TopOpt.TopOptProblems.Visualization.var"#19#28"{Dict{Int64, Vector{Float64}}})(s::Float64)
    @ TopOpt.TopOptProblems.Visualization ~\Dropbox (MIT)\code_ws_dropbox\TO_ws\TopOpt.jl\src\TopOptProblems\Visualization\makie.jl:156
 [12] lift(::Function, ::Observable{Any})
    @ AbstractPlotting ~\.julia\packages\AbstractPlotting\gE7AT\src\interaction\nodes.jl:15
 [13] visualize(mesh::JuAFEM.Grid{2, JuAFEM.Quadrilateral, Float64}, u::Matrix{Float64}; topology::Vector{Float64}, cloaddict::Dict{Int64, Vector{Float64}}, undeformed_mesh_color::Tuple{Symbol, Float64}, deformed_mesh_color::Tuple{Symbol, Float64}, vector_arrowsize::Float64, vector_linewidth::Float64, default_support_scale::Float64, default_load_scale::Float64, scale_range::Float64, default_exagg_scale::Float64, exagg_range::Float64)
    @ TopOpt.TopOptProblems.Visualization ~\Dropbox (MIT)\code_ws_dropbox\TO_ws\TopOpt.jl\src\TopOptProblems\Visualization\makie.jl:154
 [14] visualize(problem::LBeam{Float64, 4, 4, Float64, Float64, JuAFEM.ConstraintHandler{JuAFEM.DofHandler{2, JuAFEM.Quadrilateral, Float64}, Float64}, Float64, Int64, BitVector, BitVector, Vector{Int64}, TopOpt.TopOptProblems.Metadata{Matrix{Int64}, RaggedArray{Vector{Int64}, Vector{Tuple{Int64, Int64}}}, RaggedArray{Vector{Int64}, Vector{Tuple{Int64, Int64}}}, Matrix{Int64}}}; kwargs::Base.Iterators.Pairs{Symbol, Vector{Float64}, Tuple{Symbol}, NamedTuple{(:topology,), Tuple{Vector{Float64}}}})
    @ TopOpt.TopOptProblems.Visualization ~\Dropbox (MIT)\code_ws_dropbox\TO_ws\TopOpt.jl\src\TopOptProblems\Visualization\makie.jl:215
 [15] top-level scope
    @ REPL[19]:1

Example on custom linear system solver and preconditioner

We need an example showing how to define a custom linear system solver and preconditioner.

Unsatisfiable requirements detected for package Makie

Seems like there is a wrong version number for Makie.

julia> pkg"add Makie"
   Resolving package versions...
ERROR: Unsatisfiable requirements detected for package Makie [ee78f7c6]:
 Makie [ee78f7c6] log:
 ├─possible versions are: 0.9.0-0.12.0 or uninstalled
 ├─restricted to versions * by an explicit requirement, leaving only versions 0.9.0-0.12.0
 └─restricted by compatibility requirements with AbstractPlotting [537997a7] to versions: uninstalled — no versions left
   └─AbstractPlotting [537997a7] log:
     ├─possible versions are: 0.9.0-0.16.7 or uninstalled
     └─restricted to versions 0.16 by TopOpt [53a1e1a5], leaving only versions 0.16.0-0.16.7
       └─TopOpt [53a1e1a5] log:
         ├─possible versions are: 0.4.0 or uninstalled
         └─TopOpt [53a1e1a5] is fixed to version 0.4.0

CUDA support example

In the code several references to GPU/CUDA support can be found. Could an example/turtorial how to get this working be an idea?

Change JuAFEM.jl dependency to Ferrite.jl

https://github.com/Ferrite-FEM/Ferrite.jl

Use Makie observables to visualize optimization iterations

Cool visuals!

Robust topology optimisation

If the load or material properties are known to belong to a set, e.g. interval, ellipsoid, etc., efficient optimisation methods can be used to solve the robust optimisation problem.

Multi-material topology optimization

Once JuliaNonconvex/Nonconvex.jl#21 is resolved, we can experiment with optimizing structs. To do multi-material optimization, we need:

The decision variables to be a vector of composite ratios per element where each element has a struct or tuple associated.
A multi-material penalty and interpolation.

Adding constraints on the material ratios can be then be pure Julia code out of TopOpt.jl.

TagBot trigger issue

This issue is used to trigger TagBot; feel free to unsubscribe.

If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.

If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

Register the package

@JuliaRegistrator register

Define a function for ContinuumElementKσ

We currently have TrussElementKσ which is used for truss buckling constrained optimisation. We should also have one for continuum elements for continuum buckling constrained optimisation.

Enable the use of NLopt and Ipopt for optimization

Currently, only the MMA algorithm is supported which doesn't directly support equality constraints. The augmented Lagrangian method is also implemented but not too robust yet. It would be nice to be able to call the algorithms from NLopt and Ipopt from inside TopOpt.jl.

Missing CITATION.bib

Is there a suggested way to cite this package?

Simultaneous analysis and design tutorial

Now that we have a function that goes from the decision variables to the element stiffness matrices and a differentiable assembly and boundary conditions application function, we can use those to do simultaneous analysis and design by incorporating the analysis equation K u = f as constraints and then we can use the augmented Lagrangian algorithm to do optimisation and analysis simultaneously. This just needs a tutorial.

Build without CUDA

Hi Mohamed

Pleasure to meet you at the WCSMO-13.
Is there a way to build without CUDA ? Thanks.

/Peter Clausen

Beam and frame FEA models

Adding beam and frame models to the TrussTopOptProblems (we should rename it by then), so we have a "full model" for linear elements in 2D/3D that includes not only axial forces but also bending and torsion. The efforts will be in:

Extending dofs to include angles.
Extending our element stiffness matrix to translate my python code here. We can debate to directly hardcode it or try to write it in a Ferrite-friendly way (like what we've done for truss elements).

And that's pretty much it!

It would be interesting to try reproducing results from this paper: https://www.sciencedirect.com/science/article/pii/S0045794917300639

Nonlinear FEA - material and geometric nonlinearity

We should be able to support material and geometric nonlinearity using a combination of NLSolve.jl and ImplicitDifferentiation.jl. We just need to define the equilibrium equations as a differentiable function of the decision variables.

Truss geometric stiffness matrix unit tests

Currently, the geometric stiffness matrix construction (used for buckling constraint) returns incorrect results. I will try to debug that and add a few tests to compare against some textbook examples.

Visualization of first documentation example

The first example on the documentation ("SIMP example: Point Load Cantilever") has some small issues. When trying to visualize the final topology, I first had problems with GLMakie and had to add import GLMakie to the beginning of the file.

The other problem is in fig = visualize(problem; topology = result.topology, problem; topology = result.topology, default_exagg_scale = 0.07, scale_range = 10.0, vector_linewidth = 3, vector_arrowsize = 0.5, ). The repetition of problem; topology = result.topology introduces two semicolons on the call of a function.

Lastly, when the GLMakie window shows up with the final topology, the first slider ("deformation exaggeration") doesn't seem to affect the plot. I'd expect the structure to move a bit.

Define ChainRules properly

The chain rules defined for functions like Compliance assume that one would only want to differentiate wrt the pseudo-densities. However, one may also want to differentiate wrt the mesh coordinates, material properties, penalty value, etc. While one would generally not use Zygote for this but currently Zygote will give a wrong answer because we assume that the adjoint rule wrt these variables is always 0. It is possible to define this correctly using a "partial adjoint" calling Zygote.pullback in the rule.

Use LinearSolve.jl

We should look into using the LinearSolve.jl API in the FEASolver instead of implementing our own API for A \ b.

Remove SIMP and ContinuationSIMP structs

There are currently 2 workflows when using TopOpt. One uses the SIMP and ContinuationSIMP struct and one uses Nonconvex directly building and optimising the model. I former is legacy API from many years ago that's now redundant given the latter workflow. It's best to get rid of these old structs and just rely on a loop for continuation SIMP.

More light-weight truss ground structure IO

Currently, we use a JSON file to parse ground structures for truss problems. However, this is entirely for the convenience of debugging and unit tests. The json file can get unnecessarily large when the ground structure gets denser.

Here are some thoughts:

We might consider using LightGraph to represent graphs and use their IO methods.
We should have some standard problem struct for truss problems, similar to the PointLoadCantilever and L-Beam for solid problems. For example, we should at least have a ground structure method for distributing points (parameter 1) in a cube-like domain, and connect each points' k neighboring points (parameter 2).