Brew install is broken - numpy, tinyxml and cmake versions

[tdunning]

I was just trying to install using brew and ran into three problems.

The first is that that openEMS depends on numpy 1 and that is becoming an antiquated stance. I can uninstall numpy, install the most current version 1, at least until I run some other software.

$ pip3 uninstall numpy
$ pip3 install numpy==1.26.4 

Second, the tinyxml package was disabled in brew recently (on 2025-06-03) due to the tinyxml project being abandoned. The real fix is to convert to tinyxml2, but that is a significant change that would require testing that I don't even understand how to do. There is a fairly disgusting work-around involving tapping the core cask in brew and manually deleting the disabled flag from tinyxml. Not nice at all. But effective. At least effective enough to get me to the next problem.

$ brew tap homebrew/core --force
$ brew edit tinyxml
... editing session ...
$ HOMEBREW_NO_INSTALL_FROM_API=1 brew install tinyxml

At this point, installation goes forward to the point where this message pops up:

$ brew install --HEAD openems                                    
==> Downloading https://formulae.brew.sh/api/formula.jws.json
==> Downloading https://formulae.brew.sh/api/cask.jws.json
==> Fetching downloads for: openems
==> Fetching thliebig/openems/openems
==> Cloning https://github.com/thliebig/openEMS-Project.git
Updating /Users/tdunning/Library/Caches/Homebrew/openems--git
==> Checking out branch master
Already on 'master'
Your branch is up to date with 'origin/master'.
HEAD is now at a1e1be4 update submodules
Entering 'AppCSXCAD'
Entering 'CSXCAD'
Entering 'CTB'
Entering 'QCSXCAD'
Entering 'fparser'
Entering 'hyp2mat'
Entering 'openEMS'
/Users/tdunning/Library/Caches/Homebrew/openems--git/AppCSXCAD
/Users/tdunning/Library/Caches/Homebrew/openems--git/CSXCAD
/Users/tdunning/Library/Caches/Homebrew/openems--git/CTB
/Users/tdunning/Library/Caches/Homebrew/openems--git/QCSXCAD
/Users/tdunning/Library/Caches/Homebrew/openems--git/fparser
/Users/tdunning/Library/Caches/Homebrew/openems--git/hyp2mat
/Users/tdunning/Library/Caches/Homebrew/openems--git/openEMS
==> Installing openems from thliebig/openems
==> cmake .
==> make
Last 15 lines from /Users/tdunning/Library/Logs/Homebrew/openems/02.make:
-- Detecting CXX compile features - done
CMake Error at CMakeLists.txt:7 (cmake_minimum_required):
  Compatibility with CMake < 3.5 has been removed from CMake.

  Update the VERSION argument <min> value.  Or, use the <min>...<max> syntax
  to tell CMake that the project requires at least <min> but has been updated
  to work with policies introduced by <max> or earlier.

  Or, add -DCMAKE_POLICY_VERSION_MINIMUM=3.5 to try configuring anyway.


-- Configuring incomplete, errors occurred!
make[2]: *** [fparser-prefix/src/fparser-stamp/fparser-configure] Error 1
make[1]: *** [CMakeFiles/fparser.dir/all] Error 2
make: *** [all] Error 2

If reporting this issue please do so to (not Homebrew/* repositories):
  thliebig/openems

Warning: Unable to query GitHub for recent issues on the tap
Validation Failed: [{"message" => "The listed users and repositories cannot be searched either because the resources do not exist or you do not have permission to view them.", "resource" => "Search", "field" => "q", "code" => "invalid"}]
openems's formula was built from an unstable upstream --HEAD.
This build failure is expected behaviour.

Anybody have hints about how to proceed here?

[VolkerMuehlhaus]

Yes, the issue is already discussed in the "issues" section, with some really useful workarounds.

Last week, I successfully installed using the manual installation method described by @biergaizi here:
#328 (comment)
with the alternative method for the Python binding that he described here:
#328 (comment)

I made some mistakes, as you can see in the thread, but it finally worked.

[biergaizi]

Better to completely remove Brew from documentation for now before a contributor steps up. I'll submit a PR.

[tdunning]

As a partial work-around, I find that a containerized build (following https://github.com/tclin0122/openEMS_docker.git) runs well under podman except for visualization of the model. I find that the GL dependency of AppCSXCAD is just horrible to try to get running.

As a workaround to all of that, I have built a small visualization system that reads the xml rendition of the physical model and displays it in a web viewer. This seems promising, actually, and getting a working viewer has taken less time than what I spent on failing to deal with a remote OpenGL library. My current work is in Julia, but I expect that it could be translated to Python fairly simply.

In summary, I would suggest that putting a Dockerfile into the distro would almost be worth dropping the brew port entirely especially if a lightweight web-based viewer is acceptable.

[VolkerMuehlhaus]

My guess is that the memory access improved dramatically between the M1 and M4.

Thanks a lot for running this test! Memory bandwidth was indeed improved, 120 GB/s for M4 vs. 68.25 GB/s for M1.

I wonder what the openEMS performance would be using M4 Pro at 546GB/s ...

[tdunning]

That looks like just the ratio we saw in performance. Presumably, the scale would keep increasing!

[biergaizi]

My own experiment (already published a year ago) showed extremely poor memory bandwidth utilization on the M1 Ultra, it's perhaps running only at 1/5 of what the hardware is capable of. The current engine is just hopelessly inefficient from a performance perspective... I have several high-performance prototypes but I have too much different tasks at hand so I didn't finish them (although I plan to eventually do).

[VolkerMuehlhaus]

@biergaizi Thanks, I will look at those numbers! I agree that openEMS could do better, but for now, the speed that I obtain using the cheap entry level M4 machine is about the same* as much more expensive 16/32 core AMD machines. Having a better algorithm is of course much appreciated to finally use the "fat" machines more efficiently.

Until then, I use openEMS where open source solver is requested, and Empire XPU FDTD where simulation speed matters. Recent example for a multi-chip modul simulation: openEMS 90 minutes per port, Empire XPU 3 minutes per port, using the same Ryzen 9 5950X machine and similar mesh.

*) It should be noted that at least my fan-less Mackbook Air runs into thermal throttling of the CPU after a few minutes of running openEMS, and speed decreases by 25% or so. Mac mini should have better cooling, but is said to also have thermal throttling issues.

[tdunning]

These speed differences are similar to what I see with Tidy3D. On models that are comparable in size so that I can compare, I see about 140M c/s on my old Mac M1 and about 10-20G c/s on Tidy3D. It is very nearly 100x on these relatively small models. For the larger models, they get faster. In these case, small models are about 4M cells and the larger ones are about 18M cells.

I am pretty sure that I could get a new Mac mini with an M4 Pro CPU to get about triple the performance with openEMS compared to my current setup, but the remaining gap is pretty daunting.

[biergaizi]

In case anyone's reading this.

This error:

CMake Error at CMakeLists.txt:7 (cmake_minimum_required):
  Compatibility with CMake < 3.5 has been removed from CMake.

  Update the VERSION argument <min> value.  Or, use the <min>...<max> syntax
  to tell CMake that the project requires at least <min> but has been updated
  to work with policies introduced by <max> or earlier.

  Or, add -DCMAKE_POLICY_VERSION_MINIMUM=3.5 to try configuring anyway.

is also known, which has been fixed last month at here: thliebig/openEMS#184 But this PR is not merged yet as @thliebig appears to be busy on university duties.