Open mohamed82008 opened 3 years ago
I like this! I use FEASolver
for some of my other work related to elastic body simulation, but do not necessarily need it nested in an optimization. In particular, I find the problem definition -> FEA solver pipeline convenient, and I can just manually set the corresponding indicator variable to 1 in the voxel grid.
And for a lot of people that I know, they look at TopOpt.jl especially to look for example code for the FEA implementation. It'd be great if we can have a unified, high-level API for defining these FEA problems that is compatible with all the downstream in the TopOpt stack, while allowing users to swiftly try out different FEA backends (similar to my fabulous experience in JuMP).
Ya technically the API of the solver is most of the FEA API but sometimes we need to iterate over the elements, e.g. when computing the gradient of the compliance.
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.