eomys / pyleecan Goto Github PK

Hello everyone,
I am new to pyleecan and python as well. I have installed all the prerequisites. I was trying the "simulating the machine" tutorial on Jupyter notebook but at the last step of that tutorial where you have to run the simulation using mySimu.run(), it shows me a com_error. The description is pretty large and is attached in the file below.

com_error.pdf

Can someone help me out? Thanks in advance.

Hello to everybody,

I have been testing the current implementation of the MatLib-Editor within the pyleecan GUI and recognized some short comings. For instance, if a material is edited, the changes are not propagated thoughout the whole machine.
Therefore I would like to discuss the behavior that everybody would expect from the Material Library Editor.
Here are some thoughts and questions from my side.

• changes to material library should propagate to all machine parts if they use the respective material, i.e. material object references should not been broken
• Material Library should show the origin of the currently selected material (MatLib or Path)
• it should not been allowed to have duplicate material names
• if a loaded machine contains "new" material, the user should be asked to add this material to the library, to keep it as is or to replace it with a material from the library that has the same data, if it exists
• if there are materials with the same name (in the machine file and/or the library) the user should be asked to rename the material
• an alternative may also be to keep the machine files materials "outside" the library and only inside the material selection combobox with the possiblity to also edit that material (that may require some additional logic to handle all possible cases)

All of your contribution to this issue is greatly appreciated.

Best regrads,
Sebastian

At the moment the initial electrical rotor angle related to the stator winding system for arbitrary pol/slot-cominations is not known.

It would be useful to either have a function that calculates the initial rotor angle, i.e. for example the angle between the d-axis and the alpha-axis, or to modifiy the FEMM model creation in a way that the d-axis match the alpha-axis (in case angle_rotor_initial=0).

In pyfemm there is an error with the smartmesh command. It is defined several time instead of have several versions (mi_smartmesh, smartmesh, ...). David Meeker will correct that in the next release of pyfemm. Once it will be corrected, we will need to change smartmesh in draw_FEMM by mi_smartmesh.

Hello Pierre,

I got some problem with (missing) backward compatibility of pyleecan.
I have some saved "old" output objects, I can not load with the actual version.
This is because FEMM_dict attribute was removed from OutMag class (commit of 18 Nov 2019).

Do you see any chance to add backward compatibility by ignoring attributes that have been removed for instance?

Best regrads,
Sebastian

For now we have a method in the Slot abstract object that returns the surface of the slot. It would be also interesting to have the possibility to define the surface of a tooth. For that it requires:

• To add a get_surface_tooth method in the LamSlot object that (for instance) returns the following surface (but centered on the X axis):
  
• Add a build_geometry_tooth method in the Slot object that calls the build_geometry method, apply some rotation, split some curves if needed, add the bore arc. The method would return the lines (in trigo order) 6,5,4,3,2,1,2,3,4,5,6
• The get_surface_tooth calls the build_geometry_tooth method and adds 3 lines to define the yoke part (7,8,7) and create the corresponding SurfLine object. The lines 7 are polar.

This method would enable:

• To plot the tooth of the machine
• To get the surface corresponding to 1/ Zs of the machine
• This surface can be used to define a structural coupling (with gmsh for instance) by drawing a single tooth and then duplicate it by rotation.

We introduce the build_geometry_tooth method to be able to define some dedicated method for some complex slot if the general method doesn't work.

As a follow-up of issue #2, it would be great to convert all the csv files from semicolon separated file to comma separated. That way Github can display the csv in a better way: https://help.github.com/en/github/managing-files-in-a-repository/rendering-csv-and-tsv-data

Hello everyone,

As we said before we need to add a requirements.txt file for pyleecan so it is more convenient to install/use.
Two things are bothering me for the creation of this file:

• First there are some dependencies that are not mandatory. For instance, if you don't want to use gmsh, there is no need to install it. Either we say that you need to install everything (which is a radical constraint), either we will have to discuss about the "core" dependencies of pyleecan. Maybe we can create several requirement depending of the usage (core functions only, all dependencies, core + testing for developers...)
• Once we know which package, we need to know which version. Is there a way to detect the oldest version of a package that makes the project work or should we just put the current version number and update it if we find an actual version constraint ?

How do you think we should define our requirements.txt ?
Best regards,
Pierre

It would be interesting to be able to run separately the unittest (in the folder Tests/Classes, Tests/Functions, Tests/Methods and Tests/Plot) and the validation cases (in the folder Tests/Validation) since the validation cases are long to run.

