Eomys/pyleecan

Intended usage of OutInternal

Opened this issue · 2 comments

Hello,

there is an OutInternal class with 'Abstract class whose childs enable to store outputs related to a specific model' description.
What's the intended use of this class, i.e. its daughter classes.

Actually I wanted to do demagnetization calculations, i.e. post processing on OutMag.meshsolution. Since MagFEMM already got a lot of parameters, I thought I'd rather use inherited PostMethod class to do that.
Now the question is, where to store the results? OutMag got 'internal' property of class OutInternal, which could be a storage for the result. But I wonder how to actually use it. Especially since it only allow a single result to be stored.
Or is there an other place to store post processings?

Best regards, Sebastian

Hello,

The idea of the OutInternal was to gather model specific output, for instance OutMagFEMM inherit from OutInternal to store the FEMM_dict (we didn't want to extend OutMag with output only linked to FEMM). The point is to be able to clean all the data with out.mag.internal=None.

At some point we thought about adding an "output.my_post_data" (or any other name) that would be a dict to store anything related to the post-processing. But we didn't do it because for simple data we have the datakeeper that stores its own results and for more complexe post-processing we prefer to use the class generator to properly add the model and its related output. It's longer but cleaner and better enables to reuse the post/model for later work. For an extreme example, Losses could be seen as post-processing of the magnetic model.

Hope it helps,
Best regards,
Pierre

Hello Pierre,

I was affraid of such answer :-)
So mag.internal is indeed no place to store my data.

But there should be a way to store data that are not too complex to calculate but also impossible to get with Datakeepers.

I thought of some kind of plugin strategy where PostMethod is already half the way. My point to not implement my calculation with generator is to not extend Magnetics over and over again.
One could e.g. want to evaluate demagnetization in a specific way or get some mean yoke or tooth induction and so on.

Fortunately you menationed Losses. You are right, it is some kind of post operation in a specific module. But it also has the flexibility in its output due to the list/dict data structure.
So why don't we adapt Losses to PostMethod/PostFunction?

Best regards, Sebastian