Coming from an aerospace/automotive engineering background, I’d be curious to gage the interest for a engineering-focused domain. I’ve seen some projects that would fit, like JuliaFEM, JuliaControls, NLOptControl, and Modia, and it’s an area of application I’m really hoping to see/develop more of.
Is there a “critical mass” needed to justify a domain? If so, what would that look like?
Maybe a good idea. I worked in Formula 1 a few years ago. Lots of CFD of course and Finite Element.
But with a name like @CrashBurnRepeat you are not filling me wit confidence 
All of these topics you mentioned seem to fit in the Modelling & Simulations or Optimization (Mathematical) domains nicely.
I considered that, but then again there’s a distinct Astro/Space domain that could also (theoretically at least) be rolled into Modelling & Simulations, so I wasn’t sure when a domain becomes large enough in the community to justify its own section.
The name was meant with a certain amount of… tongue in cheek 
Also, from a more modeling/simulation/optimization background, our crashes tend to be a lot less catastrophic, haha
I am afraid that may be how engineers learn: history teaches us that the most valuable lessons are failures.
When there are a lot of questions in that area - which doesn’t seem to have happened yet as far as I can tell (but I may be wrong).
The splits should be practical. Domains are set so that way people can follow the questions which are related to them and their work. Modeling and simulation involves diffeqs (ODE/PDE/SDE/etc.), finite element, control theory, etc. If your question is about using those libraries in an engineering context, then you probably want to ask in a place where those developers and maintainers are actually looking/reading.
On that other hand, if the domain has a bunch of domain abstractions such that most users aren’t using the underlying core directly (for example, I know about the JuliaAstronomy that uses DifferentialEquations.jl/OrdinaryDiffEq.jl underneath), then the questions should be going to the domain experts and their package developers and not necessarily everyone who uses a diffeq or finite element package. So it makes sense for astro to have a domain since a lot of people doing astronomy, while they may be solving simulations, they may not be actively interacting with the core numerical simulation libraries but a domain-specific abstraction on top of it.
But I still think (as I noted from the very beginning of the Discourse) that modeling/simulation should just be merged with numerics so that way it’s just the domain of numerical methods for scientific computing. Then any application is in some other domain.
Not all simulations and models are numerically intensive though or use linear algebra. Discrete event simulations, e.g. finite state machines, are counter-examples.
Thank you all for the clarification Sounds like this would be better to revisit once there’s more interest from the community. Now just to get even more engineers using Julia…
What is an engineer, though? Or rather, an engineer who is interested in picking up Julia? Are we excluding specialized software engineers to make it more of a useful definition?
So here’s one go at defining a more narrow group that might have common interests. We may be less specialized than today’s scientists. We’re doing analytical calculations where units are more often useful than in the sciences. We’re working with 2d or 3d modelling, explicit or implicit finite element analyses, hydraulic or control system simulations. We’re conforming to thousands of pages of rules, laws and regulations that we’d love to have some program interpret for us. We’re using expensive, monopolistic software by industry standard. We’re dealing with conservative IT departments, firewalls, Windows, and colleagues who really want to avoid learning yet another programming language.
If that’s no basis for a group, perhaps we could have a chat over a beer, in London?
Now you’re speaking my language, programming or otherwise. I’d love to break that standard/monopoly, as utterly ambitious of a goal as that may be.
I was debating how to describe “engineering” in this context, because it is such a broad field. It’s a problem of wanting to be inclusive while still being exclusive enough to have a well defined focus. I like your description though, putting it in terms of the problems we are looking to solve and what might bring people to Julia to seek new solutions. A more “goal-oriented” approach.
And yes, I will be in London; would you be up for a beer even if we’re in agreement? Perhaps we could even find some likeminded individuals to join in.
I’m up! Too keep it low key, perhaps start a slack or gitter channel during the conference?
Perhaps engineering is too broad as a domain? Since you mentioned aerospace, I’d be interested in contributing to an aerospace domain if there was critical mass. We’ve been developing a number of aerospace tools in Julia within our research lab. None of them are registered, but a few are open source and many others will be soon. Once 1.0 settles we’ll make a more concerted effort to get things ready for broader use. For example, some of the tools we’ve developed or are developing include: blade element momentum (propellers/turbines), vortex lattice methods (lifting surfaces), airfoil aerodynamic analysis methods, classical laminate theory and composite failure theories, electric motor models, solar models (for solar-powered airplanes), beam finite element, semi-empirical acoustic models, six dof dynamic model for aerospace vehicles, wind turbine wake models.
That all sounds amazing. Will you be in London as well? I have a number of questions about how you’re getting things ready that play into whether this could be seen as a broader “engineering” project or a specifically aerospace one. But yes, I suspect aerospace/automotive engineering are traditionally the biggest consumers of these kinds of tools.
Sure, that sounds like a good idea. I’ll keep an eye out for the channel and try to create one if I don’t see it first. Maybe I’ll ask for an announcement if I don’t mind pushing my luck
Unfortunately no, I won’t be there. As examples, the blade element momentum model is here:
https://github.com/byuflowlab/CCBlade.jl
and the vortex lattice method is here:
https://github.com/byuflowlab/VLM.jl
They have been tested quite a bit (though not all tests are in the repo yet) but there is no real documentation other than examples.