For those who are interested, I have found a way to work around the issue. The python-command to continue a Simulation called: thermal_initial_global.InitializationOptions.enum.ContinueSimulation can only take the first argument, which in my case is "heating 0". So if you now have created "heating 1" based on "heating 0", and then proceed to delete "heating 0", the only available argument is "heating 1". This will enable you to further continue your simulation. You can delete a simulation using the following command: document.AllSimulations.Remove(thermal_sim) given you have returned thermal_sim, of course. If you create an empty list, you can append your thermal_sim's into it and then choose which item you want to delete. I am sure there are more elegant methods, but if you need to do this specific task, it works.

This might be an old question, but I have just stumbled accross this problem and solution recently. Someone reading this in the future might find it helpful. The code you were looking for is the following: #Sources heat_source = thermal_sim.AddHeatSourceSettings(em_sim.OverallFieldSensor) heat_source.NormalizeToInputPower = True heat_source.PowerScaleFactor = 6, units.Watts Assuming you want 6W of power, of course.

The problem has to do with (to me) unlogical ordering of the 'weights'-dict. I have made a workaround which extracts the values from the dict in alphabetical order of the keys, which seems to work.

This should work: [outputname.replace('Output', 'Input') for outputname in [sim.GetOutputFileName(i) for i in range(sim.NumberOfResults)]] however, I could not find a way to programmatically generate the input files themselves, in case they are missing. First of all, the WriteInputFile() function is only available via sim.raw.WriteInputFile() (instead of simply sim.WriteInputFile()) and it only generates the input file for the first port (which is probably a bug in the API). One possible workaround (albeit not entirely satisfactory) is to call sim.RunSimulation(wait_for_submission=True) for all the multiport simulations, which will ensure that all input files are generated and all simulations are enqueued in ARES. You can then manually kill all of these submitted jobs from the Task manager of Sim4Life....

Note: I would even recommend to raise an exception if the pipeline fails to update, before continuing with the data processing. This makes the scripts easier to maintain in the long run: S11 = simEM_results["EdgeSource (Dipole)"]["Reflection Coefficient(f)"] assert S11.Update(), 'Failed to update pipeline' S11_data = S11.Data.GetComponent(0)

Dear Redi, you can export arbitrary data to Matlab (e.g. field array and grid coordinates) using the Scipy.io library. A generic use of it is the following: import scipy.io as sio dict={'field':fieldarray,'xgrid':xgrid,'ygrid':ygrid,'zgrid':zgrid} sio.savemat(filename,dict) where xgrid,ygrid,zgrid are the vectors containing the cartesian coordinates of the grid.

Brilliant, thanks!

Okay good to know!

This error typically means that one algorithm (the Hyperthemia Field Optimizer, in your case) does not have a complete Python interface. Sometimes it means that some properties are not available via Python, sometimes it means you cannot use the algorithm at all (I am not sure in which category the Hyperthermia Optimizer falls). Note that there is a newer version of Sim4Life available (v4.0.1), but I don't think any change has been made to the Hyperthermia Field Optimizer in that release.

I found the mistake. There was one pixel shift in the lines that i was comparing. The rest was correct.

Works perfectly, thanks! Edit, I think you could also get away with: import s4l_v1.model as model import XCoreModeling def get_spline_length(spline): wire = XCoreModeling.GetWires(spline)[0] return wire.GetLength()

The behavior you are describing is a related to a not-so-uncommon misunderstanding of the .Transform property. Model entities in Sim4Life have a Transform property (which you access by obj.Transform, for example). This property holds the transformation matrix between the initial object and its final position. This means that it holds the composition of all the transformations that have been applied to this object since its creation. So when you write something like obj.Transform = Rotation(axis, ori, ang), it does not just rotate the object - it replaces the transformation by a simple rotation, erasing all previous displacements. To apply a rotation, one should instead use obj.ApplyTransform(Rotation(axis, ori, ang)). The same is true for applying a translation: first define a Translation object (which is usually independent of the Transform property of the object itself), then apply the transformation. For example: from s4l_v1.model import Vec3, Translation, Transform import numpy t = Translation(Vec3(-20, -16, 10)) # for a translation r = Rotation(Vec3(0, 0, 1), numpy.pi / 4) # for a rotation of angle pi/4 around the z-axis case = model.CreateSolidBlock(Vec3(0, 0, 0), Vec3(40, 16, -140)) case.ApplyTransform( t ) case.ApplyTransform( r )

The gridding algorithms are quite different in V17 compared to V14.8, so many options simply do not have a one-to-one conversion. The best strategy is probably to learn how to use the gridder in the GUI of SEMCAD 17 (in particular the Manual Grid Settings) and then use the "To-Python" function to auto-generate the corresponding Python scripts. I don't know V14.8 well enough to answer your other questions from the top of my head and my current V14.8 installation is acting up, so I can't help with your other questions right now. I will as soon as I fix my setup!

I had a look but also did not find it, so I added a function ConvertToPolyline which will become available in the next release (you can test it internally next week).