top

WhipMag JavaScript applet

Post new topic Reply to topic FizzX.org Forum Index | WhipMag Discussion/Development Goto page 1, 2, 3, 4, 5  Next   Page 1 of 5

Sun Feb 03, 2008 11:01 pm PostPost subject: WhipMag JavaScript applet
korkskrew
Regular Contributor
Regular Contributor


Joined: 25 Jan 2008
Posts: 106
Location: Longmont, CO

Reply with quote

I have created a JavaScript applet to model some of the physics of al's device. It's slow but it will allow you to play with some of the parameters before you go and build one.

I have taken this about as far as I can. I have to turn it over to you guys to finish it up, cuz if I work on it any more I'll have to go shopping for a new wife (her words). Have fun with it y'all.

This is the applet.
This is the femm model that I used to calculate the torque lookup tables.

It's fun to play with. It is quite difficult to get it to lock AGW just like the real thing seems to be, but I can get it to lock with just the right starting parameters.

*edit* The first version I upladed had a bug in the friction function. The version at the ubove URL is corrected. You can tell if you have the right version by the page title. The title on the one that works is "WhipMag JavaScript Applet V1.1" or later.

*update* I have added two new versions of the applet where I have "massaged" the torque tables to eliminate what I consider to be (rightly or wrongly) errors.

Version 1.6 has the positive offset removed from each table, and one value in the stator table "corrected". This version is based on RotorTorqueNoOffset.csv and StatorTorqueNoOffset.csv.

Version 1.6A has the same changes as 1.6, but I also removed some of the asymmetry and noise from the tables. This version is based on RotorTorqueSmoothed.csv and StatorTorqueSmoothed.csv.


Last edited by korkskrew on Fri May 30, 2008 5:28 pm; edited 3 times in total
Back to top
View user's profile Send private message Send e-mail
 
Mon Feb 04, 2008 2:09 pm PostPost subject:
korkskrew
Regular Contributor
Regular Contributor


Joined: 25 Jan 2008
Posts: 106
Location: Longmont, CO

Reply with quote

@ everyone

If you've looked at the applet, you can see it has the means to adjust a lot of parameters. Here are some points that may not be obvious:

- You can change the direction of rotation by changing the sign of velocity. Here's a fun experiment: set the rotor to 10 RPM, and the stator to 40 rpm. You will have to change the time step to 0.001 sec to see it moving.

- You will want to select the time step carfully so that you don't get really large velocity numbers at the bottom. Anything larger than about 5 degrees per time step will start to diverge from reality quite a bit.

- I just threw some default numbers in there for friction and drag. I don't know what the real numbers are. Can anyone help out with that? It would be nice to even know the correct order of magnitude.

- The default moment of inertia for the rotor is probably too low. You may want to change it to 0.00065 or so.

- for the rotor and stator objects, (I should have made these code comments)
- .v is the current velocity in degrees per time step
- .avgv is a rolling average velocity in degrees per time step
- .angle is the current rotational position relative to the other object
- .scale is a conversion factor to convert torque into a velocity change
- .cof is the constant counter torque from friction
- .cod is a coefficient for counter torque resulting from drag (a proportion of velocity)...I don't think I did a very good job implementing this in the code.

Please feel free to ask questions.

@ overconfident

As a programmer, this applet kind of gives you the opportunity to try your latch idea yourself. All you would have to do is add a function to set the stator velocity (stator.v) to zero at certian parts of the rotor cycle, or something like that.

I'm sorry it can't model the pivot, but I just don't know how to model the magnetic forces. That's why I used a lookup table. It would really be cool if someone could come up with a function that could calculate the rotor and stator torques. Then we could do things like change the distance between the rotor and stator or maybe even model a pivot.
Back to top
View user's profile Send private message Send e-mail
 
Mon Feb 04, 2008 2:40 pm PostPost subject:
overconfident
Major Contributor
Major Contributor


Joined: 10 Feb 2007
Posts: 1121

Reply with quote

@korkskrew,

Thanks. If I get some time I might play with it. I really don't expect much, though.

