Looks very nice! What does the package name mean? I think I get “grid”, but not “ap”.
1 Like
I’m guessing it’s this: “Gridap provides a set of tools for the grid-based approximation of partial differential equations (PDEs) written in the Julia programming language.”
1 Like
I have installed gmsh but I get
julia> model=GmshDiscreteModel(“demo.msh”)
ERROR: GridapGmsh is not loaded or installed properly.
Julia Version 1.5.0-beta1.0 (2020-05-28)
Fedora 32 Linux
$ julia ./demo/demo.jl
ERROR: LoadError: GridapGmsh is not loaded or installed properly.
Stacktrace:
[1] error(::String) at ./error.jl:33
[2] macro expansion at /home/hearnsj/.julia/packages/GridapGmsh/Kh2vV/src/GridapGmsh.jl:48 [inlined]
[3] GmshDiscreteModel(::String) at /home/hearnsj/.julia/packages/GridapGmsh/Kh2vV/src/GmshDiscreteModels.jl:7
[4] top-level scope at /home/hearnsj/julia-code/gridap/GridapGmsh.jl/demo/demo.jl:5
[5] include(::Function, ::Module, ::String) at ./Base.jl:380
[6] include(::Module, ::String) at ./Base.jl:368
[7] exec_options(::Base.JLOptions) at ./client.jl:296
[8] _start() at ./client.jl:506
in expression starting at /home/hearnsj/julia-code/gridap/GridapGmsh.jl/demo/demo.jl:5
Try:
pkg> build GridapGmsh
If it does not work, take a look into
https://github.com/gridap/GridapGmsh.jl/blob/master/deps/build.jl
and check if it covers your scenario. If not, you are wellcome to open a PR with a fix for your case.
To get this to work, I found that the gmsh SKD must be installed. It contains a few extra sub-directories. The /lib then contains gmsh.jl that is needed for GridapGmsh to properly build and run.
I found something strange that I can’t get around. The first three lines of Tutorial one: t001_poisson
using Gridap
model = DiscreteModelFromFile("../models/model.json")
writevtk(model,"model")
execute properly from the notebook supplied in the tutorial. However, the same code fails in the REPL:
It’s some type conversion error but I don’t see why it presents in the REPL.
Any ideas on this one?
I think this is related with this issue
Can you summarize at a high-level the capabilities of this package compared with commercial software like ANSYS or Abaqus? I realize that the commercial software are developed by much larger teams with much more money, so I do not mean to criticize your package. I just have no idea of what Julia implementations are capable. Can this package be used on moderately complex geometries to solve practical engineering problems, or is it more for tinkering and research purposes?
Specifically I am interested in:
- transferring geometry from Solidworks
- automatic unstructured meshing and mesh control
- frictional contact surfaces and separation detection
- automatic tracking of nodal/elemental locations and connections
- solving heat transfer and force balance simultaneously
- post-processing
1 Like
Yes, that fixed it. Thanks.
Define practical engineering problem. I certainly use Julia to solve (what I think of as) practical engineering problems.
I suppose my main concern would be the handling of realistic geometries. I could code up a 1D finite element solver where I manually assign all the nodes and elements fairly easily, but a 3D solver which can mesh itself and perform the appropriate quadrature is expected for most practicing engineers.
My next concern would be what problems it can solve. What PDEs are supported, and how accurate and stable are the iterations?
I suppose my queries all boil down to the following question:
On a spectrum of required user involvement from coding my own simulations using the finite element method to clicking buttons in a commercial GUI, where does this package sit, and what benefit does being situated at that position provide?
1 Like
I haven’t used Gridap and this isn’t a full answer to your question but the following post from earlier in this thread gives a partial answer:
2 Likes
Gridap is a toolbox rather than an app that provides pre-backed Finite Element solvers for solving a specific PDE. The user writes a Julia scrip that combines the tools in Gridap to solve a particular problem.
3 Likes
@PetrKryslUCSD, I’ll take a stab at listing what I would consider practical (to me) engineering problems.
- Sections 4.1, 4.2, 5.1, 5.2
- Problem 1.6 “Ball Bearing Pull”
- Section 3.2 “Resistance Forge Weld Problem”
I don’t necessarily expect any Julia FEM package to solve these problems - rather I’d expect a commercial/government code (possibly written in Julia) to solve these problems.
1 Like
I don’t doubt that these are tough problems, that fit well the definition of a practical engineering problem. But, not all practical engineering problems are this complicated. There’s a spectrum.
I’m not sure why anyone would expect an open source code, with a handful of people working on it in their free time, to attack problems that thoroughly exercise codes such as Sierra (to which you linked), developed by hundreds of man years, with budget probably on the order of $1 million per year.
Could a commercial code be developed in Julia, for sure. Do you have the budget for it?
PS: By the way, I believe some of your links are mixed up.
2 Likes
I don’t expect any open-source toolbox to handle these problems. I’ve thoroughly enjoyed watching various open-source toolboxes (FEniCS, your project, MFEM, etc) grow and develop. But you asked for comments on what people might consider practical, so I felt compelled 
. I personally think we’re lucky to have any open-source FEM tooboxes (and incredibly lucky to have the MOOSE toolbox open-sourced by INL).
Something I’ve pondered on for quite some time is whether a large compendium of “practical” examples could be compiled, that then various toolboxes / codes could use as a capabilities reference. “Practical” here refers to the spectrum of non-verification style problems (i.e. no patch tests). Abaqus has an enormous suite of example problems that demonstrate capabilities.
Links should all work, but depending on OSTI’s servers, may take some refreshes.
Edit:
And I do think some projects should be a little more careful in what they claim, for instance Elmer FEM claims:
Elmer includes physical models for all branches of computational engineering and even beyond. … This is not a limitation of the code but rather limitation of time used make these examples. Application examples - Elmer - CSC Company Site
Yet they don’t appear to support contact in their structural mechanics code, nor structural dynamics capabilities!
3 Likes
Second the sentiment on MOOSE.
Also like the idea of a compendium. That could become one of the features of the JuliaPDE organizations, perhaps. But, I think that verification problems are good. There are many nontrivial benchmark problems in Abaqus, and FinEtools in particular solves a good number of those.
In addition, it would be good to have more comprehensive examples, especially with multi-physics. The problem then becomes how to tell a good solution from a bad one.
4 Likes
Maybe let me define two kinds of verification problems (borrowing from the insights of this VV&UQ paper): Code-verification, Capability-demonstration (roughly aligning to the paper’s descriptions of weak-sense / Glass-box benchmarks and strong-sense / black-box benchmarks respectively)
Regarding code-verification problems, I agree that they’re absolutely necessary, but they are often so integral to the development of a code (and often simple) that I’m not as concerned about developers being able to build their own verification problems. (But perhaps I’m overestimating the maturity here?)
Many practical engineering problems are nonlinear and do not have closed-form solutions to verify the code’s capabilities. So I think having a freely-available compendium of practical problems where developers can provide demonstrations of their code’s applicability, workflow, accuracy, robustness, uncertainty etc. and compare against other code-bases would be most useful.
Very nice examples!
Contact mechanics is the main missing part for solving some of these problems in Gridap. But, I believe we have the other ingredients: multi-physics, non-linear, time-dependent, history-dependent, etc.
3 Likes
It would be very nice to have this list and see how different FE libraries perform for each case. I am sure that there will be libraries that work better for some problems and viceversa.