The quick and dirty solution is to add a folder Tests/unittest and gather the related folder inside. To be more efficient we can maybe use pytest or something else but it need to be investigated.

Hello at all,

I want to start a disussion about a general FEA mesh & solution class here.
A first realization of this feature (more or less related to FEMM specifics) was done with pull request #47.
With the actual MeshMat class (which I think is meant to be a general class) it is only possible to store elements of one kind (i.e. triangles for example). I think this is very restrictive.
Is there a reason not to expand the elements attribute ndarray to the max. number of nodes of the used or supported element types or to use a list to store the elements nodes. In addition this would require an element type attribute or to store the element type as the first value of each row within the elements attribute.

In the current implementation the FEMM solution is stored in a MeshFEMM object which is inherited from MeshMat. What do you think, if we seperate the mesh and the solution to some point, i.e. having a solution attribute in MeshMat. This attribue can then be of type FEASolution (or more general MeshSolution) with inherited FEMMSolution with nodal and elemental solution values.

At last, why are you interfacing FEMM with a LUA script instead of the python interface? Is it faster or more convienent for that purpose?

I'm looking forward for a constructive disussion.
Best regards,
Sebastian

Hello,

the winding distribution calculated by the pyleecan winding generator of a 1/2 slots per poles per phases winding has a clockwise direction, while other windings are anti-clockwise (e.g. 1 and 2 slots per poles per phases).
This should be corrected for consistency.

Further if a tooth winding is reversed the tangential position of the coil sides will be wrong. Although that seems to have minor influence on simulation results, it should also be fixed.

Best regards,
Sebastian

