[NF] Defining the EEC for the electrical module for squirrel cage induction motor
Closed this issue · 60 comments
I have been trying to get pyleecan to simulate a regular squirrel cage induction motor (SCIM) but i cant get it to work. I will attach my code to this post as well as the motor i defined using the GUI and a material .json file for Aluminium i made. This is just a fairly standard SCIM which i am trying to analyze for a project i am working on.
My code is basically a copy of the code found under tutorials on the main website. I know there is a key difference between both motors because there my motor doesn't have any permanent magnets in the rotor. But i reckoned i should at least get some form of output. Since there still is an input for the rotor current (albeit a total guess).
However i do not understand the error i got:
File "......\pyleecan-master\scripttest.py", line 51, in <module>
out = simu.run()
File "......\pyleecan-master\pyleecan\Methods\Simulation\Simulation\run.py", line 43, in run
self.run_single()
File "......\pyleecan-master\pyleecan\Methods\Simulation\Simu1\run_single.py", line 19, in run_single
output.geo = self.machine.comp_output_geo()
File "......\pyleecan-master\pyleecan\Methods\Machine\Machine\comp_output_geo.py", line 28, in comp_output_geo
output.rotor = self.rotor.comp_output_geo()
File "......\pyleecan-master\pyleecan\Methods\Machine\LamSlotWind\comp_output_geo.py", line 21, in comp_output_geo
output = Lamination.comp_output_geo(self)
File "......\pyleecan-master\pyleecan\Methods\Machine\Lamination\comp_output_geo.py", line 22, in comp_output_geo
output.name_phase = self.get_name_phase()
File "......\pyleecan-master\pyleecan\Methods\Machine\LamSlotWind\get_name_phase.py", line 22, in get_name_phase
return gen_name(self.winding.qs)
File "......\pyleecan-master\pyleecan\Functions\Winding\gen_phase_list.py", line 75, in gen_name
for i in range(N):
TypeError: 'NoneType' object cannot be interpreted as an integer
What i get from this is that the name of the phase can not be determined because there is no element to name? I have to admit my python skills have deteriorated over the last few years and weren't all that good to begin with. So the answer might be really simple, but i just can't seem to figure it out.
Does anyone understand the problem?
Hello,
Thank you for your interest in pyleecan. The issue seems to be that machine.rotor.winding.qs is None. For SCIM, we use the convention to set the number of rotor phase to the number of rotor slot (you can take inspiration from the machine SCIM_001).
The issue title indicates that you are trying to run the Electrical module. For now we only have a single equivalent circuit and it is for synchronous machine so you won't be able to run this module. SCIM are only available for now in the Magnetic module. If you need a Electrical module for SCIM you can open an issue by taking inspiration from issue #31 and providing the model and equivalent circuit you would like to use.
Best regards,
Pierre
Hello,
I guess there are some other issues with the machine model as well, we should address this first. (Even with rotor.winding.qs != None there are still errors).
OT: What would be a sensefull number of rotor phases?
If we'd solved this issues, it should not be too hard to have an EEC for that type of machine. Interestingly the existing PMSM EEC could be seen as a special case of a SCIM EEC.
If you're willing to spend some affort to it let me know. I think we could get this running within a short time.
Best regards, Sebastian
Theoretically the rotor should have as many phases as it has rotor bars. I have never actually checked this myself, but in my time researching the topic i came across multiple sources stating this.
It also makes sense because of slip, this indicates every rotor bar getting a slightly different influence from each pole, resulting in a different phase.
I would definitely be willing to spend some time on it, but i'm not to experienced so it would take me some time to get to know the ins and outs of FEMM and your codePyleecan.
The EEC for SCIM's are quite easy to find. This would for example be a fairly exact option:
The R_1m term is however often excluded from calculations because it has a minor effect on the system. This would perhaps be useful to us to do because this term contains information on mechanical losses in the machine, which are next to impossible to accurately predict. Although i did find some equation often used in a handbook from the eighties:
Yes you are right, the number of phases must be the number of bar. I haven't thought that far :-)
Otherwise it wouldn't be possible to set individual bar currents.
My suggestion to you would be to check your machine first. (I saw some None values.)
Therefore it may be helpful to you to import pprint and e.g. check your rotor.
from pprint import pprint
pprint(IPMSM_A.rotor.as_dict())
As said, you e.g. have to set the number of phases 'qs' or the number of turns per coil 'Ntcoil'.
IPMSM.rotor.winding.qs = IPMSM.rotor.slot.Zs
Afterwards you could send the updated machine and we will see what's next. BTW, not all values have to be set, only the main parameters first.
Regarding R_1m of the fairly 'standard' EEC (as shown above) it also include the iron losses. Although the obvious effect is minor we may include it to be as general as possible and to e.g. estimate the losses and the efficiency. But we will see.
Hello,
Regarding your EEC for SCIM machine the steps should the same as for the PMSM one (cf issue #31).
The first step is to be able to compute each parameter of the EEC. For that there are two possibilities:
- Either the value has a direct formula and it should be a "machine" method like LamSlotWind.comp_resistance_wind
- Either the computation require a simulation like the magnetization inductance or flux linkage in the PMSM EEC and then we should create a dedicated object (IndMagFEMM and FluxLinkFEMM) to compute it (which enable to change the model).
Can you detail all the parameters that are needed for your EEC and how you think we can compute them. We will guide and help you on how to achieve the actual computation in pyleecan (we should be able to reuse some part from the PMSM EEC). As a side note, we can design this EEC to have optional parameter (so the user can choose to neglect them).
Best regards,
Pierre
First of all calculating R_s, the stator resistance shouldn't be any different from the PMSM case, so we should be able to use the same method for that.
The rotor resistance should also be fairly easy, i'll look into that today. Since it consists of the same basic formulas used for the stator resistance. We just need to calculate the cross section area of the rotor bars and the cross section of the end rings.
There is one question i have about the current EEC. In this EEC there is a correction factor on the rotor resistance and inductance due to the frequency difference between rotor and stator currents. I do have these factors, but i looked into how they were derived and i think it would be better to use another type of EEC for the motor:
This will enable us to use the regular resistance and inductance of the rotor, without any semi-emperical factors. We should be able to simulate the value for E1. I however do not know (yet) if the losses represented by R_1m will be inherent in this computation, would you guys have an idea?
What also has to be stated is the term V_r =0 for an SCIM, since there is no applied voltage on the rotor.
Now the two factors I don't yet know how to calculate are the inductances, which would need to be simulated in a similar manner to the synchronous machine.
I'll get starting with the rotor resistance, but i will need assistance in getting the values for the inductances.
Hello,
Regarding the rotor resistance, you will need to add a method "comp_resistance_wind" to the class "LamSquirrelCage" (by updating the csv pyleecan\Generator\ClassesRef\Machine\LamSquirrelCage.csv" as explained in https://pyleecan.org/tuto.add.slot.html).
For the cross section of the ring, "LamSquirrelCage" contains:
We have a "comp_length_ring" method, we should add a "comp_surface_ring" method.
For the cross section of the bar, it is defined with "CondType21" or "CondType22" objects which have "comp_surface_active" methods.
Do you have a publication or a reference that would provide a machine with the corresponding EEC parameters ? That would be great to validate this new EEC.
I will take a look at your other questions later.
Best regards,
Pierre
Hello,
I think your EEC is okay so far (regardless of the variable voltage element). If you e.g. have a look at the wikipedia induction machine page, you will find nearly the same EEC.
Since an induction machine is some kind of rotating transformer you will always have a 'correction factor' on the actual rotor quantities, similar to the transformer transformation ratio :-)
For the implementation of EEC, I think i can do it within the next weak. At least a first simple (working) implementation.
@BonneelP One thing I realized only now is that there is no 'slip' or possibility to set different rotor speed vs. stator frequencies?!
For now I may find a workaround.
With that EEC you will be able to do a simulation by setting the resistance and inductance values manually.
A second step then would be to automate the calculation of these parameters by an analytical model or a FEA simulation of the actual machine.
Regarding the R_1m, I'm not sure I understood your question. In the end, it's up to you if you would like to include the iron losses in your EEC simulation by setting an equivalent R_1m value or set it to infinity to neglect iron losses.
I hope this helps for now.
Best regards, Sebastian
Edit: I think, I will also find some example parameters to validate the EEC.
Of course implementing the R_1m term would be best if possible, since it gives a more accurate description of your motor.
I do know i have some files with accurate parameters and performance curves of a particular motor on work. Only due to corona i am forced to work from home and i can't reach those files before next friday. Besides that the described motor might have a dual cage rotor, for which there is not yet a geometry included. (Perhaps that would be a good idea for a feature i can work on sometime.)
#Edit: I don't know how i missed you mentioning where to find the dimensions. I deleted my question to prevent excess information in the thread
Hello all,
@SebGue Regarding the slip I think we can refer to the main principal of the Electrical module (from issue #31):
- Each Simu1 object correspond to a single OP and VarLoad object enables to define "variable speed" simulation (or multi-simulation) on several OP
- The purpose of the Electrical module is to compute the OP that matches the Equivalent Electrical Circuit (with resistance, inductors, voltage sources etc) solving constraints
- Then the object to enforce the OP already exist: InputCurrent
- The OP is defined in OutElec with: a fixed speed N0, Id and Iq (even for asynchronous machines) and a reference theoretical torque (the calculated torque is still defined in OutMag). We provided a method to set Id, Iq in InCurrent according to I0, Phi0
Then slip should be defined in a dedicated InCurrent (or InVoltage) and a special VarLoad with an OP_matrix with a "slip" column can also be created. slip would be stored in OutElec as reference for all further computation.
@MVreemann we don't have dual cage rotor yet but that would be an interesting architecture challenge :) It shouldn't be that hard to implement by reusing existing code, we just need to think about how to do it properly. If you are interested you can open a separate issue to discuss about this topology.
Best regards,
Pierre
Hello,
I just 'finished' the EEC_SCIM class, still with a lot of TODO's.
To be able to run a simulation I had to add the frequency to the InputCurrent/InputElec class. This shouldn't break anything since 'felec' is optional.
For now, the eec parameters have to been input manually. A test script is attached.
The next steps would be to get the actual machine parameters. There are different ways to do so.
One way would be to calculate the parameters analytically (maybe with some FEA assistance).
An other way would be to do 'pure' FEA parameter estimation. (I'm not into that but I think one could adapt some real world IM parameter estimation, i.e. no-load and locked rotor tests.)
Waiting for your comments :-)
Best regards, Sebastian
Hey guys,
Nice work, i'll try and find some data sheets of motors with motor parameters. We should have some available from WEG machines.
I finally had time to work on the resistance scripts. But when i was looking into the area scripts in Object21 and Objects 22 i didn't think they are actually suited for the type of motor we're interested in, since they basically compute the area of a rectangle. Where as most SCIM's rods have a somewhat triangular shape. Am I missing something? Or should I write the code for computing the area also.
All the best, Menno
Hello Menno,
I think you could use Cond22 as the rotor bar conductor. It has no specific shape, only a user defined area.
You could set this area in your script by the slot area, i.e. rotor.winding.conductor.Sbar =rotor.slot.comp_surface_wind()
Regarding the transformation of the actual rotor bar and ring resistance into stator side quantities I found following information in an electrical machine design book.
The substitute resistance of an equivalent 3 phase winding is calculated as follows:
R = Zs/3 * (Rbar + 1/(2sin(alpha_Zs/2)**2) * Rring)
alpha_Zs = 2pi*n_pole_pairs/rZs
The transformation ratio of the rotor quantities into stator side quantities is calculated to
i = (Ntspc * winding_factor ) / (Zs/6)
Zs ... number of stator slots
Ntspc ... number of turns in series per phase (of stator)
With this transformation the current in the eqivalent 3 phase winding has the same effective value as the current in the actual bars.
Maybe you can compare this with you books equations and implement one of both into the comp_parameter methods.
Best regards, Sebastian
Hey Sebastian,
The equation for the resistance you said is somewhat in agreement with the equation i found. In the sense that, only the factor Zs/3 is missing from mine, but that term also doesn't make sense to me, because it seems to say that there are only 3 phases in the rotor, which we already discussed not to be correct.
Btw, i checked your transformation ratio and it does differ somewhat from a ratio i used in te passed:
i = 4* m *(Ntspc * winding_factor)^2/Zs
where m is the number of phases. The weird thing is that these give a totally different value. I will look into it.
Btw, the following link contains the book i mostly use for my research (allthough i have the first edition, so there may be some differences). It also contains a chapter on FEMM estimation for induction motors and they have an analytical model (chapter 15) for determining the parameters. I did try this model but i couldn't get the same results as we measured for motors, so i believe it to be somewhat inaccurate.
Thanks for the code for surface of the rotor bars, I was looking for how to do that.
There is maybe some misunderstanding :-)
The 'R' equation calculates the resistance of a 3 phase winding that is equivalent to the actual rotor winding with Zs bars.
In fact also the transformation ratio seems to be similar. The factor 6 equals 2*m with m=3 (to account for the 3 phase equivalent).
Maybe you missed to square Zs and m? I.e. 'my' transformation ratio is applied e.g. Xr' = i**2 * Xr
My book also got a downloadable example 'Berechnungsbeispiele' but it's only in german language.
BTW: You forgot to actually link your book :-)
Luckily, living close to the dutch/german border, i do speak a bit of German, so i might be able to understand your book. i'll definitely check it out.
I double checked, but m and Zs are definitely not squared in my book. The link to which i indeed forgot, here it is:
But for now lets just use your transformation factor, since i did have some problems with my book, so they may (partly) originate from this difference
Hey Guys,
I am trying but i am having some troubles with understanding the object orientation in Python. In university i did follow some courses in Object Orientation in Java, but it seems pretty different. I attached my code for comp_resistance_wind() (and surface of the ring), but i need the length of the rotor lamination for the resistance of the rods, but i don't really know where to find this parameter, nor how to call it. Could you guys check it for me?
Thanks
Menno
LamSquirrelCage.zip
In short, you should remove 'rotor' input and replace rotor by self (lines 32 + 33) in comp_wind_resistance().
You also use the structural rho instead the electrical (line 25)
BTW: do you know how to add this methods to the respective class?
do you mean in the csv file? Yes, i did that.
what exactly is the difference between the structural rho and the electrical? because we are talking about the electrical resistance right?
Yes electrical rho. After your changes you also have to run the class generator, but I guess you also know :-)
Hey Guys,
Sorry for the long delay, it was a busy week. I finally have time to work on the project again today.
I finished the functions just now, should i commit them to the main branch?
I guess the most important next step is calculating the inductances somehow and i'll keep searching for some good validation data for the EEC
All the best,
Menno
Hello Menno,
maybe you could first push your local changes to your origin. To be clean you should have a feature branch for that.
I am really interested in your functions. (At the moment I also have to calculate a parasitic induction cage :-) )
I already got some idea how to calculate the inductance with some FEA. So if you don't have an analytic solution you would like to implement, it would be great if you could check your machines input data. That's to see if it is already build a FEMM model or if there is still some code missing.
Best regards, Sebastian
Alright, i'm struggeling a bit with GitHub Desktop right now. I may or may not have just deleted all the files i've written... But i guess i can still rewrite them.
What do you exactly mean by input data? Do you mean data like: voltage, nominal current power etc. or the data in the .json file of the motor i specified? Because i just took some random motor design of the shelve to test, i don't know if i have any more data on that specific motor.
Hello Menno,
I haven't used Github Desktop yet. I use VS Code and Git Bash uptill now and I'm very happy with it. Maybe you should give GitBash a try.
By input data I meant the machine data. But if the machine you got is only for test, we could also use the scim from the machine examples for now.
I will have look at your code the next days and come back to you.
BTW: Could you tell what's your profession. Maybe you could also help me with some other issues :-)
Best regards, Sebastian
Yeah i switched to tortoiseGit, for which I could use your tutorial.
Yeah we could definitely use the example SCIM for now. I did actually copy the geometry from an actual machine which you can buy. But i can't find proper data for the induction parameters... And i'm not sure whether we can measure those at our company. Besides that the corona restrictions make performing measurements in our company somewhat difficult.
For your question about my profession: I am two things, firstly I work 2 days a week for EN motors, a company specialized in custom(ized) induction motors. I started half a year ago as a research engineer to improve on their knowledge on drives. Especially for the extreme cases where the drives are pushed to their absolute limit. Besides that I also follow my masters in sustainable energy engineering.
All the best,
Menno
@BonneelP Is there a particular reason, that rotor bars have their on 'if-path' without circuit properties?
... from create_FEMM_material.py
elif "BarR" in label: # Squirrel cage
prop, materials = create_FEMM_bar(
femm, is_mmfr, rotor.mat_type.elec.rho, materials
)
prop_dict[label] = prop
elif "WindR" in label: # Rotor Winding
prop, materials, circuits = create_FEMM_circuit_material(
femm, circuits, label, is_eddies, rotor, Ir, is_mmfr, j_t0, materials
)
Hello Sebastian,
I think that it was linked to the fact the SCIM was no-load only as a first implementation. I think that we can change it to define it as "WindR".
Best regards,
Pierre
Hello Menno,
I am sorry, I using VS Code and Git Bash (which is maybe somehow redundant regarding Git). So I can not give any help regarding tortoisGit.
Recently, I have implemented rotor currents (some tests are still needed, e.g. current transformations), so we can proceed with parameter estimation.I am not an induction machine expert, but I have some rough idea on a first way to do it. Nevertheless it would be very interssting if you'd had some literature or something on that topic.
Regarding validation, if you have your IM inverter driven, you may extract the machine parameters from the inverter.
BTW: Good to know, you are doing custom machines. We (the company Iam working for) recently 'lost' our IM parts deliverer. Do you also build e.g. stator laminations with winding and/or rotors only.
What is your speed/ power range?
Do you plan to use pyleecan on a regular basis? What is your actual design software? Are you also interessted in thermal calculations?
Best regards, Sebastian
Hello Menno,
just one more question. Did you also had Siemens machines at your company. You could also send a PM on that :-).
BR Sebastian
Hey sebastian,
I send you a mail regarding your questions about my company, because i dont think it is a good thing to clutter this topic with unrelated info.
Right now i have a 1,5 week holiday because i was moving to a different house. After that i can see if i can extract some parameters from a motor. Unfortunately i am nolonger allowed in the testing room due to corona refulations, so it might be difficult. But ill come back to that
On the literature ill have to search for it, this might take some time.
We dont know yet how often well use pyleecan, we roght now use mostly (semi-) empirical equations and methods collected in the 75 years or so of buisness, so we dont use any specific software at the moment.
And pierre: ill send you the files as soon as possible, however due to moving i dont have a good internet connection right now, so ill have to do it whenever i have it available.
All the best,
Menno
Hey Sebastian,
I found some literature on finite element analysis for induction motors, it's quite old (1987), but motors haven't changed that much and neither has finite element analysis so i think this should be relevant still.
thesis on finite element.pdf
I'll go and ask around for some validation data.
All the best,
Menno
Hello Menno,
I have seen this thesis before but I didn't read it all. I still can't recall if there where example machines in it but I guess. If I also remember correctly there was some very interessting part about airgap torque calculation in it.
Regarding the actual EEC I think I finished the basic implementation for now. It is in my SCIM branch and I will PR it within the next days. So additional validation cases would be very handy.
Some details are still missing, but I will point that out in the PR or hear maybe later (e.g. periodicity utilization in FEMM, current dependent parameter estimation, mean value of phi vs. rms, ...).
What I actually do is to impose a stator current (first simulation) and a rotor current (second simulation) to calculate the rotor and stator fluxlinkage.
Then the parameters are calculated by the following equations
-
sim. with stator currents
Lm = phi_rotor / I_s
Ls = (phi_stator - phi_rotor) / I_s -
sim. with rotor currents
Lm = phi_stator / I_r -> for verification
Lr = (phi_rotor-phi_stator) / I_r
Another detail is the needed number of simulation steps and the corresponding rotor speed and stator frequency to get a good average of the fluxlinkage. Maybe you could 'waste' some toughts on that as well.
BR, Sebastian
Hello Sebastian,
Another detail is the needed number of simulation steps and the corresponding rotor speed and stator frequency to get a good average of the fluxlinkage. Maybe you could 'waste' some toughts on that as well.
For that I recommand to use a method to properly initialize the simulation / multi-simulation objects. That way you can check what will be run before starting the simulation and within the simulation we run as usual ;)
Best regards,
Pierre
Hello Pierre,
I think my intention was not too clear. I don't talk about methods or something.
I was looking for the answer, what will be the best settings for:
- Nrev ... Number of rotations (not nessesary complete ones)
- N0 ... rotor speed
- felec ... stator frequency
- time axis discretization, i.e. number of simulations steps
The goal is to get the most important harmonics of the fluxlinkage for a machine with Zs stator slots and Zr rotor slots to calculate a good average or rms fluxlinkage (since I don't know how 'wrong' simulation settings will affect accuracy).
BR, S
I actually put my boss on the job to search for validation data, he thinks he already has some data available for some machines. So test data is coming your way, perhaps even today. It might be that the data is for a dual cage rotor, but we'll probably be able to provide both.
About the needed number of simulation steps: What do you exactly mean? I don't know how the steps exactly work, does it average over different orientations of the rotor, or for different phases?
If the iterations are determined by rotor orientation way it should be enough to average over Zs (number of stator tooth) simulations. Where every simulation the rotor is rotated 2pi/Zs rad, because than you would have a pretty good distribution of possible orientations of the rotor. This at least is the case for a machine where Zs =/= Zr and they are both sufficiently big, because for i.e Zs = 2, Zr= 3 there obviously are a lot more relevant positions of the rotor than 2.
I guess this doesn't provide the full picture, because the magnetic field does change a bit when you vary the phase. So i guess if you just start with phase = 0 i think you can just go up to a phase of 2pi/Nphase (number of phases) due to symmetry, because by that time you have reached the initial phase of coil. If you go through this in something like 10 steps it would probably already be more then enough. (although I suggest choosing an uneven number to make sure you get the maximum at pi/Nphase)
It might even be enough to go up to pi/Nphase. Because a phase of (1-a)pi/Nphase is basically the mirror of (1+a)pi/Phase. And physics don't change under parity transformation, or in non-physicist terms; the world doesn't change while looking in a mirror.
Hey Sebastian,
I finally have some data available, the unfortunate part is that this is for a double cage rotor, of which the slot doesn't exactly match the one we defined in #193. I'll try to define this geometry also in a new slot today, than we can start testing using this data.
Besides that i will ask for data for a regular single cage rotor. In that way we should be able to see whether or not we get accurate results for both types.
all the best, Menno
double cage rotor data.zip
Hello Menno,
Thank you for the data. Double cage should be okay for now, since this should be of interest for transient only. Correct me if I'm wrong.
To be honest, I had no sparetime to look at your yet.
I hope i can do it the next days.
Do you have some urge on that issue?
My next steps would be to implement periodicity for faster computation and add the tests then.
Best regards, Sebastian
Hey Sebastian,
Nice, im looking forward to it. I don't have much of an urge for the issue, i just would like to finish the project before february, but that should easily be doable!
Double cage is indeed mostly of interest for the transient, but i was wondering whether or not the transient could be calculated with pyleecan? Because that would be interesting.
I will try still to find some more data, although i haven't had the time to search yet.
all the best,
Menno
Hey Sebastian,
How is it coming along? Did you have time to do the test? I would like to start testing it before the end of this year myself, so i can start implementing it into our company. Would this be possible?
All the best,
Menno
Hello Menno,
I'm very sorry, despite my claim to finish it soon, I wasn't been able to actually do it. I was very busy and still I am.
But I will try my best to have it running until the weekend.
Best regards, Sebastian
No worries, these are busy times right? Take your time, although i would like to have things running around the start of february, if at all possible.
Hello Menno, I can't remember. Have you already implemented the new slot and input your machines data? BR S
Thats a good question... i can't remeber if i ever finished it, but i think not actually. I'll fix that as soon as possible (today probably)
Hey, i have a small problem. I finished the hole for the validation, but ever since i reset my computer i can't get pyleecan to work. I tried python 3.5 (as stated on your site) but i cant download all the requirements using pip somehow... i also tried multiple other versions of python but so far none seemed to work.
Therefor I was not able to test the hole to find bugs. Without proper testing i don't want to commit it to the branch so i attached everything to this post. (i also uploaded a schematic of the hole, the names of the mirrored points don't coincide with the code (P9'= P10 etc.))
HoleDC.zip
I hope this works for you! Otherwise let me know, in the mean time i will try to figure these problems with the requirements out
Hello,
In my mind we advise using Python 3.6 + for using black, where did you find the 3.5 (so I can correct it) ? By the way I'm currently using python 3.8.6. Which packages were problematic when using pip ? Maybe it is linked the Raphaël's issue with numpy: #266
What a interesting Hole you have there :) We haven't implemented yet lamination with hole containing winding but this shouldn't be too complicated. For testing, I'm starting to introduce this kind of code in the SlotMerge branch:
@pytest.mark.parametrize("test_dict", Mag14_test)
def test_comp_point_coordinate(self, test_dict):
"""Check that the point coordinates are correct"""
test_obj = test_dict["test_obj"]
point_dict = test_obj.slot._comp_point_coordinate()
Z1 = point_dict["Z1"]
Z2 = point_dict["Z2"]
Z3 = point_dict["Z3"]
Z4 = point_dict["Z4"]
ZM0 = point_dict["ZM0"]
ZM1 = point_dict["ZM1"]
ZM2 = point_dict["ZM2"]
ZM3 = point_dict["ZM3"]
ZM4 = point_dict["ZM4"]
W0 = test_obj.slot.W0
H0 = test_obj.slot.H0
Wmag = test_obj.slot.Wmag
Hmag = test_obj.slot.Hmag
Rbo = test_obj.get_Rbo()
assert abs(Z1) == pytest.approx(Rbo, rel=DELTA)
assert angle(Z1) == pytest.approx(-W0 / 2, rel=DELTA)
assert abs(Z4) == pytest.approx(Rbo, rel=DELTA)
assert angle(Z4) == pytest.approx(W0 / 2, rel=DELTA)
if test_obj.is_internal:
assert abs(Z2) == pytest.approx(Rbo - H0, rel=DELTA)
assert abs(Z3) == pytest.approx(Rbo - H0, rel=DELTA)
else:
assert abs(Z3) == pytest.approx(Rbo + H0, rel=DELTA)
assert abs(Z2) == pytest.approx(Rbo + H0, rel=DELTA)
assert angle(Z2) == pytest.approx(-W0 / 2, rel=DELTA)
assert angle(Z3) == pytest.approx(W0 / 2, rel=DELTA)
assert angle(ZM1) == pytest.approx(angle(ZM2), rel=DELTA)
assert angle(ZM1) == pytest.approx(-Wmag / 2, rel=DELTA)
assert angle(ZM3) == pytest.approx(angle(ZM4), rel=DELTA)
assert angle(ZM3) == pytest.approx(Wmag / 2, rel=DELTA)
if test_obj.is_internal:
assert ZM0 == pytest.approx(Rbo + Hmag - H0, rel=DELTA)
else:
assert ZM0 == pytest.approx(Rbo - Hmag + H0, rel=DELTA)I check that the schematics is respected in _comp_point_coordinate. I always start by this test, because if this one is wrong all the other will be. By the way, _comp_point_coordinate is a non mandatory method, so on the SlotMX I changed it to return a dictionary which I think is more convenient.
Best regards,
Pierre
Hello @MVreemann ,
I also had problems installing the requirements. You could try to install the modules one after another by hand and see if this works. You could also try to use python 3.8. I have multiple systems runing pyleecan with this version without problems.
Best regards, Sebastian
Hello again,
regarding the slot I think we should open it, i.e. have slot opening.
Have you ever tried to have a slot with zero slot opening (W0 = 0). If this would be possible ...
I thought i had read it on the pyleecan site, but now i indeed see it says 3.6 (with some weird symbols, probably a glitch, you might want to look at that)
Can't remember what the exact packages were again which gave me errors, i'll try again in a minute, see if it comes up again. UPDATE: it seems to work fine with python 3.8.6 indeed. i believe pandas didn't work for me in python 3.9 or 3.10
I know the _comp_point_coordinate method is not mandatory, but i do feel like it makes the code slightly more readable. Besides that, i used the points both in the surface calculation and the build geometry methods, so making one method for that makes sense in this case. Why is making a dictionary more convenient (just asking because I honestly have no clue)?
Would there be a reason for W0 = 0 to not work? It shouldn't change calculations too much right? Otherwise you could always make it very small, say 1e-6*slotwidth or something.
Hello again,
@BonneelP, The code you sent above, do you mean i should change the check function to a pytest? And i don't quite understand the code, for example you have:
assert angle(Z1) == pytest.approx(-W0 / 2, rel=DELTA)
To me this seems like you calculate the angle of a point, which doesn't really make sense. How should i interpret this otherwise?
Just to let you know. I'm nearly done with the first 'release' of eec_SCIM. Periodicity seems to work and the results of my example machine fit quite well. Now I only have to add some test and enable some input parameters.
Hello ,
I know the _comp_point_coordinate method is not mandatory, but i do feel like it makes the code slightly more readable
I totally agree, sorry if it seems otherwise ;) When I said it is not mandatory, it was to justify why I took the initiative to change the output for the slot I'm working on.
Why is making a dictionary more convenient (just asking because I honestly have no clue)?
This is a personal preference. I prefer the second line to the first one, it is more standard and I don't have to count if I just want to access Z4, i go to point_dict["Z4"] :
[Z10, Z9, Z8, Z7, Z6, Z5, Z4, Z3, Z2, Z1] = self._comp_point_coordinate()
point_dict = self._comp_point_coordinate()
For the code I send you, it is related to another slot, so it won't work for your slot. It is a test method so it is not meant to be used in check. It is a convenient way of making sure that the slot that you have define work and will always work what ever changes happened in the future of the project. We have a dedicated tutorial at https://pyleecan.org/tests_tutorials/test.contribution.Pyleecan.html
Best regards,
Pierre
Hey Pierre,
Ooh i totally read the code wrong, but i'll make a test class for my hole somewhere next week, probably tuesday, when i have time. Should i also make a second version which is a slot? In case using a hole is not yet properly implementable
For now, for a SCIM machine you must have a LamSlotWind object, so yes a slot version will help you. But this constraint is arbitrary and we should be able to remove it without too much work. I will try to take some time to suggest how next week. So it depend when you want your simulation to run but at the end the Hole should be all you need.
Hello to you,,
as you may noticed, I PRed the EEC for SCIM with #270. For now the EEC_SCIM class doesn't have a dedicated input object but some properties to set the calculation of the EEC parameter. This is mainly current 'I' that is used to magnetize the machine (model) to calculate the inductances.
As mentioned before the main inductance is estimated to be the fluxlinkage that is induced in the 'other' laminations winding divided by the magnetizing current 'I'. The stray inductance is then the difference of fluxlinkage in the 2 windings fluxlinkage divided by the current.
For now this excludes skew effects on the inductance but also end winding stray. Further the fluxlinkage is calculated as the mean value. As a later improvement there should at least be the option to calculate the RMS value of the fluxlinkage to also include harmonics stray (don't know if this is the right term for it in english).
The other EEC parameter are for controling the underlaying MagFEMM simulation, e.g. the rotor rotation and number of steps.
The actual EEC solver does utilize the electrical input. With the estimated or directly input EEC parameters the system is solved for the current so input voltage has to be set.
If someone has some time to spend, one could rearrange the equations to also solve for the voltages.
There are also some general changes. With the PR there is now a 'Phi_wind' property that is a list to store the winding fluxlinkage. The list index coresponds to the lamination index of get_lam_list.
This also change the way 'Phi_wind_stator' is set, i.e. 'Phi_wind_stator' is set when 'Phi_wind' is set regardless if it is in out_dict. This may not be desired and I can change this back.
Further the PR introduce the Machine method get_lam_index to get the lamination index by label.
I hope, I haven't forgot anything important here. :-) Comments are really welcome.
BR Sebastian
Hello @MVreemann, hello @BonneelP,
with the merge of #270, I think we should close this issue for now, since EEC is working for SCIM now.
Further improvements and bugs would be in their own issues then.
What do you think?
Best regards, Sebastian
Fine for me ;)
Yes, that's fine ofcourse!
Hey @SebGue,
Could you perhaps sent me a file where you use the EEC_SCIM class? I can't figure out how it works... apparently i am not too good at reading code. But if you could supply a simple piece of code as an example i can probably alter it to do what i want it to do.
Thanks in advance.
All the best,
Menno
Hello Menno,
you can have a look at Test\Validation\Simulation\test_EEC_FEMM_SCIM.py
If you need further help, let me know.
BR Sebastian