ZMT zurich med tech

We are excited to announce the release of Sim4Life V9.0. Now powered by o²S²PARC technology, Sim4Life amplifies its industry-leading simulation capabilities for design and optimization – from body-mounted wireless devices to medical technology and basic research, setting benchmarks for user experience and third-party extensibility. [image: 1752499181982-2506_s4l_v9.gif] What’s new: Unified Ecosystem: Thanks to full incorporation of o²S²PARC technology, the unified ecosystem allows straightforward integration of user and third-party tools, making Sim4Life an easily extendable, universal simulation platform and enabling the development of advanced, shareable workflows. New Plugin Framework: Third-party solvers can now be integrated, as demonstrated by the beta integration of the ray-tracing engine SionnaRT and the FEniCS FEM simulator. Meta-Modeling Preview: Parameterized models can now be intelligently and efficiently explored, e.g., using response surfaces and multi-goal optimization. Cloud-Powered: Users can tap into high-performance CPU/GPU cloud resources directly from the desktop, and monitor simulations in real time. Fully Shareable: Projects are easily and safely shared with coworkers. Learn more about the release here. Access it via sim4life.io, sim4life.science, or sim4life-lite.io (free for students), or download the latest desktop version from our website. A comprehensive list of Sim4Life V9.0’s new features, improvements, and fixes (web and desktop versions) is provided in our Release Notes. Please send your feedback and suggestions to s4l-support@zmt.swiss.

When the stop button is pushed in the task manager, while a simulation is running, it will generate an event that is equivalent to "enforcing" a "convergence reached" state from the solver perspective. That's why the following log will appear inside the Solver-Log tab WARNING: [...] Simulation end request received. The solvers starts to consider this. Steady state detected at iteration x, remaining time steps are y. Simulation performed z iterations. Elapsed time for 'Time Update' was xx:xx:xx wall clock time.

I see. That's a different issue, and not related to multiport/combiners/etc... The source volume (which you use in the "second" simulation, the one with Huygens Sources) has to be smaller (by at least one half grid cell, but I would recommend an extra margin of one grid cell) than the sensor of the "first" simulation (the one with the incident fields). The reason is that the incident fields are interpolated onto the "second" grid at the locations of the huygens sources (and the interpolation scheme has the requirements I mentioned above). Check the coordinates given in the error message if you want to know the location where the "padding" condition was violated. I hope this helps.