By reusing the same principal as for the FEMM/GMSH coupling, we want to create a coupling with SALOME (https://salome-platform.org/).

The main step would be to:

• Reuse the build_geometry method to generate the surface to draw (most of the geometry work is already done)
• add draw_salome methods to the Geometry object
• create new functions (matching FEMM/GMSH ones) to generate the mesh
• For the mesh definition, we propose to assign a number of element for each line of each surface. It would be a comp_mesh_dict(element_size) method of machine that would call build_geometry and compute the length of each line to deduce the number of element on the line. It would return a dictionary[line label] = . That dictionary can be then updated (as the FEMM_dict one) to tune the mesh. We have started to work on this function.
• For 3D mesh we can then create a build_geometry_3D method for the machine and lamination to define (to begin) extrusion volume based on the build_geometry surfaces #

Hello to everyone,

since I don't know by now, what is your best practice to version control your internal code that is within your local pyleecan dir?

Best regards,
Sebastian

The class generator creates files that doesn't perfectly follow the PEP8 and it creates some meaningless changes in the commit if one doesn't run black (https://black.readthedocs.io/en/stable/).

I can see three solutions (in order of preference):

• Find a way to add a hook to call black on the complete project before each commit
• Add an automatic call to black after each use of the code generator
• Improve the class generator to perfectly match PEP8 standards

Hello to everyone,

What do you think about switching from unittest to pytest for our testing process ?

I remarked that some tests and especially validation ones can be really long and I think that it could be good to have the possibility to exclude some tests easily or to only include some of them. Pytest enables to do it easily by defining markers:

@pytest.mark.validation
def test_example():
    """Write the test here"""
    pass

Pytest also handle Pytest-cov to generate coverage test and help us improving our test process. It also handles tests parametrization so we wouldn't lose any testing ability.

Pytest can also execute unittest so the transition could be easy. We could write all new tests with pytest formalisme and progressively convert every tests and then remove ddt dependancy ?

Best regards,
Cédric

Do you have a coil geometry calculator defined for lap form coils yet? (I couldn't see one in the code, but I haven't absorbed the program structure yet.) If not, I may be able to assist with that. Concentric and other oddball windings maybe not so much.

Regards,
Allen

The function create_FEMM_magnet may be improved to clean "the if LamHole / if magnet_X" part. For instance by replacing the argument of the method from lamination to magnet ?

In the Code generator, we now call automatically the PyQt method to convert the ui files to python scripts. Problem, the generated files starts with:

# -*- coding: utf-8 -*-

# Form implementation generated from reading ui file 'C:\Users\XXXXX\Desktop\Git\PyManatee\pyleecan\GUI\Dialog\DMachineSetup\SBar\PCondType22\PCondType22.ui'
#
# Created by: PyQt5 UI code generator 5.9.2
#
# WARNING! All changes made in this file will be lost!

We should change it to

# -*- coding: utf-8 -*-

# WARNING! All changes made in this file will be lost!

To avoid unnecessary modification in commit.

It would be nice to have Pyleecan running on Linux but FEMM would have to run using Wine which needs to be tried out.

It would be interesting to add the possibility to skew the laminations. To achieve that it would require:

• To add an instance of a Skew abstract object in the Lamination class. The Skew class define Nslice the number of skew slices.
• Provide several daughters of Skew (for instance SkewLinear, SkewStep...) with the method comp_angle_skew that returns an array of length Nslice of the angular position of the lamination slices [rad].
• The comp_angle_skew would also have an optional argument (alpha_ref) to normalize its output according to an angle [rad]. The idea is to be able to provide the skew as a multiple of the stator slot pitch for instance
• The "angle_skew" of both laminations are computed in the comp_output_geo method of the Lamination object and stored in the corresponding OutGeoLam
• In MagFEMM solve_FEMM method there is another loop on the skew slice. The skew is set in the update_FEMM_simulation to set the correct rotor relative position (angle_skew_rotor[ii] - angle_skew_stator[ii])
• The resulting flux is stored in the OutMag object as Br_skew and Bt_skew with dimensions [Nt_tot, Na_tot, Nslices]. Br and Bt are then computed as the average of Br_skew and Bt_skew on the slices.
• OutMag will define a get_flux_skew_rotor(Nslice) and get_flux_skew_stator(Nslice) that returns the flux at on a Z linspace. If Br_skew and Bt_skew are not available, the method returns just an extended [Nt_tot, Na_tot, Nslices] matrix of Br or Bt.
• A validation case on each Skew daughter and one comparing Br and Bt of a no skew simulation with a simulation with a 0 linear skew would be interesting.

By reusing the same principal as for the FEMM coupling it should be simple to create a coupling with GMSH (http://gmsh.info/)

The main step would be to:

• Reuse the build_geometry method to generate the surface to draw (most of the geometry work is already done)
• add draw_gmsh methods to the Geometry object
• create new functions (matching FEMM ones) to generate the mesh
• For the mesh definition, we propose to assign a number of element for each line of each surface. It would be a comp_mesh_dict(element_size) method of machine that would call build_geometry and compute the length of each line to deduce the number of element on the line. It would return a dictionary[line label] = . That dictionary can be then updated (as the FEMM_dict one) to tune the mesh. We have started to work on this function.
• For 3D mesh we can then create a build_geometry_3D method for the machine and lamination to define (to begin) extrusion volume based on the build_geometry surfaces

Hello everyone,

this issue is for discussion of a consistant and relieable way to store material data (i.e. BH curves) within the saved machine files (json).
Actually, if there is a BH curve imported, it is referenced by the file name i.e.

"mag": {
                "BH_curve": {
                    "__class__": "ImportMatrixXls",
                    "file_path": "C:\\...\\MaterialBH.xlsx",

Now, if the referenced file is deleted or moved for some reason, the machine can't be used any more and has to be fixed.

To be able to use the machine file even though, I think it is benificial to also store the import data within the machine file.
Then the program can compare the referenced and stored data, throw some warning and proceed with one of the datasets.

What do you think about that?

Best regards,
Sebastian

The Arc1 object is not precise enough. For now this object is defined with begin, end, radius. The radius can be >0 or <0 to select on which side of the [begin, end] segment the centre is. It would be interesting to add a new parameter "is_trigo_direction" to select the orientation of the arc.

Indeed with the same begin, end and abs(radius) 4 arcs can be defined:

The new method to define the centre should be that in the coordinate system centred on the mid and with begin, mid, end aligned on the X axis in this order:

• if R >0: Zr = mid + 1j*sqrt(R²-(X/2)²)
• if R >0: Zr = mid - 1j*sqrt(R²-(X/2)²)

With X the distance between begin and end.

Hello to everyone,

this issue will be to discuss the possiblites to automate the GUI creation as mentioned here.

Since there are a lot of hand coded files, what do you think about an object attribute editor instead? I don't actually know if that will work as expected, but it would track user class modifications easily without the need to adapt the GUI.

Why not. I'm just not sure how it would work with the current GUI. The structure of the GUI enables to easily add new slots, magnets, conductor... which is mostly the new objects that contributor should add. But as we have the csv doc, I think that we should be able to generate automatically such GUI. So it is worth investigating.

What keeps me promising is the following blog post. http://trevorius.com/scrapbook/python/attribute-editor-in-pyqt/

@BonneelP: Could you tell me why machine.__dict__ return underscored attributes as keys, _rotor for instance, although I can access the rotor with machine.rotor (without underscore)?

Best regards,
Sebastian

Hello all,

I'm currently working on a publication for ICEM 2020 (and on how to upload Jupyter notebook to pyleecan.org for the documentation). In this publication, I will present the geometrical modeller of pyleecan (build_geometry) and how it can be used to create complex and exotic topologies.

In particular I'm investigating a new class "LamSlotMulti" a "LamSlot" with a list of Slot (and an array of angular positions) to draw uneven slot machine like (image generated with my current version of pyleecan as a proof of concept):

Then I wanted to add notches and it became quite complicated to mix both.

That's why I want to introduce a new method for Lamination objects:

def get_bore_desc(self):
"""This method returns an ordered description of the elements 
that defines the bore radius of the lamination

Parameters
----------
self : LamSlot
    A LamSlot object

Returns
-------
bore_desc : list 
    list of dictionary with key: "begin_angle", "end_angle", "obj"

For a "normal" Lamination with Zs=12 SlotW10, it would returns (T_op = tooth opening angle, S_op=slot opening angle) :
bore_desc [0] = {"begin_angle" = -T_op/2; "end_angle" = +T_op/2; "obj": Arc1}
bore_desc [1] = {"begin_angle" = T_op/2; "end_angle" = T_op/2+S_op; "obj": SlotW10}
bore_desc [2] = {"begin_angle" = T_op/2+S_op; "end_angle" = 3/2*T_op+S_op; "obj": Arc1}
...

• This bore description would then take into account the notches and the uneven bore shape.
• The "obj" are either pointer to the corresponding Slot either the Arc to use.
• The bore_desc can either describe the complete lamination or a symmetry part. In case of symmetry, the first angle is 0.
• We keep the convention: The first tooth is centered on X+ axis (with or without symmetry)

The build_geometry of the "Lamination" object can then call this function to draw the bore (what ever the lamination type or the sym). The polymorphism would be on the get_bore_desc method.

I would like to take the opportunity to update the Notch definition.
In Lamination we currently have a list of Notch and then the Notch class itself contains a list of Slot object. I would like to keep the list of Notch in the Lamination and remove the list of Slot in Notch.

The Notch class would be abstract and empty. NotchEvenDist would have a single Slot object as property and alpha as a float (with alpha=0, first notch centered on X+axis). The number of notches would be set with Zs in the Slot.
Then we can either create a "NotchSingle" with a Slot and alpha as a property that draws only one notch centered on alpha. Either we use a NotchEvenDist with Zs=1 (which can have an impact on the geometry of some slot).

What do you think of these modifications ?
Best regards,
Pierre

Thanks for all the work that has gone into this project so far. I have no intention to use FEMM yet when playing with the current code, I cannot 'assemble' a machine/geometry without having to import FEMM (some of the geometry methods try to call/import it). Is this intentional (or am I being silly)? Wouldn't it be possible to decouple this project and let the user choose what other modules to interact with?

Hello,
I have two doubts regarding plotting of the simulation results:

1 I have been trying to plot the results of the "tuto_Simu_FEMM_results.json" available online. But every time I use the command out.plot_A_time("mag.Br"), an error at the end 'List of index out of range' shows up. How do I resolve this? Attached is the error message in pdf(a) and the jupyter file(b).
a) error.pdf
b) Online FEMM results plotting.zip

2 How do I create the .json results file for my own simulations. I have set the savefile option - mySimu.mag.is_save_FEA = True. But when I import this file as out = load('MeshSolutionFEMM.json') for plotting, and apply the the command 'out.plot_A_space/time', it gives the error: 'MeshSolution' object has no attribute 'plot_A_space'
Attached is the jupyter file(a) and the mesh solution json file(b)
a) Plotting own results.zip
b) MeshSolutionFEMM.zip

Hello Pierre,

in the hole's build_geometry method, hole's labels are "Air", while there is no FEMM air group nor an explicit "Air" material in create_FEMM_materials or an "Air" mesh setting in get_mesh_param.
I would like to add the missing parts, but before I need to know if holes should get their own group, etc. or if they should belong to "Ventilation".

Best Regards,
Sebastian

Due to the possibility to set arbitrary magnets of HoleMx-Class to None, the magnets label is not always the same, i.e. "T0" may be magnet_0, magnet_1 or magnet_2 with HoleM51 for example.
This causes the code of related methods and functions to have a lot of conditionals.
To simplify the code it would be more convienent to have all magnets first (with labels "T0" = magnet_0, "T1" = magnet_1, ... all the time) and set the "None" property later, for example with an additional magnetization "None".

Hello Pierre,

do you plan to include your MANATEE's rotor notches functionality into pyleecan in the near future?

Otherwise I would try to include some similiar functionality, i.e. a notch or (rotor) bore surface shaper class. That class can be a property of all concentric bore laminations (e.g. LamHole-type) similar to LamHole.holes list.
The class will then be used (if not None) to shape the bore surface in a substractive manner to get rectangular notches or other shapes. Since it will be substractive one could also combine multiple shapes.

I think that will be a good addition to pyleecan. What do you think?

Best regards,
Sebastian

There are two things to improve in assign_FEMM_surface regarding the HoleMagnet:

• For now the magnet are always set according to hole[0] but in the case of several holes it would require to read the label to select hole[ii]. The convention could be that in build_geometry of LamHole we update the hole label to have RX with X the position of the hole in the hole list of the lamination.
• We need to add a method comp_angle_magnetization to compute the angle of the magnet for parallel magnetization. It would take as argument a bool is_north and return a tuple corresponding to the magnetization of each magnet (None if the magnet is not there).

Hello to everyone,

it would be nice to have a live preview of the geometry inputs within the GUI.

As a first step, this would require to have meaningful default parameter for everything.
The question is, how to do that.
Of course the class definions should be updated therefore, but that may not be sufficient. If for instance the default lamination diameters are changed in a way, that the default slot pitch is exceeded by the slot width, the slot preview will be invalid.
So either there has to be an error/warning (since the user can also input invalid slot parameter by accident) or the default parameter have to be corrected within the GUI corresponding to the previous user inputs, which seems to be a difficult task.

The next step then, would be to use matplotlib to plot the geometry instead of the images.

Best regards,
Sebastian

Hello,

the method build_geometry for the different types of geometry (i.e. Lamination, Slot, ...) is inconsistent, since the input parameter are not the same. Slots build_geometry method has no input parameter for example.
At least all build_geometry methods should have the alpha and delta parameter in common.

Best regard,
Sebastian

To simplify the function comp_FEMM_dict it would be great to have a get_height_magnet method for the HoleMagnet daughter classes (HoleM50, HoleM51...).

Some model (like Subdomain) require to have a polar approximation of the machine. It would be great to have a get_polar_eq method in the Machine class. This method will return an equivalent machine object but with the polar versions of the laminations (by calling a get_polar_eq method). It would require a get_polar_eq for each kind of lamination.

For LamSlotWind, the method is simple: the method of the slot are defined to compute the polar height, angles... The get_polar_eq method would call the corresponding comp methods and change the slot type to SlotType22 (https://eomys.com/produits/manatee/howtos/article/how-to-set-up-slot-type-22).

Then there are the other type of lamination (we can create the method and use "NotImplementedYetError" from pyleecan.Methods by waiting) that need to be defined.

Hello everyone,

I have encountered a limitation to the actual class generator. The method "save" output is not JSON serializable if some ndarray are stored into a dict.

When an attribute is directly a ndarray, the method "save" turns it into an list (which is JSON serializable). But if this ndarray is stored into a dict, the method "save" does not perform this conversion.

Best regards,

Raphaël

Hello,

if I load a machine once (e.g. IPMSM_A.json), go to '8 RotorLam' and try to load a machine again I get the follow error message.

Best regrads,
Sebastian

The first module of a full PYLEECAN simulation is the electrical one. The architecture proposal document details some idea on this module (p37)

To summarize, the module would be organized around 3 objects with several versions:

• Electrical: To select the workflow and the Operating Point
• Drive: Generate the power signal of the machine
• EEC: Compute the parameters of the Equivalent Electrical Circuit (EEC)

To begin with this module, the idea is to choose a particular simple case to create the first version of each object and set all their interactions. Then other versions of these objects will be easier to develop to add new hypothesis or workflow.
We suggest to begin with the following case:
A SIPMSM at a single speed, powered by a sinusoidal tension drive with the following EEC:

P180 from “Advanced Electrical Drives, analysis, modeling, control” Rik de doncker, Duco W.J. Pulle, André Veltman, Springer edition

The advantage of this EEC is that we will be able to use it for surface, inset and interior permanent magnet synchronous machine.

To develop this module several independent steps are required:

• Create a DriveImport object that would contains an Import object and have a gen_signal() method. For the previous case, we can use a ImportGenMatrixSin to define the signal.
• Add a comp_resistance_wind to the LamWind object
• Create an IndMagANL object (included in the EEC object) to compute the magnetization inductance along d and q axis analytically (for instance)
• Create a FluxLinkANL object (included in the EEC object) to compute the flux linkage analytically (for instance)
• Provide some validation cases to check that the computation of each EEC parameter is correct

Note that inductance and flux linkage has their own object so that it will be possible to easily add new model to compute them. The winding resistance is more straight forward and can be a “machine” method.

Once all this available, it would be interesting to compute the current (as a function of time) without assuming that the tension is a sinusoidal to be able to change the Drive for other cases.

Radial magnetization of HoleMx-magnets is actually not implemented correctly.
I think there should be an error stating "not implemented" until someone need this feature and implement it.

To simplify the machine definition it would be great to have a GUI. Here are the main idea for the GUI:

• We plan to use PyQt5 since the Qt designer simplify a lot the definition of a GUI
• The definition will be done step by step with some check, intermediate output computation and maybe some default meaningful values
• The tooltip of the fields will be automatically added according to the csv class documentation
• For the slot (and any other part that can have several version of the same class) we need to find a way to automatically detect how many slot widget are available to simplify the process to add a new slot to the GUI for instance.
• The machine GUI need to enable to select the materials from a library
• The GUI will load and save the machine json file (with the save/load function of the machine object), the simulation will then be done in a separated python script (by waiting the simulation GUI)

As a follow up of issue #43, it would be interesting to be able to update the classes code for internal use. The point of pyleecan is to enable people to experiment new models and new topologies and we have chosen the Apache license to enable anyone to use it even for confidential purpose. So pyleecan should have a dedicated way to separate "open source code" and "internal code".

My suggestion would be to use the code generator. The code generator is split in two parts:

• read all the csv files to generate the "class_dict"
• generate the code of all the classes present in the class_dict
  The idea would be to add a new step before generating the code: updating the class_dict with internal modifications.

I saw several useful modifications:

• Add a new method to an existing class
• Add a new property to an existing class
• Add new classes
• Replace an existing method by a confidential one
• Update the definition of a property of an existing class

All the modifications to apply would be gathered in csv files (like the existing one of the code generator). Theses csv files would be in a dedicated folder "Generator/Internal" (name to be discussed). If the folder doesn't exist, the step is skipped. We can imagine to store the internal methods of a class in the corresponding method folder/Internal.

There are two ways to defined these csv files and we need to chose one:

• The csv file define completely the internal class, we replace the data in the class_dict. Problem: any internal csv needs to follow the modifications of the corresponding csv.
• The csv file defines only the modifications: we update the data in the class_dict. Problem: The definition of the class is split between two files.

An option would also be added to skip the "internal" step to enable to chose between generating the open source pyleecan or the internal one.

Then by adding the "Internal" folder(s) to the git ignore list it would reduce the risk to commit internal code. The only possible error would be to commit a wrong class file which would not be an issue since there is no valuable code in it. This error can be avoided by following the guideline: "before any commit we need to run the code generator, black and the unittest".

What do you think of this new evolution ?
Best regards,
Pierre

Hello to everyone,

there should be a winding pattern editior within the GUI.
As stated by @BonneelP here, there are some ideas to do that.
Anyway help is greatly appreciated.
Maybe it is also possible to include some existing tools, for instance koil.

Best regards,
Sebastian

Hello all,

To make sure that the result of the models are meaningful (and always will be), we need to add some validation cases. A validation case in pyleecan is test that defines a simulation that runs one or several models on a real machine to compare the results against experimental measurements, other software results or other pyleecan models. All these tests are gathered in "Tests/Validation".

We are always looking for new validation data, new publications, new simulation change or comparison study. If you are interested in helping us, please open an issue to discuss about what is the best way of including your data, publication...

Best regards,
Pierre

Hello Pierre,

what do you think about a change of the "root_dir" of pyleecan to ..\XYZ\pyleecan instead of ..\XYZ ?
Therefore all imports have to be corrected, but on the otherhand its enable the user to rename the pyleecan folder without breaking the program.

Best regards, Sebastian

Hello everyone,
I have been trying to simulate an IPMSM motor defined by me using the steps mentioned in the tutorial. At the last step though, an assertion error shows up:

~\Documents\GitHub\pyleecan\pyleecan\Methods\Machine\LamHole\build_geometry.py in build_geometry(self, sym, alpha, delta, is_simplified)
123 for hole in self.hole:
124 Zh = hole.Zh
--> 125 assert (Zh % sym) == 0 # For now only
126 angle = 2 * pi / Zh
127 # Create the first hole surface(s)

AssertionError:

Can someone explain where exactly I have gone wrong in defining the machine?
From the error it seems like something is wrong in the rotor part. But I am not sure what I have defined wrongly in the rotor part.

It would be great to be able to generically split the surface objects. It would have several applications:

• For now for the symmetry we split the lamination by assuming there is nothing on the "splitting line". In some cases there may be a ventilation, a notch or even a slot. Instead of changing the build_geometry it could be interesting to create the complete lamination surface and then "cut it twice" to get what is needed.
• For the build_geometry_wind we defined each surface manually. It could be interesting to just generate the complete winding surface then split it according to Nrad and Ntan. A second constraint would be to split it to have the same area for each surface.

The method split could take as argument either two complex or a Segment object. In both case we assume that it define a complete straight line. The method would return two surfaces: the surface above the line and the surface below the line (can be None). The "above" would be defined by assuming the new coordinate system center is on the begin point of the Line and has the end point on the X+ axis.

Hello !

If there is a csv file defining a class "MyClass", and if by mistake someone put the same "MyClass" in "Inherit", then there is an infinite loop in the update_all_daughters.

Maybe we could add a check to prevent it somewhere in the function ?

Raphaël

Hello team,

Do you plan to share the .xls spreadsheet that is used as an input for the automated code generator?

PS: Great project, thanks! Looking forward to getting involved.

Hello,

I'm very impressed by all the progress that's been made, well done!

I'm on macOS. With the latest changes, when I try to start the GUI using python -m pyleecan, having installed pyleecan in a python3 virtual environment using python setup.py install I get a ModuleNotFoundError:

File "/Users/till/Documents/pyleecan/pyleecan/pyleecan/run_GUI.py", line 6, in <module> from PyQt5.QtCore import QTranslator ModuleNotFoundError: No module named 'PyQt5.sip’

$pip list shows PyQt5 5.14.1 PyQt5-sip 12.7.1 as being installed. Uninstalling those two packages with pip uninstall and re-installing the required versions seems to have done the trick (I can load the GUI). Do you have any idea what could be causing this?

On another note: The current setup tries to install pyFemm, which requires pywin32, which - for obvious reasons - doesn't exist for a mac install...

Best regards,

Till

Hello,

I would like to include a first implemention on iron loss calculation based on the new FEA results feature.
Therefore some things have to be discussed to find an apropriate and flexible solution.
At first there has to be an IronLossModel class to regard the different calculation approaches (Steinmetz, ...). Actually I'm not quite sure on how to apply the model on the magnetics output. Maybe the magnetics simulation should have an additional attribute iron_loss_model of the respective class. The only thing importent to me is, that the model can be updated even after the magnetics simulation is done to avoid unnecessary FEA (FEMM) calculations. Even a list of calculation models would be good to compare results.
A nice to have feature would be that IronLossModel is as much flexable, that it also could be applied to analytical magnetic models.

Next thing are the material/model loss parameter. At first I thought of some kind of user specified material attribute or an extra loss parameter data file, but I don't really like that idea. It would be a mess with different loss models and/or parameter sets.
A solution I actually like is to have the (watts per kg) loss data as function of B and f within the material data. Every loss model will then have a method to fit its loss parameters to the material data. The fitting functions could also be objects for instance with different fitting algorithms or weights. Nevertheless the loss models should also have the possiblity to overwrite these parameters.

Furthermore, we have to think on how to apply the loss calculation to the different parts of the machine, i.e. laminated vs. solid materials.

Yet there are some further (minor) points:

• where and how to store the results and estimated/used model parameters
• how to verfiy valid periodicity of the input data
• inclusion of correction factors and cutting edge effects

So, finally what is your opinion on this issue?

Best regards,
Sebastian