[WIP] expose Excitation::CustomExcite and add new Excitation::Dump and Excitation::Noise

[thliebig]

As I think discussed elsewhere, please separate the different new excitation approaches. It would be nice to have the custom excite exposed to python. But the two other excites (dump and noise) are not even at all implemented in CSXCAD and/or openEMS? Thus a python interface makes little sense? And again, I'm not convinced at all that a "noise" excite makes any kind of sense to begin with (e.g. in terms of simulation/excitation length and bandwidth/pulse length economy) ... In that sense I will close this and ask to open new and separate PR's, thx

[oberstet]

It would be nice to have the custom excite exposed to python

ok, I will submit a new PR with only this change [1]

But the two other excites (dump and noise) are not even at all implemented in CSXCAD and/or openEMS?

yes, this PR is a skeleton only proposing APIs, it was only to gather first feedback / measure interest

so I figure:

[2] a new white noise excite: no interest, wouldn't be merged [3] a new entry point to load excite dumps previously stored using the existing dump: no interest, wouldn't be merged

right?

that's cool for me, I will submit a new PR for [1] even though personally, I don't have a use for it.

[thliebig]

[2] a new white noise excite: no interest, wouldn't be merged

No I would not say it like this. If you get it implemented completely, tested and can show that it has any use or is any good I surely will merge it. But see also option 2 below

[3] a new entry point to load excite dumps previously stored using the existing dump: no interest, wouldn't be merged

Reading an excitation function from file is a valid idea and could be useful. But you "skeleton" was not good enough. You cannot have two signlas voltage/current from a previous dump, but only a single simple excitation signal over time. This would then be sampled/interpolated inside openEMS for use with either voltage excitation and/or current excitation. This way you could even get your noise into openEMS by just using a dump. Additionally you always need a f_max option to tell openEMS about the upper frequency limit e.g. for dump sampling rates etc.

[thliebig]

but only a single simple excitation signal over time.

This e.g. could be generated by any external simple tool. Just dump two columns "time vs signal" and be load that into openEMS to be resampled as the FDTD timestep requires

[thliebig]

And additionally I would prefer tested working code and not skeletons...

[oberstet]

This way you could even get your noise into openEMS by just using a dump.

yes, that's what I figured, plus: I can use Python and not fuzz around with C++ (no problem, I can do, but I prefer not to if possible/sane to do so)

Reading an excitation function from file is a valid idea and could be useful. But ...

awesome! thanks for the feedback! that's exactly the kind of early review/discussion the skeleton PR was intended for. now that I know constraints/side-conditions/interest, it makes sense for me to think about whether I now have time to invest into

And additionally I would prefer tested working code and not skeletons...

my folly was not understanding the

You cannot have two signlas voltage/current from a previous dump, but only a single simple excitation signal over time.

implications which extend to the API

hence, some working code would have maybe allowed me to recognize this API defect myself;)

but then again: my most valuable resource is time, hence I was driven over the years to be quite terse, minimize work done, because if stuff doesn't make sense / isn't of interest, why would I waste time with details like implementation? for me, APIs are crucial, implementations is just a matter of work / figuring it out. anyways, "working prototype code" is always better, I agree.

[oberstet]

No I would not say it like this. If you get it implemented completely, tested and can show that it has any use or is any good I surely will merge it.

fwiw, just to conclude this for now, I will likely come back to this at some point.

rgd "any use", here is just a quick example

https://ui.adsabs.harvard.edu/abs/1995A%26A...300..707T/abstract

which I came across now that I had a quick look for Python libraries which allow me to generate arbitrary power law noise, of course there is one

https://github.com/felixpatzelt/colorednoise

white noise is just one thing to try. pink noise or brownian noise another, and the general form for that is power-law noise, also called "colored noise"

https://en.wikipedia.org/wiki/Colors_of_noise#/media/File:The_Colors_of_Noise.svg