Calculate timestep after meshing but before simulation

[BatchDrake]

Hi,

Does OpenEMS provide an API to calculate the CFL / Rennigs time step after meshing but before running the simulation?

A little bit of context here: I am using OpenEMS to optimize the dimensions of a filter, which involves running a script to tweak its geometrical parameters in different ways. For instance, one of these parameters could be used to control how to notch certain section of a microstrip:

But since the optimizer performs a random search on the parameters within certain bounds, we can arrive to degenerate situations like this:

In which the small size of the notched part results into an extremely small step in that point, requiring an equally small time step that I would like to rule out before even starting the simulation.

Of course, you can say: "that's easy, just ensure the bounds do not allow situations like that". However, in some situations that is more easily said than done. The parameters may look sane, but at some point you end up with two sides of two unrelated elements too close together as projected in certain axis, resulting into a simulation that never ends.

One way to fix this would be by doing it myself: I traverse all the lines in the mesh, check the smallest step size in all directions, compute the CFL condition and that's it. But I'd prefer to ask before reinventing the wheel here.

Thanks in advance,

[thliebig]

Hi,

in short, no such function does not exist, but I agree that it might be useful. Maybe you would like to contribute a function that takes the mesh and maybe the highest material values (or lowest speed of light) and calculates a simple CFL timestep from that?

The longer answer is that calculating the (correct and final) time-step is not as easy as it sounds. In a first step the complete material averaging for the entire set of coefficients (including lumped elements and so on) has to be done to then be able to calculate the timestep. At this step the coefficients are almost done and simulation can start.
Therefore this was never made separate and it can be quite time-consuming for complex structures too.

Therefore having a very simple and rough estimation (see above) would be nice to have.

best regards,
Thorsten

[BatchDrake]

in short, no such function does not exist, but I agree that it might be useful. Maybe you would like to contribute a function that takes the mesh and maybe the highest material values (or lowest speed of light) and calculates a simple CFL timestep from that?

I'd love to. Where should I write it? I guess the sanest thing to do is to implement it in C++ and expose it to Python / Matlab next. Maybe as a method of ContinuousStructure.h or directly in openems.h?

[thliebig]

Well I think that algorithm should be very simple? No need to go C++? I would recommend directly as a python function in openEMS? maybe inside of the automesh.py as a helper function?

[thliebig]

Again I would just do it using the mesh lines and the lowest speed of light anywhere and nothing more... Yes it would only be a rough estimate, but that should be good enough in most cases?

[BatchDrake]

That's also possible, and would be quicker to write of course. I'll send you a PR in no time.

[0xCoto]

That would be useful indeed - I have also stumbled upon a similar situation in the past where it would be useful to know the timestep without having to invoke the simulation to run.

By the way what kind of optimization algorithms have you been experimenting with?

[BatchDrake]

All this is in a very early stage but, my first tests involved PDFO, then I moved to differential evolution and now I am comparing directly with "random" (i.e. uniform within certain boundaries). I was thinking on releasing the code somewhere, but right now everything is so ad hoc it would be embarrassing to show it to the world. It is also something I am constructing on top of pyems, in case you are curious.

[0xCoto]

Nice. FYI I've had luck with this: https://scikit-optimize.github.io/stable/modules/generated/skopt.gp_minimize.html

Not in simulations, but in real-world experiments (yes, with moving RF parts hooked up to a VNA). Worked quite well. The main difference here is that there's basically 0 noise in simulation results, but that shouldn't really be a big problem (in fact it should be even better).

I had also tried all(?) scikit's optimization functions but none of them performed as well. Perhaps I didn't use them too well though, as their parameters need some understanding. :)

[BatchDrake]

Thank you very much for that info, because so far I am basically trying stuff blindly. I am definitely going to include it in my optimizer, let's see how it performs.