Announcing GXBeam.jl
This package provides an thoroughly verified and validated implementation of geometrically exact beam theory written in pure Julia. It’s also extremely fast, rivaling Fortran implementations of geometrically exact beam theory in speed. For more details about this package’s many capabilities see the README and/or
the documentation.
As a side note, this package is also a good example of the effectiveness of StaticArrays at eliminating allocations in inner loops.
Is there a reason for not using ArnoldiMethod.jl? That way you could remove the “almost”.
There isn’t any particular reason. I’ll look into it. It would be great to remove the “almost”.
IMO there should be a really good reason for any attempt to knock out
some non-Julia dependency. Purity by itself is not a good reason, I believe.
For me the primary motivation for moving toward pure Julia code would be in order to use automatic differentiation tools.
FWIW, from the GXBeam.jl docs:
The “almost” here refers to the fact that the Fortran library ARPACK is used for eigenvalue computations. Otherwise the code is written with pure Julia and should work with custom types and automatic differentiation packages such as ForwardDiff.
I disagree, if there is not a single observable disadvantage and it is almost as easy as just importing another package to change. I think many advantages might also appear after some time, e.g. automatic differentiation, thread safety (ARPACK isn’t), arbitrary number types, …
That is really what I’m saying. In this case you have identified benefits to be realized sometime down the road. There is always a disadvantage though: replacing a dependency will involve work, testing, maintenance.
Probably I agree in many examples, but what we are discussing here is changing from
using Arpack
eigs(sprandn(10,10,0.1))
to
using ArnoldiMethod
eigs(args...;kwargs...) = partialeigen(partialschur(args...;kwargs...)[1])
eigs(sprandn(10,10,0.1))
And that doesn’t seem like all that complicated. Also, at some point I assume that the second line will not be necessary anymore.
Oh, I was talking about the dependency itself. Not about the client.
Super neat!
Being someone who doesn’t understand much of anything about beam theory, could you use this to model radial/circular elastic materials? If so I may have a fun project involving this.
Speaking from curiosity: what are radial materials?
Wrong word… I just meant shapes that have no start or end but have finite perimeters. Words are a bit elusive right now… So things like a circles, ellipses. Sorry its been a real long day.
Like this?
Yes like a rubber band!
Let’s talk.
I don’t know anything about circular elastic materials, but I don’t see why you wouldn’t be able to model them with this package. The only potential issue I can think of is if the small strain assumption is violated (which is used to construct the constitutive equations). I wouldn’t classify myself as an expert in beam theory, however.