I've been hoping some university grad student would take an interest and create an accurate model of it using some high-powered simulation software.

I'm afraid the models we have so far are just guesstimates. The best model I've seen so far was in my dream ... and that is fading.

OC


Last edited by overconfident on Mon Feb 04, 2008 8:22 pm; edited 1 time in total
Back to top
View user's profile Send private message
 
Mon Feb 04, 2008 7:40 pm PostPost subject:
billgates
Contributor
Contributor


Joined: 27 Jan 2008
Posts: 41

Reply with quote

@korkskrew

Nice work! If only it could work in FireFox too... Wink
Could you also explain me why if I insert 1 second as the Time Step the simulation stops after 1-2 seconds and I have a "NaN" value in result fields? Here are the values I used:

Speed= 1190
Moment of Inertia= 0.0005
Friction Constant= 0.1
Drag Coefficient= 0.001

Stator Parameters:
Speed= 4760
Moment of Inertia= 0.00001
Friction Constant= 0.01
Drag Coefficient= 0.001

Misc Parameters:
Time Step (seconds)= 1
Initial Stator Angle (degrees)= 0

thanks Very Happy
Back to top
View user's profile Send private message
 
Mon Feb 04, 2008 7:58 pm PostPost subject:
korkskrew
Regular Contributor
Regular Contributor


Joined: 25 Jan 2008
Posts: 106
Location: Longmont, CO

Reply with quote

The problem is your time step. you should chose a time step that gives you only a few degrees per time step.

4760 RPM X 60 seconds per minute = 285600 degrees per second

You should use a time step around 0.00001
Back to top
View user's profile Send private message Send e-mail
 
Mon Feb 04, 2008 9:43 pm PostPost subject:
korkskrew
Regular Contributor
Regular Contributor


Joined: 25 Jan 2008
Posts: 106
Location: Longmont, CO

Reply with quote

OK, I'm an idiot.

4760 RPM X 360 degrees / 60 seconds per minute = 28560 degrees per second

The good news is the first bug is now fixed in V1.2
Back to top
View user's profile Send private message Send e-mail
 
Thu Feb 07, 2008 3:54 pm PostPost subject:
korkskrew
Regular Contributor
Regular Contributor


Joined: 25 Jan 2008
Posts: 106
Location: Longmont, CO

Reply with quote

Ok, version 1.4 is up at the same location (should I be keeping the old versions up?).

