The organization that I (and others on this thread) envision is an umbrella for multiple projects, for multiple methods for PDEs, for multiple physics domains (perhaps solid and fluid mechanics, heat transfer, EMF, …), and also perhaps for multiple abstraction levels (general second-order PDEs vs one particular PDE, …).
At least for me the motivation would be to provide a place where Julians can go when they are looking for a package to help them with some code.
I may be wrong, but INVITING developers of relevant packages to join the organization and then to encourage them to transfer the packages to the organization (or at least link them from a wiki or in some other way) may be the key to the fitness of the org. Chris may have more to say about it. He has much more experience with an org (a successful org I might say). @ChrisRackauckas
I see it similarly. PDEs is a very heterogeneous field and while I am attempting to work towards something that combines solvers together, it will take quite a long time and in the end the specialized codes would probably do really well and should be integrated anyways. So an org is a nice way to organize various projects together. It also can pull together a set of bylaws and maintenance: I usually spend part of my morning going through tagging, re-running tests, and checking open PRs to see what needs to be done to move forward (maybe pinging the right people or leaving a message as to why it’s stalled). This kind of maintenance work from a core group is really what brings an org together and can make it “trustworthy”, and with that there’s also a sense of community that grows so people tend to work more together which then makes things sooner or later look more uniform.
The issue with FEM is that it’s such a time investment. I plan to just use whatever comes out, but FEM packages are a full team and org itself. Plus, I don’t tend to ever need it for my own work. I think a lot of people are the same. But there’s so many other things to do though that I don’t plan on stepping into FEM grounds anymore since there are so many specialists looking to do just that. Meanwhile I’ll do the easy stuff like FDM .
I’m also very interested in this. In my spare time, I’m developing some prototypes of semidiscretisations for hyperbolic PDEs at https://github.com/ranocha/HyperbolicDiffEq.jl, including finite volume and discontinuous Galerkin methods. It is in its early stage but may become part of the JuliaPDE toolbox. I’m also interested in classical summation-by-parts operators from finite differences and want to implement them in a package.
Obviously we are hoping that the developers of ALL such packages will join the organization.
The more the merrier.
By the way, it might be helpful in the setting up of the organization if people interested in being members expressed their intent here or by private message.
Hi everybody,
Very interesting discussion. What is the current status? I’m new to Julia so I’m trying to get an overview between JuliaFEM, JuaFem and FinEtools
I’m an engineer and not a programmer or mathematician, but I could contribute with tutorials in the areas that I’m experienced with: EE, mechanics and heat transfer.
Cheers,
J
Please join us for FEM development in JuliaFEM. We also have gitter channel: https://gitter.im/JuliaFEM/JuliaFEM.jl. We are copying the nice DifferentialEquations.jl package structure. We are splitting the development as small packages as possible, in order to avoid dependency problems of our development end users (people needing a small functionality rather than full FEM solver.). Although, the main package JuliaFEM.jl aim to be full FEM solver including all the features. I cannot compare to others because I don’t have experience of using the other Julia FEM packages.
All are different packages doing FEM with Julia with the authors coming from different backgrounds and have different philosophies on how the code should be structured and how the API should look. I’d suggest reading through some examples from each of them and try contribute to the one you like the most
Is there an “agreed upon” or somewhat “standardized” mesh format we can pull from something like JuliaGeometry? One of the issues with a higher level interface of this is that, for non-regular domains, in order to specify the domain you already need a mesh format, so at some point it might make sense for our high level interface to just choose one and let other FEM packages convert from it. I am not sure which one to choose though.
GeometryBasics is looking good, but the question is can it grow up some more? A fully general mesh framework needs to support, in addition to the basic cube -like and simplex -like shapes with the minimum number of vertices, analogous shapes with higher numbers of vertices (mid-edge, interior, and such), and also shapes with variable number of vertices (Voronoi-type polyhedra and so on). Also, arbitrary-order NURBS/Bezier shapes need to be supported. Finally, frameworks similar, but not identical, are needed for mesh-free methods.
Hi Chris,
How about using the gmsh mesh format? Gmsh 4.10.5
At least here in Germany a lot of people use gmsh and it even has a Julia API (I haven’t used it though) Gmsh 4.10.5
Cheers,
J
.