FreeCAD with Julia

Looks like the FreeCAD community has taken an interest in supporting Julia computations:

https://forum.freecadweb.org/viewtopic.php?f=8&t=42400

14 Likes

Oo Oo Oo this could be a match made in heaven. I’ve been daydreaming about this for a while now: CAD in Julia?

7 Likes

Funny to see this in that thread:

I guess pythons advantages is the clean syntax and the big user base.

It’s only the latter, especially if you’re working with something as complex as CAD. :slightly_smiling_face:

4 Likes

This made me lough :rofl:
Funny to see others spotted it too.

Unless some big revolution happens in a foreseeable future i feel that Python is the place to be.

Maybe someone will be surprised in a foreseeable future. (ok, I am too optimistic, but who knows…)

3 Likes

I see Julia as an alternative to the python world. Julia allows faster computation but is still a very new language. Introducing Julia to freecad is a more difficult task than one might expect.

I guess pythons advantages is the clean syntax and the big user base. Accelerating python via jit is possible with numba which is in my eyes a good approach to speed up more time intensive functions.
With binding tools like pybind11 it’s also quite simple to speed up things with c/c++.

In my eyes a lot of bubbeling is build around Julia via advertising. At least this is the impression after receiving some mails every month which tells me to switch to Julia… I guess Julia is not only a community driven approach and therefore advertisement should be consumed carefully.

So from freecad perspective we should better concentrate on the python approach. There is a lot of things which can be optimized. In the long run bubbles will burst and only the working stuff will survive.

https://forum.freecadweb.org/viewtopic.php?f=8&t=42400#p360112
This is quite severe.

What I read here is that they (or the OP) seem to suffer hard from the two language problem but don’t know/realise it.
(It is from Jan 13, 2020, so not, lets say, 6 years old, which would make it understandable)

What can we learn from this? It’s a long way to go to break down prejudice, resentments and barriers in mind.

1 Like

It feel similar to reading the comments from Why Numba and Cython are not substitutes for Julia. Most of the comments can be summed up as “you can make that Python code a bit faster if you use this C/Fortran piece of technology (which is also incompatible with the other C/Fortran piece of technology that you used to make it fast in the first place)”, while missing the whole point of the article.

Now I had a hard time with this blog post, I think it’s not the best to advertise for Julia. For me, it is a long time in reading where I don’t know, what @ChrisRackauckas wants to say. And it’s just too lengthy. But finally I reached the comments and yes, reactions are of similar attitude but by far not as explicit as I quoted from the FreeCad community.
Chris is really doing a good job in advertising Julia with great stamina, he can probably tell more about general resentments.

1 Like

So not to step in where I don’t belong, but gonna anyways. Several users here have CAD capabilities in the works via Julia and are experts!

Converting FreeCAD to Julia may be a win. But there are serious holes in our ecosystem making that difficult. Julia is stronger in GUI components than it once was, but still compared to python there’s a lot of work to be done. FreeCad is probably 30% UI/UX, and it’s admittedly not the best UX, but very usable. Thus far I can’t think of a software tool that’s freely available written in just julia featuring a GUI - it’s really not a big part of our culture yet - we’re mostly all mad scientists doing numerical stuff for a living who got pigeon holed into Julia because there is nothing remotely better for this stuff. As far as I know Sherlock.jl which was a complete experiment, is the only package that you can invoke an interactive GUI that has an intended UX in (but could be wrong - if I am wrong please tell me so I can get ideas).

But maybe the right thing to do is to show them some of what we have cooking, IE: https://github.com/sjkelly/Descartes.jl, etc. as they develop over time, or showcase why you would want a julia compute engine for sanity sake and sure performance. This all being said - FreeCAD isn’t exactly sluggish, I’ve used it for some pretty detailed things on horrible computers and it never crashed or was noticeably slow. If it were faster it could feature more involved operations though. But for doing basic CAD it’s solid considering it’s free!

The real advantage to a Julia CAD is what physicists could do with it. Our FEM, Top Opt, etc ecosystem is duplicating and evolving pretty quickly. That’s another really cool angle.

Maybe best to just go it alone until things progress, and see if we can get contributors to the CAD ecosystem we have here already? OpenSCAD has far less UI/UX and very targetible as sjkelly is showing.

1 Like

It’s all about adding Julia to FreeCAD just as Python/C/C++ is currently used. Just an add and lets see what happens and even this triggers IMO huge and severe resentments which really makes me sad.

3 Likes

I see what you’re saying. In that case! Yea why not?

But yes, I do know the resentment you’re talking about. I’ve failed to get people in my company to adopt Julia on many occasions. In some regards it’s actually been used against me… So yea. Sorry my last post was more from a pure Julia perspective. I misunderstood, sorry.

1 Like

That article is for a very specific audience. Basically, I kept getting questions about whether Numba or Cython could just do it all, so I wanted to very clearly, on a very real problem that I care about (differential equations), show that is not the case in order to then explain why. It turns out inlining functions really matters for cheap expressions (and you can measure this in Julia!), and so just slapping separately compiled codes does not get you to optimal speed, and you can measure this.

This article is a lot of fun because it invites people who don’t understand the concept to try and “beat it” (of course, you can’t beat it because you can tell that the cost of not inlining here is enough to cause a difference), which mostly then just serves to show that the difference is exacerbated by a few other factors based on the limitations of these subset compilers. If you fudge things around a lot, use non-standard libraries, you can get to 4x. You can only get 2x away from Julia when you finally use Jax, but again, that’s actually using a Jax implemented ODE solver so it can inline into it, which just further proves the same point :). So it’s a somewhat technical non-technical dive that is really there to slap people in the face with a challenge and fail when they try the simple Numba trick, and of course it’s guaranteed to not get all the way in performance because of this fact.

This of course doesn’t matter for all use cases, it’s specifically about higher order functions like optimization and differential equations, but wouldn’t be an effect seen in something like ML. But it’s an effect worth noting to a lot of applications. Specifically to this conversation though, it wouldn’t matter to the FreeCAD use which wouldn’t be pure Julia and would have large kernel costs.

5 Likes