As far as I know, for multi-physics simulations often software packages like Ansys or COMSOL are used. Can Julia also be used for this kind of simulations?
Or can Julia be used together with these commercial SW packages?
I am talking about 3D simulations of solid-fluid interaction, CFD, thermal simulations and electro-chemical simulations…
Hi @ufechner7
Take a look at: GitHub - gridap/Gridap.jl: Grid-based approximation of partial differential equations in Julia
[Disclaimer] I am one of the main developers of this package.
Looks good!
Question: Is it possible to do CFD (computational fluid dynamics) with Gridap, e.g. simple water cooling?
To me, “multi-physics simulation software” means that the software can simulate models from different physical domains, and typically also can combine models from different domains. This possibility typically exists for equation-based simulation tools. Prime examples of equation-based languages/tools are Modelica, ModelingToolkit, gPROMS, COMSOL Multiphysics, ANSYS Fluent, etc. Other tools normally have specialized libraries focused on limited domains, such as AspenTech process simulators, Spice, etc. (although these may also have some level of possibility to add models).
The two tools you mention typically target the solution of PDEs. Fluent is often used to solve Computational Fluid Dynamics problems (moving fluids) typically based on Fininite Volume Methods, while COMSOL Multiphysics is a rather general PDE solver using Finite Element Methods (more suitable for electro-magnetic-mechanical systems?). COMSOL Multiphysics has nice support for “drawing” the system volume and specifying boundary conditions, generating grid, etc. Since I looked at them, they may have developed and have more possibilities. COMSOL Multiphysics was originally developed in Sweden by the Nordic MATLAB reseller (COMputer SOLutions) and was written in MATLAB. When MathWorks took over the Nordic MATLAB market themselves, COMSOL split out and became independent of MATLAB code.
There is a standard for connecting different types of simulation tools: FMI – Functional Mock-up Interface. If your ANSYS tool and COMSOL Multiphysics supports generating FMUs (Functional Mock-up Units), then it is possible to interface the generated simulation unit via FMI to other FMUs. Several Modelica tools support FMI. I seem to have seen that there is support for FMI in JuliaSim, but I may be wrong.
There is FMI support in Julia, not limited to JuliaSim: GitHub - ThummeTo/FMI.jl: FMI.jl is a free-to-use software library for the Julia programming language which integrates FMI (fmi-standard.org): load or create, parameterize, differentiate and simulate FMUs seamlessly inside the Julia programming language!
But not yet complete, for example export of FMIs for cosimulation is still missing: Support export of FMUs for cosimulation · Issue #10 · ThummeTo/FMIExport.jl · GitHub
Hi @ufechner7
Yes, you can use Gridap for CFD if you are happy to use finite elements for this. You can also couple fluid with other physics as long as they are also modeled with PDEs. You can have both surface and volume couplings.
I believe that super computing, including CFD, is still one of the pain points in the Julia community. Organizing a massively parallel computing package takes years of effort. For the CFD people, it is pointless to turn to abandon a platform that has been maintained for two decades and turn to a new language. Therefore, I don’t see a real reason for such softwares like OpenFoam, SU2, FeniCS, PyFR, to be replaced.
There have been some excellent work in the community, including Oceananigans and Gridap mentioned above. But I think there’s still a long way to go.
(I won’t call Ansys or COMSOL as software packages since they are apparently the product of domain specific commercial companies and are close-source.)
Trixi should probably be also mentioned: https://trixi-framework.github.io/ (@ranocha could probably give a better commentary on it)
I guess there is no genuine multi-physics simulation framework in Julia but you can definitely create your own code, depending on the application. Trixi.jl is our package focusing on transport-dominated problems (hyperbolic conservation laws such as the compressible Euler equations). It depends on what kind of CFD you have in mind - compressible, inviscid flows are our main focus, experimental support for Navier-Stokes has been added recently. We can’t do incompressible flows at the moment (but shallow water flows, for example).
Our first application was a multi-physics setup coupling compressible flows with self-gravity, so it’s possible to couple things. But that’s of course not something like a commercial software package like the ones from Ansys or so.
@ufechner7 I don’t know if this question is still relevant, but as @ranocha pointed out, we do have initial support for multi-physics simulations in Trixi.jl using volume coupling (sometimes called bulk coupling), e.g., for flow-gravity or flow-aeroacoustics problems. There is also a PR for coupling two or more meshes using surface coupling (aka interface coupling), but it has not yet been merged.
Activities regarding multi-physics simulations in Trixi.jl are to increase soon, since we have secured a research grant on bulk and interface coupling with Trixi.jl. The first PhD students and postdocs are starting in October and November, so we expect to start seeing feature updates in the next couple of months. Feel free to reach out to me personally if you have a specific question and whether it is (currently) viable to do in Trixi.
Sounds promising!
What is the main difference between Gridap and Trixi?
What we want to simulate is liquid cooling, e.g. water flow (CFD), a heat source, and later electro-chemical corrosion…
Maybe if someone can create a wrapper of Kratos Multiphysics for Julia it can be helpful.
If you think about CFD, you can simplify it as “Gridap does classical FEM for incompressible flows, Trixi does DG for compressible flows”. That’s not the only tasks those packages can solve etc. but it’s a good first approximation.
openfoam, code-saturne, and SU2 are Open-Source CFD Codes. but SU2 has a python wrapper.
so, instead of writing all code in Julia, it is better to write a wrapper for SU2 in Julia for immediate access to CFD. Julia language was also developed for numerical methods but no CFD toolbox is available yet.
finally, SU2 + Julia is the best solution. SU2 can develop post-processing tools using Julia. I was trying to find the CFD package, I think only SU2 can solve this problem.
Julia is developed at MIT, and SU2 at Stanford University, but both don’t find communication on it. I think They should work on it. it will be a great advantage for CFD people to use Julia.
@ufechner7 @BLI @Freya_the_Goddess @ranocha @Krastanov @sloede
SU2… probably Stanford University
Hi @fverdugo
Gridap.jl is awesome.
I hope that it can support some predefined models like in COMSOL.
Then, for ordinary usage, people can just choose a model and define the geometry, boundary conditions and meshes without touching the mathematical description on the model.
Is this out of the scope of Gridap.jl?
Is this out of the scope of
Gridap.jl?
I think it is out of scope, but it looks like a nice project idea.
Salome-Meca using Salome as an open source preprocessor and Code Aster as the FEM engine, and integrating nicely with Code Saturn is one of the more polished open source projects for FEM & CFD for multi-physics and fluid structure interaction.
You will note the fingerprints of EDF the French research institute in many places with in this framework.
They use compiled Fortran Code for the number crunching with the glue code being Python. It would be neat to replace the Python part with Julia, which would then open the door to developing Julia modules to extend the capabilities and solving their two language problems.
It would be good that we just transform the examples in the tutorial to models, which can be easily included by users, making the tutorial become a high-level package based on Gridap.jl.
By adding some physical description to those models, we may deliver something that is comparable to COMSOL for ordinary usage.