Frame with Gap and structural Bars

[ecs-kev]

Hi,

I commonly work with through flow ventilated machines, which generally have a gap between the stator and the frame. The gap is usually created by having rectangular bars between the stator and the frame. I noticed that it is possible to define a frame with a gap (though it doesn't seem to be possible using the GUI), but I could not find a way to define the geometry of the structural bars.

I would like to try to add that functionality. What would be the best way to implement this? My plan was to add an additional class that inherits from Frame and has additional properties (Number of bars, Bar width) and methods (comp_height_gap).

Does this sound reasonable or is there a better/more preferred way to do it?

Cheers Kevin

[SebGue]

Hello Kevin,

your proposal is reasonable in my opinion. Depending on your actual needs, you may also try to use yoke notches (PR #376).

Do you need the frame and/or bars to be included in the FEA? This will require some further code extensions. As for the GUI, I plan to release some extension to the GUI, that will allow editing generic pyleecan objects.

Hope this helps for now. Best regrads, Sebastian

[ecs-kev]

Hi Sebastian,

There's a few things I would like to do with his type of machine: 1) Calculate some geometric parameters like the surface area of the gap (this could probably be achieved using the notches). 2) Couple it with a CAD package to create 3D parts. 3) Run thermal FEA on it.

To achieve 2+3 i would be useful to have the bars implemented, though it might take a while until I actually get to do these steps. I can't imagine the bars will have any impact on the electromagnetic FEA, so I wouldn't need them to be included for that.

Thanks for your feedback, I'll have a go at implementing the new frame type and see how I get along. Looking forward to the new GUI extension. I haven't really gotten my head around how the GUI is implemented yet.

Kind regards Kevin

[BonneelP]

Hello Kevin,

To complete Sebastian's answer, the Frame class was intended to be a cylindrical Frame with Rint that matches the stator Rext. So a "frame gap" was not intended (hence why it is not available in the GUI) but it should be compatible. Creating a new class with bars would be great :) Do you have schematics or picture of this topology ? Maybe for later extensions we will have to make Frame abstract and rename the existing one to "FrameCirc" for instance. Anyway this class is not that much used so you should be able to add your modifications.

Regarding the "comp_height_gap", I think that it is important to define a precise definition/name for "gap". Indeed, pyleecan should be able to simulate machine with more than two laminations (most of the code is there, we just have never tried). So as a follow-up to issue #344 I would propose to have Airgap-X with X the id of the airgap starting at 0 inner to outer. Then the question would be: should the "frame gap" be Airgap-"X+1" or should we set a different name "AirgapFrame"? The first solution is more generic (so it should be the best) the question is mostly: do we need to differentiate a "lamination gap" from a "frame gap"? Depending on the answer, then we would have either machine.comp_height_gap(id) or machine.comp_height_gap_frame(). What do you think ?

Regarding 2 and 3: the geometry modeller of pyleecan should help you: https://pyleecan.org/icem.2020.html. The coupling with FEMM for Magnetics already exclude the frame but we should be able to add an option to Functions/FEMM/draw_FEMM to add the frame if we want to add it (if we extend the model for thermal computations). You can also take a look on pyleecan coupling with gmsh to generate the 3D FEA model.

@SebGue is your next modification to the GUI related to #58 ? Will it be in the "extended GUI" part ?

Sorry for the long delay without answer, the summer holidays have a bit "challenged" our planning but I should be able to come back more regularly to pyleecan. I'm still focusing on the label PR, the code is mostly ready, I'm working on correcting all the tests.

Best regards, Pierre

[SebGue]

@BonneelP Exactly. I will go to holidays tomorrow, so I hope to have some time there to cleanup my current code and to finally release it. This will also close #58 :-) Edit: BTW: Would you mind to change the 'machineChanged', ... signals to a generic 'dataChanged'? So one could connect to the widgets without knowing what type of data (or class) it represents.

Best regards, Sebastian

[BonneelP]

No objection to rename the signal to a generic dataChanged. Anyway the signal connection context should be clear enough to know which kind of data have changed. Looking forward for your PR :)

Have a nice holiday :) Best regards, Pierre

[ecs-kev]

Hi Pierre,

Sure, I have some schematics of the machine type: This shows a typical machine without the frame:

And here is a slice through the centre of the core (plus some thermal results):

I hope this helps with understanding what I am trying to model.

Regarding "comp_height_gap": I am not sure what the best approach is to be honest. My gut feeling ist that you might want to differentiate beween gaps between 2 laminations and gaps between a lamination and a frame at some point, so I would probably go with that. But I don't mind the other approach either.

I managed to implement some basic functionality by now, such as drawing the new frame type (view below) and calculating some basic properties:

I am not quite sure how to continue from here though. Particularly what I am supposed to implement for the testing is a bit unclear to me. Any advice on this?

Kind regards Kevin

[BonneelP]

Hello Kevin,

After also discussing about it with my colleagues, we think that we can go with the "separate lamination airgap from frame airgap" and so we can go for machine.comp_height_gap_frame().

Regarding the Tests, here are some guidelines about Tests in pyleecan: https://pyleecan.org/tests_tutorials/test.contribution.Pyleecan.html Long story short, the best would be to create:

• Tests/Methods/Machine/test_frame.py to test each method
• Tests/Plot/test_frame.py to plot/save the image from your post above.

The point is to make sure that the code that you have created won't be broken by the next developments. So you can write the test on a configuration that will match your usage. If you want, you can open your pull request and we can guide you on writing/improving the tests.

Best regards, Pierre

[ecs-kev]

Hi Pierre,

Some guidance on the tests would be useful, thanks. I have openened the pull request.

Cheers Kevin