Will EMerge ever get a GUI?

Although EMerge doesn't currently have a large user base, I've received numerous inquiries from the few interested users about whether EMerge will eventually feature a GUI or some form of visual interface for modeling. Additionally, some users have asked if it's possible to import models from CAD programs.

This naturally leads to the question of why EMerge lacks a GUI and is instead developed as a Python module. In this post, I aim to explain why EMerge doesn't have a GUI and whether it might in the future.

Here's a quick summary: EMerge will get a GUI eventually, but it won't happen soon.

Why EMerge doesn't have a GUI

There are two primary reasons why a GUI hasn't been implemented yet, but one is particularly significant.

Programming GUIs involves a lot of work and making them compatible on MacOS, Windows and Linux is very challenging.

GUIs are notoriously difficult to program due to various asynchronous processes. However, that's not the most challenging aspect, as modern tools like Qt simplify many of these tasks.

The main reason is that they make development significantly more time-consuming. Each new feature requires a button, a menu, a dropdown box, etc., and if there's a design error in the UI, you have to start from scratch. I don't have exact figures, but developing new features would probably take at least ten times longer if I had to integrate them into a UI compared to just implementing them in a Python module.

This reason also explains my timeline for when it will be implemented: Once EMerge is mature enough that I don't anticipate any major changes. At that point, I can design a UI with a comprehensive understanding of all the features it needs to support.

Beyond the delay in implementation, there's another reason. If I believed a UI was essential, I would have already implemented one. The second reason for not having a GUI is that I don't consider them very important.

Why I don't believe a GUI is important

Okay, I know this might sound a bit out there, but bear with me. First, let me highlight a couple of important points.

In certain applications of FEM software, product design and simulation occur within the same environment, which is quite common in structural mechanics programs. Another major application is PCB design. I would never suggest that those work flows would lend themselevs well to a code-based modelling approach; that would be a nightmare. I understand that there might be many users who are used to working this way.

So yes, to those people, I understand a GUI would be useful but for you, EMerge just might not be the right tool sadly. But before you write it off, maybe consider the following.

The reason I don't think EMerge would benefit significantly from a GUI is more related to the physics we're simulating.

EM physics is quite distinct. It might be closest to acoustics in linear models, but beyond that, it's quite unique. For reasonable efficiency, one typically uses second-order curl conforming basis functions. For EM physics, this results in 20 degrees of freedom per tetrahedron, leading to at least 400 coupling terms in the final matrix per tetrahedron! This is considerably more than many other kinds of physics (lets not talk about fluid dynamics). These basis functions also makes matrices ill-conditioned and causes computational complexity to increase rapidly with problem size. Furthermore, due to wavelength-related properties, you can't use arbitrarily coarse samples for very large geometries. This differs from structural mechanics or basic heat transfer physics, where a maximum mesh element size is not a requirement. As a result, throughout most of the history of FEM simulations, solving large problems was not even possible.

I recall reading documents from my previous work as a radar antenna engineer, where they described simulating a slot-coupled stacked patch antenna. They solved the resonating cavity below the slot separately from the radiating patch part. These models were from around the 2010s, if I'm not mistaken (they might not have had very fast PCs). This is just one antenna and the total modal was too complex to run at that time.

What I'm suggesting is that for a long time, simulating large EM problems wasn't even feasible. The types of 3D models that would need a GUI where most likely too complex to simulate to begin with. Yet, people have benefited from EM solvers since at least the 1980s. How is that possible?Well, due to the remarkable linearity properties of Maxwell's equations, it's much easier to divide problems into sub-parts which can be glued together later (using S-parameters for example).

A second property of Maxwell's Equations is that small details can become less significant for your solution, depending on the situation. This may not apply to structural mechanics or fluid dynamics, where you can have scale-invariant dynamics, such as energy dissipating into eddy currents, etc.

The people who taught me to use EM solvers were those who experienced the release of the first versions of HFSS. This might have influenced my philosophy and thinking about this issue, but I don't think it's entirely unjustified.

To truly understand your EM model, you need to see its components. The art of EM modeling involves the ability to switch between thinking in transmission line models and EM fields.

Sure, today you can load your entire model into a 3D solver and press run, but is that the best approach? To some extent, what works, works. However, it's often much faster to break down a problem or design into subcomponents, optimizing and analyzing them individually. You don't need to model your entire RF distribution network. If you simulate all the bends, transitions and splitters separately, you can tie them all together in ADS or Qucs just as well. You might be surprised about that design approach but the people I worked with regularly had first-time right designs of entire Tx/Rx modules.

On top of the advantages of a reduced simulation time, this approach also forces you to understand better what all the moving parts of your EM design are. Ask yourself this: If you import your large 16-to-1 distribution network in EMerge and see a large S11 spike in your pass-band, do you know where to look? It could be any of the 25 parts that make up your design and each test and tweak will now take 20 times longer than if you optimized all the parts that comprise it.

You can simulate both the coax-to-waveguide transition along with the horn itself, but you can also design them separately. As long as all higher order evanescent modes decayed enough, you can be sure that the S-parameters may simply be cascaded.

With EM designs, you often just don't know the dimensions beforehand, which means you have to conduct large parameter sweeps to examine their effects. It's much easier to do all of that in reduced models before finalizing your design to see if it works than to model everything at once and not know which part in your simulation is causing your astronomical VSWR.

Wrapping up

In short, I think that most crucial simulation work should be done using simplified models. Instead of simulating an entire PCB, you model a 90-degree bend to determine the optimal chamfer, or you analyze a Wilkinson splitter to find the best curve radius, and so on. You compile all these components into a final design.

Of course, you might want to run the final PCB through a FEM solver to check its functionality, which can be beneficial. In that regard, EMerge isn't quite there yet.

If you feel EMerge isn't useful without a GUI for modeling, it might be because you haven't learned how to simplify your designs and examine the moving parts. Now don't take this the wrong way, its also possible that in your work flow, that is just how things are done. But beyond PCB design and final checks on larger systems, I don't see real applications where the 3D model couldn't be programmed. If you have such a case, feel free to let me know!

In the long run, I plan to rewrite the entire EMerge codebase before developing a UI. When I do, I might need to hire a programmer for that task.

For you, the users, here are the key things I want you to take away from this:

1. Don't underestimate the effort required to manage a well-functioning UI. I could either focus on implementing the features you need or spend significantly more time integrating existing features into a GUI.

2. Consider whether you truly need it. If your design is too complex to model with code, perhaps it isn't meant to be fully simulated. Can it be simplified?

3. EMerge will eventually have a GUI, but development won't start for at least 1 to 2 years (unless I start earning significantly more money in the meantime).

Finally, if anyone is willing to wrap EMerge in a GUI, I promise to support that development as much as possible. However, be aware that the interaction with EMerge v2 may differ significantly from EMerge v1.0, which will be released in September. You might need to start over with much of it when I switch versions.