Joule heating sources from various processes (e.g., EM energy deposition by ohmic losses) can be considered as inhomogeneous heat sources in thermal simulations.
To create heat sources

Simulation Link: Sensor settings of an EM FDTD simulation in the same project can then be dragged and dropped into Source Settings folder. Modulated Analysis/Cache: Data Origin Type can be defined as:
(a) Cache File: select the path of a thermal source previously exported into a .cache file.
(b) Analysis Output: select the energy density of interest directly from the Analysis.

You can look into the heated brain tutorial for a simplified example.

Hi,
There is most likely an error due to a sanity check, since you appear to have lossy tissues in your simulation and the Magneto Static Vector Potential solver does not account for those losses. Having a ferrous core, however, you do need to use that solver.
The trick is to chain 2 simulations: one that solves the magnetic vector potential (A), and one that uses this A as a source term to determine the induced electric field (this time accounting for losses). The key is to remove the lossy tissues from the first simulation (only metallic or ferrous materials play a role anyhow).
I would recommend you have a look at the LF tutorial called "Wireless Power Transfer: Exposure Assessment", since it uses the same technique.

In addition, it seems that "The solver may have run out of RAM"... I would therefore check the RAM usage to make sure it's not going beyond your resources. Note that using the technique above allows you to have two different resolutions: one optimized to properly resolve the coil, the other to resolve the tissues (as long as the domain sizes of the first simulation is large enough to include that of the second). This usually leads to smaller grid sizes, thereby reducing the RAM usage...

Hi Andrei, I replied on the other thread: https://forum.zmt.swiss/post/1941

Hi Andrei, this error shows when there are not enough MPI-QS tokens on your license to use all cores on your computer. If parallelization is set to automatic, Sim4Life iSolve will try to use all available cores, and one MPI-QS token per core is needed. You can change the number of processes (=cores) to be used by setting parallelization to Manual and entering the number of MPI-QS tokens + 1 (solver license).

Dear @NaraSakamoto

Thanks for your feature suggestion.

Dear Ali,

It looks like the path to iSolve is not set correctly. Please follow the steps below:

Open Ares on the machine where Sim4Life is installed Click on the blue cross at the end of the line labeled "Paths to the iSolve solver executables." This will open a pop-up window. (see the image below) If the list of solvers is empty or the one you intend to use is not listed, simply add the path to the relevant solver. Restart Sim4Life.

aresisolve.png

It looks like this is a bug. Until it is fixed, you can still add line sensors to LF simulations using the API.

Here is a quick example that adds an entity named 'Lines 1' as a voltage sensor:

# -*- coding: utf-8 -*- import numpy import s4l_v1.document as document import s4l_v1.materials.database as database import s4l_v1.model as model import s4l_v1.simulation.emlf as emlf import s4l_v1.units as units from s4l_v1 import ReleaseVersion from s4l_v1 import Unit # Define the version to use for default values ReleaseVersion.set_active(ReleaseVersion.version8_0) # Creating the simulation simulation = emlf.ElectroQsOhmicSimulation() # Mapping the components and entities component__plane_x = simulation.AllComponents["Plane X+"] component__plane_x_1 = simulation.AllComponents["Plane X-"] component__background = simulation.AllComponents["Background"] component__plane_y = simulation.AllComponents["Plane Y+"] component__plane_y_1 = simulation.AllComponents["Plane Y-"] component__plane_z = simulation.AllComponents["Plane Z+"] component__plane_z_1 = simulation.AllComponents["Plane Z-"] component__overall_field = simulation.AllComponents["Overall Field"] entity__line = model.AllEntities()["Lines 1"] # Adding a new VoltageSensorSettings voltage_sensor_settings = emlf.VoltageSensorSettings() components = [entity__line] simulation.Add(voltage_sensor_settings, components) # Editing AutomaticGridSettings "Automatic automatic_grid_settings = [x for x in simulation.AllSettings if isinstance(x, emlf.AutomaticGridSettings) and x.Name == "Automatic"][0] components = [entity__line] simulation.Add(automatic_grid_settings, components) # Editing AutomaticVoxelerSettings "Automatic Voxeler Settings automatic_voxeler_settings = [x for x in simulation.AllSettings if isinstance(x, emlf.AutomaticVoxelerSettings) and x.Name == "Automatic Voxeler Settings"][0] components = [entity__line] simulation.Add(automatic_voxeler_settings, components) # Update the materials with the new frequency parameters simulation.UpdateAllMaterials() # Update the grid with the new parameters simulation.UpdateGrid() # Add the simulation to the UI document.AllSimulations.Add( simulation )

To follow up on this problem just in case other people encounter similar issues, I found out that in my case this error was caused by cropping the region of interest out of the anatomical model.
I cropped the Jeduk static surfaces with Planar cut as well as the nerve trajectories to preserve only the torso/chest region. As a result, from some nerve trajectories that extend beyond the region of interest and loop back into the region, multiple wires resulted from the cropping. The discontinuity in these splines caused issues in discretization which showed up in the console as a "Failed to interpolate extracellular fields onto neurons" error for me.
This problem was solved by iterating through all the remaining nerve trajectories after cropping and checking using xcm.GetWires() how many wire bodies are contained in each trajectory. If there is more than one, the wire body with the max length is cloned and given the same name as the original trajectory and the problematic trajectory was deleted.

Hey there!
That's a pretty powerful setup with dual GPUs! To run two simulations at the same time, you can utilize parallel computing techniques to distribute the workload across both GPUs. Since you already know how to designate GPUs for each simulation, you might want to explore frameworks like CUDA or OpenMP, which are excellent for managing parallel tasks. Ensure that your simulation software is configured to support multi-GPU operations and check its documentation for any specific settings related to concurrent simulations. Sometimes, fine-tuning the job scheduling can also help in managing simultaneous tasks more effectively.
On another note, if you're interested in staying ahead with technology, check out Quantum AI. They delve into the fascinating world of quantum computing, which has the potential to transform simulation and problem-solving in groundbreaking ways. Best of luck with your simulations!

@brown
Thank you, I will check these things. Additionally, there are some warning messages which may help:
7427af6d-b388-4d9a-b629-2678e1872293-image.png
Is the mesh division not precise enough？

You definitely have enough memory here. It's likely that the solver could not use the device for some other reason. Can you try updating your graphics drivers?

Thanks for your reply

I think you can change how the steps change between gridlines with the grading option. If you have some entities that should not influence the grid set priority to zero (for those entities). Then choose the largest grid step you want for the global settings and and the smallest (0.5mm) for the arrays_grid. You should manage to control how the grid changes away from the arrays_grid.

When using a long line as "normal" edge source, the discretization will result in one edge being the actual source and rest of the line being discretized as PEC filament. This can lead (depending on the excitation frequency, the length of the source line and the setup) to inaccuracies due to the additional capacitance introduced be the PEC filaments. An alternative that is, in most cases, a more accurate source representation is using the "Distribute Along Line" option, the source is equally distributed over all the discretized edges of a line element (see image, right). That prevents any PEC filaments and therefore makes the injection of the signal more realistic.

Time delay = distance between the transmitter and receiver*sin(theta)/c where theta is the angle of antenna. I would suggest looking into antenna array literature for theoretical background on calculating this quantity.