I have separated drag from friction (put it in it's own function) and fixed the math for the drag calculations.

There is still at least one major bug that I just can't figure out. It appears to me to be a power of ten problem with the speed conversion but the math works out. In the mean time I have been multiplying the speed by ten to get the correct behavior. I don't even know if it's a power of ten problem, it just seems like if I multiply the speed by ten I get behavior that mimics reality.

For now, if you want to use the applet, and you want wo see what happens at 500 RPM for example, you would enter 5000 RPM.

If anyone can help find where this problem is comming from I would be very grateful.
Back to top
View user's profile Send private message Send e-mail
 
Thu Feb 07, 2008 4:14 pm PostPost subject:
overconfident
Major Contributor
Major Contributor


Joined: 10 Feb 2007
Posts: 1121

Reply with quote

korkskrew wrote:
Ok, version 1.4 is up at the same location (should I be keeping the old versions up?).

I have separated drag from friction (put it in it's own function) and fixed the math for the drag calculations.

There is still at least one major bug that I just can't figure out. It appears to me to be a power of ten problem with the speed conversion but the math works out. In the mean time I have been multiplying the speed by ten to get the correct behavior. I don't even know if it's a power of ten problem, it just seems like if I multiply the speed by ten I get behavior that mimics reality.

For now, if you want to use the applet, and you want wo see what happens at 500 RPM for example, you would enter 5000 RPM.

If anyone can help find where this problem is comming from I would be very grateful.


I like it, but it doesn't look quite like "my" reality. I'd help if I could, but I'm not familiar enough with the math or physics and I'm not really sure the lookup table is quite right. I'd like to see what happens if one of those high powered simulators used by disk drive manufacturers was used to model this.

Keep on keepin on. Wink
Back to top
View user's profile Send private message
 
Thu Feb 07, 2008 4:35 pm PostPost subject:
korkskrew
Regular Contributor
Regular Contributor


Joined: 25 Jan 2008
Posts: 106
Location: Longmont, CO

Reply with quote

The lookup tables come straight out of the FEMM model, so they are the thing I trust the most. Because the speed of the interactions between the magnets is relatively low compared to the speed of magnetic viscosity I think the tables should hold up pretty well. It would be a lot better to have a continuous function, but the tables are high enough resolution that it does a decent job of modeling reality.

As for adding stators and other machanical interactions that can be done by adding new functions to represent them.

I know this thing won't get any respect though until I (or someone) figure out that damn scaling problem. It's vexing me! Mad
Back to top
View user's profile Send private message Send e-mail
 
Fri Feb 08, 2008 3:08 am PostPost subject:
Harvey
Major Contributor
Major Contributor


Joined: 16 Jan 2008
Posts: 1927

Reply with quote

korkskrew wrote:

I know this thing won't get any respect though until I (or someone) figure out that damn scaling problem. It's vexing me! Mad


I'll have a look at it.

EDIT: I still have more to look through, like your torque to velocity conversions.

I'm not familiar with your use of the ParseInt(x,y) - what is the y parm?

Also your .maxv trap where you set the rotor.scale and stator.scale to x^2 has me a bit puzzled. I know this is supposed to help match resolution of the torque table but I am uncertain as to all the implications here.
Back to top
View user's profile Send private message
 
Wed May 28, 2008 12:08 pm PostPost subject: Modifications for the 180 Snap
Harvey
Major Contributor
Major Contributor


Joined: 16 Jan 2008
Posts: 1927

Reply with quote

@Korkskrew,

I added the following code in your torque function at line 248:
Code:
if (r_angle < 45) {
               s_angle = 93;
      } else {
            if (r_angle < 90) {
                  s_angle = 273;
      } else {
         if (r_angle < 135) {
                     s_angle = 93;
         } else {
            if (r_angle < 270) {
                  s_angle = 273;
            } else {
               if (r_angle < 315) {
                     s_angle = 93;
               } else {
                  if (r_angle >= 315) {
                        s_angle = 273;
                  }
               }
            }
         }
       }
      }


When setting the rotor RPM to 12 and the Stator RPM to 48 the velocity for each goes negative and in a few minutes we get upwards of 25,000 Rotor RPM and climbing.

Essentially I was trying a quick and dirty 180 snap off your existing tables to see if Cloud Campers rig could accelerate by a simple stator repositioning. I'm a bit confused as to why it only wants to go CCW though. It works the same even without the 3 offsets. Initial rotor RPM < 12 seems to stall.

I'd like to know if I hosed some other routine or if this reflects the FEMM data for a stator reposition. It is my theory that the stator can be repositioned during the shear period with no KE transfer to or from the rotor for the repositioning. If so, then this is an OU technique and we need to find out why conservation laws allow it..
Back to top
View user's profile Send private message
 
Wed May 28, 2008 2:43 pm PostPost subject:
korkskrew
Regular Contributor
Regular Contributor


Joined: 25 Jan 2008
Posts: 106
Location: Longmont, CO

Reply with quote

Harvey wrote:

EDIT: I still have more to look through, like your torque to velocity conversions.

I'm not familiar with your use of the ParseInt(x,y) - what is the y parm?

Also your .maxv trap where you set the rotor.scale and stator.scale to x^2 has me a bit puzzled. I know this is supposed to help match resolution of the torque table but I am uncertain as to all the implications here.


Jeez! I didn't see this edit until just now! Sorry!

The y param in ParseInt just specifies base 10 numeric conversions. I know that's the default...just call me a control freak...my wife does all the time... Confused

The model runs in discrete increments of time (timestep), but if it gets to going too fast, too much information in the torque table is skipped, and if it gets going too slow there is nothing to be gained because it is already below the resolution of the table. What I'm doing in this section is adjusting the time step based on the stator and rotor velocity to keep the simulation progressing in a useful way. x is the time step scaling factor.

rotor.scale, and stator.scale are used, as you noticed, to convert torque, to degrees per timestep. This is an acceleration function.
F = ma
Substitute d/t^2 for a and then solve for d (in this case d is degrees instead of distance). So now we get
d = (t^2)F/m
F comes from the torque function, so .scale is the (t^2)/m part.

When I change timestep, I have to change .scale by the square of the factor that I used to change timestep. That's why scale is multiplied by x^2.

Gawd, I hope that was easier to read than it was to write.

Harvey wrote:

When setting the rotor RPM to 12 and the Stator RPM to 48 the velocity for each goes negative and in a few minutes we get upwards of 25,000 Rotor RPM and climbing.


You must have the friction set quite low. I believe you are falling victim to one of the problems with the torque tables that OC noticed. They have a slight positive offset. If friction is too low, the thing is going to take off CW every time. I believe this is a result of a math error in FEMM.

Tell you what. By the end of the day tomorrow, I'll try to have V1.6 up with the torque offsets removed (and one stator torque value corrected). I'll also have a V1.6a that removes the asymmetry from the torque table. This will have the same effect as what you are trying to achieve with the 180 degree limit. I will also post new .csv files containing the torque tables used in each version.

Harvey wrote:

I'd like to know if I hosed some other routine or if this reflects the FEMM data for a stator reposition. It is my theory that the stator can be repositioned during the shear period with no KE transfer to or from the rotor for the repositioning. If so, then this is an OU technique and we need to find out why conservation laws allow it.

I'll have to look at this, but just off hand I would have to say that the rotor and stator are only completely decoupled when they are at exactly 0 degrees for the rotor and 270 degrees for the stator (FEMM angles) or 22.5 degrees for the rotor and 180 degrees for the stator. At any other point there is some greater or lesser amount of coupling.

I know you like your shear theory, but I don't think just skipping parts of my torque table is going to get you where you want to go. You would need some mathematical model of the shear process and how it effects torque, then add that as a separate function to amend my torque function.
Back to top
View user's profile Send private message Send e-mail
 
Wed May 28, 2008 8:09 pm PostPost subject: Re: WhipMag JavaScript applet
Yadaraf
Major Contributor
Major Contributor


Joined: 30 Jan 2008
Posts: 436

Reply with quote

korkskrew wrote:
I have created a JavaScript applet to model some of the physics of al's device. It's slow but it will allow you to play with some of the parameters before you go and build one.

I have taken this about as far as I can. I have to turn it over to you guys to finish it up, cuz if I work on it any more I'll have to go shopping for a new wife (her words). Have fun with it y'all.

@korkscrew,

Fantastic job on the programming. Cool Glad to see that the top post reflects the most current version.

I wish it were that simple. Having played with one of these device for a few days now and looking closely at Al's videos, it's clear that the AGW stator has a significant wobble. God only knows what the flux is really doing. The rotor has a wobble as well, but in a slightly different way.

.. Q: Is there any way you can add a factor for stator wobble and/or rotor wobble?

The below pic shows the relationship between planetary precession and nutation. As for the Whipmag, consider that the stator exhibits precession and the rotor exhibits nutation. The rotor might also exhibit precession, but to a lesser degree.

P=precession, N=Nutation



Note that the stator wobbles relative to the the 4-40 screw (dotted line in above pic), like Earth's precession. The rotor wobbles in a circular fashion, like Earth's nutation. (The stator wobble when viewed from the top reminds me of OC's vortex. As MADPROF has pointed out, you can see the stator wobble very clearly in the fourth hi-speed videos.)

.. Stator Wobble: http://www.youtube.com/watch?v=crapAVI7zQ4

Cheers Smile
Yada ..
_________________
Any sufficiently advanced technology is indistinguishable from magic. (Clarke's law)
Changing the world, one magnet at a time. (Yada)
Back to top
View user's profile Send private message
 
Wed May 28, 2008 8:36 pm PostPost subject:
Harvey
Major Contributor
Major Contributor


Joined: 16 Jan 2008
Posts: 1927

Reply with quote

Korkskrew wrote:

If friction is too low, the thing is going to take off CW every time.


Thats the problem, this only works CCW AGW Confused

Korkscrew wrote:

You would need some mathematical model of the shear process and how it effects torque, then add that as a separate function to amend my torque function.

I agree. From what I can tell, we need to calculate the inertial load based on the acceleration / deceleration of the 180 Snap. My son and I worked some of this out and arrived at a timing of 67s for 45 against the 10g load. The concept here is power is applied for 67s, the stator coasts for 90, and then decelerates to a stop during the final 45. Using a mogen, the deceleration stage recovers the conserved momentum energy by placing a capacitive 'short' across the gen windings, thus loading it to a stop while charging the cap. This affords full movement of the stator during 2 of the rotors equitorial pass which has a torque angle near 90 to the rotor (near zero torque). So, about 99% of the ~300J of energy used to snap the stator is recovered and the drive energy is decoupled from the rotor load. This means that the rotor is driven by magnet power alone and the energy out / energy in is about 5.1J / 3J which is over unity. Wink


Last edited by Harvey on Wed May 28, 2008 10:51 pm; edited 1 time in total
Back to top
View user's profile Send private message
 
Wed May 28, 2008 8:51 pm PostPost subject:
korkskrew
Regular Contributor
Regular Contributor


Joined: 25 Jan 2008
Posts: 106
Location: Longmont, CO

Reply with quote

Yadaraf wrote:

Q: Is there any way you can add a factor for stator wobble and/or rotor wobble?

Not really. This doesn't model the magnets. I used FEMM to do that, and put the results of the FEMM simulation into this applet in the form of a pair of torque tables. That means this simulation only applies to 2D, not 3D, and only to the specific size/distance relationships in th FEMM model. In that respect it is quite limited.

On the other hand, it's pretty easy to add a function that controls or modulates various parameters. My main purpose of this model was to show the nonlinear aspects of the interactions between the rotor and stator, and give a way fo playing with how to control that without having to build an actual device.

An example of this would be to add the influence of the MKJD's by adding a function that applies a counter-torque that is a sigmoid function of the stator angle and speed.
Back to top
View user's profile Send private message Send e-mail
 
Wed May 28, 2008 8:54 pm PostPost subject:
korkskrew
Regular Contributor
Regular Contributor


Joined: 25 Jan 2008
Posts: 106
Location: Longmont, CO

Reply with quote

Harvey wrote:

Thats the problem, this only works CCW AGW Confused


Could you post all of the parameter values you are using?
Back to top
View user's profile Send private message Send e-mail
 
Wed May 28, 2008 9:04 pm PostPost subject:
Harvey
Major Contributor
Major Contributor


Joined: 16 Jan 2008
Posts: 1927

Reply with quote

Here ya go Very Happy
Code:
Speed=<INPUT id=rotorspeed onchange=setUp()
value=12> (RPM)<BR>Moment of Inertia=<INPUT id=Irotor onchange=setUp()
value=0.000669> (Kg m<SUP>2</SUP>)<BR>Friction Constant=<INPUT id=rotor_cof
onchange=setUp() value=0.0005> (Nm)<BR>Drag Coefficient=<INPUT id=rotordrag
onchange=setUp() value=0.0001><BR><BR>
<H3>Stator Parameters:</H3>Speed=<INPUT id=statorspeed onchange=setUp()
value=48> (RPM)<BR>Moment of Inertia=<INPUT id=Istator onchange=setUp()
value=0.00000025> (Kg m<SUP>2</SUP>)<BR>Friction Constant=<INPUT id=stator_cof
onchange=setUp() value=0.0001> (Nm)<BR>Drag Coefficient=<INPUT id=statordrag
onchange=setUp() value=0.0001><BR><BR>
<H3>Misc Parameters:</H3>Initial Stator Angle (degrees)=<INPUT id=statorstart
onchange=setUp() value=90>
Back to top
View user's profile Send private message
 
Wed May 28, 2008 9:16 pm PostPost subject:
lostcauses
Major Contributor
Major Contributor


Joined: 02 May 2008
Posts: 871
Location: NM

Reply with quote

With out all the stuff going on in the system it is going to be chaotic is motion to velocity relations.

The simple just agw effect is not a controlled effect; depending on friction (drag) to mass an velocity relationships this process is going to be unpredictable. As in the sym it shows a lot of velocity changes to stator. Yet due to the interactions of MKJDs and idlers we see a more controled ( less action on stator, a more constant velocity) in the HSF vids.

It is such that just due to gain, the next timing of stator to rotor has changed. The potential energy to kinetic timing is now off. It will effect timing. If it gets over the angle were it can correct or gain, well. Chaos is what normally will happen. One may adjust the friction (drag) to limit the effect, But good luck on getting a sym to show this in a self running effect with just the AGW action.
Back to top
View user's profile Send private message
 
Wed May 28, 2008 9:36 pm PostPost subject:
Yadaraf
Major Contributor
Major Contributor


Joined: 30 Jan 2008
Posts: 436

Reply with quote

korkskrew wrote:
Yadaraf wrote:

Q: Is there any way you can add a factor for stator wobble and/or rotor wobble?

Not really. This doesn't model the magnets. I used FEMM to do that, and put the results of the FEMM simulation into this applet in the form of a pair of torque tables. That means this simulation only applies to 2D, not 3D, and only to the specific size/distance relationships in th FEMM model. In that respect it is quite limited.

On the other hand, it's pretty easy to add a function that controls or modulates various parameters. My main purpose of this model was to show the nonlinear aspects of the interactions between the rotor and stator, and give a way fo playing with how to control that without having to build an actual device.

An example of this would be to add the influence of the MKJD's by adding a function that applies a counter-torque that is a sigmoid function of the stator angle and speed.

korkscrew,

Thanks. I'm experimenting with tuned stator wobble now, and can vary the degree of precession quite easily. In this way it's easy to add a third degree to the interaction, but there's a lot of trial and error. In any event, I am much closer to simulating Al's stator wobble. (Now if I can just get my other two stators to cooperate. My new bearings are too precise -- even though they are cheap and dry.

Cheers Smile
Yada ..
_________________
Any sufficiently advanced technology is indistinguishable from magic. (Clarke's law)
Changing the world, one magnet at a time. (Yada)
Back to top
View user's profile Send private message
 
Wed May 28, 2008 9:49 pm PostPost subject:
korkskrew
Regular Contributor
Regular Contributor


Joined: 25 Jan 2008
Posts: 106
Location: Longmont, CO

Reply with quote

If, as Al stated, no new physics is required to explain the behavior of his device, then it should be possible to add functions that model the various physical systems in his device until it shows the same behavior as the physical thing. My hope was that exercise would reveal what was and was not important to consider.

The model was meant to be a starting point...not a solution.

Unfortunately, where everyone who has built a physical model can get stable AGW behavior at about 1000 rotor RPM, this javascript model needs to be spun at about 10000 RPM to get similar stable behavior. I have never been able to identify the source of this scaling problem.

Is it friction? My recent calculations suggest that the friction may be off by several orders of magnitude.

Is it the torque table defects? I've known about the offsets for a while, but some recent analyses I've been doing have identified a conspicuously errant value in the stator torque table, inexplicable phase asymmetries and other weirdness that I am not sure I can blame on FEMM.

My personal suspicion is that I put a math error in the .scale factors and for some reason I'm blind to it. I always supect that kind of thing when I see an order of magnitude error.

I dunno, and I had quit working on this model until there was a resurgence of interest in it. I'll fix the defects that I know about in the torque tables, but it'll be up to y'all to come up with ideas that might make it more closely approximate reality.
Back to top
View user's profile Send private message Send e-mail
 
Thu May 29, 2008 12:34 am PostPost subject:
Harvey
Major Contributor
Major Contributor


Joined: 16 Jan 2008
Posts: 1927

Reply with quote

Gaaah Exclamation

I musta been tired when I did that - I left out 3 of the magnets Shocked

Code:
if (r_angle < 45) {
               s_angle = 87;
      } else {
            if (r_angle < 90) {
                  s_angle = 267;
      } else {
         if (r_angle < 135) {
                     s_angle = 87;
         } else {
            if (r_angle < 180) {
                  s_angle = 267;
            } else {
               if (r_angle < 225) {
                     s_angle = 87;
               } else {
                  if (r_angle < 270) {
                        s_angle = 267;
                  } else {
                     if (r_angle < 315) {
                           s_angle = 87;
                     } else {
                        if (r_angle >= 315) {s_angle = 267};
                        }
                     }
                  }
               }
            }
         }
       }


This was an attempt to get things going CW - this is really strange. Interesting, I left it run for about a half hour before checking back and found it running 'stable' in GW mode Shocked Velocities: Rotor -24903 Stator +143 - go figure Neutral

ETA: This drastically changes the energy ratios to some seriously high OU condition. Only 286 flips per minute on the stator yielding a ridiculously high momentum on the rotor. Hmmm, I wonder if there is a term swapped somewhere - like stator should be rotor etc. Confused
Back to top
View user's profile Send private message
 
Thu May 29, 2008 3:17 pm PostPost subject:
Mr.Entropy
Regular Contributor
Regular Contributor


Joined: 28 Aug 2007
Posts: 67
Location: Canada

Reply with quote

korkskrew wrote:
If, as Al stated, no new physics is required to explain the behavior of his device, then it should be possible to add functions that model the various physical systems in his device until it shows the same behavior as the physical thing. My hope was that exercise would reveal what was and was not important to consider.

You don't even have to do the work. Just think of each function you want to add and then ask yourself "does this function violate CoE?" and "does this function introduce an external source of energy?". If the answer to both of those is "no", then it won't give you anomalous acceleration. If the answer to either of those is "yes", then you have a theory about the energy source and you don't need to bother coding it into the sim.
Back to top
View user's profile Send private message
 
Thu May 29, 2008 3:43 pm PostPost subject:
Harvey
Major Contributor
Major Contributor


Joined: 16 Jan 2008
Posts: 1927

Reply with quote

You mean like spinning things by hand?
Back to top
View user's profile Send private message
 
Thu May 29, 2008 4:05 pm PostPost subject:
lostcauses
Major Contributor
Major Contributor


Joined: 02 May 2008
Posts: 871
Location: NM

Reply with quote

'does this function violate CoE?"
define such in relations to magnets!
Back to top
View user's profile Send private message
 
Thu May 29, 2008 4:20 pm PostPost subject:
Harvey
Major Contributor
Major Contributor


Joined: 16 Jan 2008
Posts: 1927

Reply with quote

lostcauses wrote:
'does this function violate CoE?"
define such in relations to magnets!


A function that unrealistically converts torque from a magnetic lookup table to momentum greater than would be expected when applying conservation of energy rules.
Back to top
View user's profile Send private message
 
Thu May 29, 2008 4:31 pm PostPost subject:
lostcauses
Major Contributor
Major Contributor


Joined: 02 May 2008
Posts: 871
Location: NM

Reply with quote

LOL
Back to top
View user's profile Send private message
 
Thu May 29, 2008 6:14 pm PostPost subject:
Mr.Entropy
Regular Contributor
Regular Contributor


Joined: 28 Aug 2007
Posts: 67
Location: Canada

Reply with quote

Harvey wrote:
You mean like spinning things by hand?

Yes, but I expect that you'd start the simulation at some time _after_ all the manual spinning was complete. Smile
Back to top
View user's profile Send private message
 
Fri May 30, 2008 2:05 pm PostPost subject:
korkskrew
Regular Contributor
Regular Contributor


Joined: 25 Jan 2008
Posts: 106
Location: Longmont, CO

Reply with quote

OK, as promised...but later than promised...whatever...

WhipMag Javascript applett version 1.6: This version is the same as 1.5 except two flaws were removed from the torque tables. An overall positive offset in each table was subtracted from all of the values, and the stator torque at angles 0,0 was changed from 0.10102 to 0.099. These changes were made because I believe them to be math errors in FEMM and cannot exist in reality. These errors are actually documented in the FEMM errata. I believe that this version is much preferred to V1.5. Please note that I also changed the default friction values to be more in line with what I think is real, but they are still just guesses, because there is inadequate data to know what they actually are in Al's rig.

RotorTorqueNoOffset.csv, and StatorTorqueNoOffset.csv are the torque tables used for V1.6.

WhipMag Javascript applett version 1.6A: This version has some asymmetry in the torque tables removed by averaging the four quadrants of the table together. This also has the effect of reducing the "noise" in the table by about 6dB. I made this version because I cannot think of any way the asymmetry can exist in real life so I have to assume it's a FEMM error. However, I am equally stumped trying to come up with a way FEMM could create this kind of error. That said, I think this version is preferable to V1.6 because it will behave the same regardless of the direction of the interaction between the magnets.

RotorTorqueSmoothed.csv, and StatorTorqueSmoothed.csv are the torque tables used for V1.6A.

Since both of these versions are based on V1.5, they also share the conspicuous scaling problem that V1.5 has. I'm starting to think Harvey is right, and that I somehow botched the .scale parameters. But I still can't figure out how. Confused
Back to top
View user's profile Send private message Send e-mail
 
Fri May 30, 2008 2:50 pm PostPost subject:
korkskrew
Regular Contributor
Regular Contributor


Joined: 25 Jan 2008
Posts: 106
Location: Longmont, CO

Reply with quote

Mr.Entropy wrote:
You don't even have to do the work. Just think of each function you want to add and then ask yourself "does this function violate CoE?" and "does this function introduce an external source of energy?". If the answer to both of those is "no", then it won't give you anomalous acceleration. If the answer to either of those is "yes", then you have a theory about the energy source and you don't need to bother coding it into the sim.


I don't necessarily agree with you. For instance one theory has to do with the stator bearing binding. That would be modeled with a variable friction function that depended on the angles of the rotor and stator. So with this theory, friction (loss) would be added to see if it caused the thing to speed up.
Back to top
View user's profile Send private message Send e-mail
 
Fri May 30, 2008 3:47 pm PostPost subject:
Mr.Entropy
Regular Contributor
Regular Contributor


Joined: 28 Aug 2007
Posts: 67
Location: Canada

Reply with quote

korkskrew wrote:
I don't necessarily agree with you. For instance one theory has to do with the stator bearing binding. That would be modeled with a variable friction function that depended on the angles of the rotor and stator. So with this theory, friction (loss) would be added to see if it caused the thing to speed up.


Friction turns kinetic energy into heat, conserving CoE. Generally, in a theory that doesn't violate CoE, there is a value called "energy" that you can calculate from the state of the system, and this value remains constant. It doesn't really matter how you calculate it, as long is it includes kinetic energy and heat losses -- you can put in anything else that you like.

Then, whenever some object in the sim moves against a force, you end up reducing kinetic energy, but the motion alters the state of the system to make your "energy" calculation come out to the same value. Whenever some object moves with a force, you increase kinetic energy, but the energy calculation performed on the new state of the system must come out to the same value.

For example, lets say you wanted to model magnetic viscosity in your sim. You and I don't know _exactly_ how to calculate the effects of magnetic viscosity, and even if we did, we'd probably want to use some kind of approximation instead, so we have to choose the effect we model. Unless you have some specific theory about why the effect would violate CoE, the reasonable thing to do is to carefully choose your calculation to preserve CoE as defined above. You would modify your "energy" calculation to include some notion of potential energy due to the magnetization of the materials, and some ways in which magnetization of the materials affects the forces on objects, and would then ensure that as objects move, the difference in kinetic energy is still matched by an opposite difference in all the other kinds of energy.

Often, the easiest way to do all of this is to calculate the forces on objects directly from their contributions to the energy calculation -- if you know how fast kinetic energy changes to potential as the rotor rotates, and you know that kinetic energy only changes due to the application of a force, then you can calculate that force.
Back to top
View user's profile Send private message
 
Post new topic Reply to topic FizzX.org Forum Index | WhipMag Discussion/Development
View previous topic
View next topic
Display posts from previous:   




You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum