pyleecan
pyleecan copied to clipboard
[CO] Architecture proposal: refactoring Is/Ir to I_dict[<lamination_label>]
Hello all,
This issue is related to #206. For now the electrical module store Is and Ir in the OutElec object. The problem is that when there are more than two laminations we need to add a proper way of storing the corresponding current. For the magnetic model, we have the same issue for Phi_wind (for all the winding of the machine).
We can use get_lam_list to have an adaptive way of storing our values by using the index in the list. Then we would have Phi_wind_list[index] = values with index the index of the lamination in the lam_list. The issue with this method is that if the rotor don't have winding we would have Phi_wind_list = [None, values]. And to access the stator phi_wind we would always need to call get_lam_list to know what was the index of the stator (the stator is not always outer).
My proposal would be to introduce get_lam_dict (in addition to get_lam_list). Then we would need to have a default label for all laminations. My proposal would be: "Stator_X" with X from 0 to number of stator -1. The label are given for inner to outer so:

Then in the output OutElec.I["Stator_0"] = Data. We don't have to set all the keys, for instance for a machine without winding in the rotor there won't be any "Rotor_0" key. We can add a get_label to the Lamination object that would check its parent to return "Stator_X"
What do you think of this proposal ? Best regards, Pierre
Hello Pierre,
that's a good idea even with 2 laminations, that e.g. could both carry a current.
Wouldn't it be possible to have a special dict for that purpose, i.e. a dict that can automatically translate an integer key to the corresponding lamination label and also translate "Stator" into "Stator_0", since most of the time there will be only 2 laminations. I know that will require some affort but would be very handy in my opinion.
BR, Sebastian
Hello Sebastian,
Indeed, this convention is also meant for machine with 2 laminations. I propose that even for these machine we use "Stator_0" and "Rotor_0" for the labels. That way the models will be ready to be extended for further work with more laminations and the syntax will be unique in the software. So we would need to change again the labels in build_geometry: "Lamination_Stator_0_Bore_Ext" for instance. Or maybe "Stator-0" so we can extract the full label with the split("_") method ?
By the way we can even use it to have several currents on a same lamination (as long as the model knows which label to look for). For instance OutElec.I["Rotor_0_SC_0"] and "Rotor_0_SC_1" for double squirrel cage machine. Not sure if should do that but it would be possible.
We can add to the machine the method "get_lam_list_label" that would return (according to the above machine) label_list=["Stator_0", "Rotor_0", "Rotor_1", "Stator_1"] then index = label_list.index("Stator_X") to get the proper id. get_lam_by_label would be handy as well.
Best regards, Pierre
The laminations labels are now unique and consistent. The next step would be to refactor Is/Ir (and the other output) to a "I_dict" where the key is the lamination key and the value the corresponding current. It will require to rethink the Operating Point and the InputCurrent which is something we will start in the asynchronous machine related work (corresponding issue in writing)