ZMT zurich med tech

Hi David, No — the Vector Potential solver has no B-H curve input. A magnetic material there is a relative permeability and a conductivity, and that's all it can do: no saturation, hysteresis or remanence in the low-frequency solvers. (FDTD has further magnetic models for dispersive media, but they're linear too.) Nonlinear magnetic materials have been on our development list for a while, but they have not been implemented yet. For your case I'd suggest the chain from your other thread: solve coil and core with the vector potential solver (lossless, so no tissues in that simulation) and feed the resulting A into the magneto-quasi-static solver on the head model to get the induced E-field. The LF tutorial "Wireless Power Transfer: Exposure Assessment" works exactly like this. You can handle saturation approximately by iterating the permeability. Solve once with the datasheet mu_r, extract B in the core, read the manufacturer B-H curve at that point, set the secant value mu_r = B/(mu0*H) and re-solve. Two or three passes should already converge quite well. Only the vector potential simulation involves mu, so that's the only one you would iterate. Note that B might be strongly non-uniform in the ferrite core, so a single uniform mu_r would average quite different local operating points. Splitting the core into two or three bodies (poles, yoke, the rest) and iterating each separately might be a good enough approximation, depending on your application. What this approximation gives you is saturation, not hysteresis: no minor loops, and nothing about core losses or the falling edge of the pulse. Also, ferrite mu depends on frequency as well as on B, and the solver applies one value at one frequency; take mu from the datasheet at a frequency representative of your pulse rise time rather than at DC. Everything above is scriptable (setup the two linked simulations in the GUI, then use To-Python to generate a good starting point for your scripts). Sweeping should work fine, even for linked simulations. Let me know if you have issues getting that to work! Best regards, Sylvain

Hello, To use multiple instances of the same HOC file in a single simulation, the neuron model must be defined as a HOC template (see Manual section 2.13.4.7.2, “HOC Templates”). In a non-templated HOC file, section names are defined globally. Loading the file more than once therefore creates duplicate section names, which NEURON does not permit. A template gives each neuron instance its own namespace, allowing multiple instances to be created and connected without naming conflicts. Please also ensure that the HOC template meets Sim4Life’s compatibility requirements, including matching the file and template names and placing the compiled mechanisms in the same folder as the HOC file.

thanks a lot for the clarification

To make a uniform grid, you can add all of your simulation objects to a 'Manual' grid settings folder, and then set the 'Priority' of that folder to 0. This will ensure that no grid 'baselines' are placed. Please refer to this forum post for more information about grids.

Even if your region of interest is well-resolved, running psSAR over the entire sensor/domain means the evaluator tries to process all relevant lossy voxels in that domain. If there is a region somewhere in the simulation domain where voxels are too large for the desired averaging mass, then the evaluator may report the “grid too coarse” error. Cropping away those problematic regions can therefore allow the evaluation to complete for the remaining volume. Values inside a cropped region are generally meaningful as long as the important features are not intersected by or too close to the crop boundaries. The exact definition of "too close" will depend on the averaging mass used. If you enable the "Compute Cube Information" option in the psSAR evaluator, you can inspect the averaging cubes that were used by the algorithm.

When you mention you are experiencing the same issue, do you mean that you are getting the same error message? Are you getting any license-related errors? Did you install the NEURON solver in the new server?

Dear Jihan, You can use one of our available ViP models and crop it to include only the leg, or define a simulation grid that covers only the leg region. For the electrode array, our template models include a customizable Paddle Electrode, which you can adapt to your requirements. I hope this helps.

Dear Jihan, The issue you are describing is related to the available screen space, which is too limited for Sim4Life. This can happen when Windows display scaling is above 100% or when the laptop screen has insufficient vertical resolution. Please check the display scaling setting and try 100%; if it is already at 100%, a higher-resolution external monitor may be needed. In any case, a solution is to right-click on the simulation tab and select "New" there to create your simulation. I hope this helps.

thanks Robin!

The text exporter is just called 'FieldDataTextExporter' instead of 'MatlabExporter'. However, I would first recommend that you try my suggestion of using the GUI to add a text exporter, and then right-click the analysis tree to generate the equivalent code. This is the best way of discovering the API equivalent of UI features.

In answer to my own question, I found the way: Extract the Titration Evaluator via the Titration Sensor, and check the 'Visualize spikes' option in the Settings field for the Titration Evaluator. Click refresh; this will create a folder of point entities in the modelling window with all the nodes of first spike location. The locations of these point can be access using ent.Position in Python or Jupyter, which can then be used to calculate distances to other points. I will note for the SIM4LIFE team, I could not find any examples or documentation for this method, nor is the 'Visualize spikes' setting exposed in the API. Please consider adding this in a future update, as I believe it to be a powerful and useful method. It would also be helpful if these nodes are named distinctly, such that they correspond to the Neuron fibers that they refer to. This would mean that you don't end up with a significant number of entities all named 'node[0]'. Thanks!