-
#780 by Rodal on 26 Dec, 2015 18:35
-
Yes, I think we understand each other
-
#781 by not_a_physicist on 26 Dec, 2015 18:45
-
Thank you. CSVs for 2 test runs attached. Ch1 is pendulum position (the value is in Volts, scale is 1V = 1000 um). Ch2 is High-Voltage on command (0 to 5 V change), Ch3 is RF on command (0 to 5 V change). Each run also includes 3 CSV files for Ch1 min, max and mid-point as-detected. Have fun!
Thanks for the CSVs!
I'm going to post my analysis. (I know that you (RFPlumber) already know all this, but I want to document where this is all coming from.)
The restoring force on a freely swinging pendulum is Frestoring = -m g sin(θ)
where m is the mass (kg) of the pendulum, g is the standard 9.8 ms-2 of gravitational acceleration, and θ is the deflection of the pendulum from vertical.
The deflection from vertical in these runs is very small, so sin(θ) can be replaced by θ, leaving.
Frestoring = -m g θ
This leads to the pendulum behaving like an ideal spring, oscillating in a nice sine wave. Everything up to here is explained in http://hyperphysics.phy-astr.gsu.edu/hbase/pend.html#c3.
In the middle of a swing, right between minimum and maximum of a sine wave, the displacement graph looks like a straight line. That is, the pendulum is not accelerating in either direction. That means that the forces on it all cancel out. In this case, that means the restoring force cancels out the thrust:
Fnet = 0 = -m g θ + thrust
thrust = m g θ
RFPlumber is measuring horizontal displacement (x), not deflection from the vertical. Using some geometry and that same approximation for tiny angles, x = sin(θ) * L ≈ θ * L, where L is the length of the pendulum.
thrust = x m g L-1
That is, under the assumptions I've made, thrust is proportional to horizontal displacement, with the proportionality constant being made of things that are easy to measure.
Something I was uncertain about was how the pendulum would react right when the thrust force was turned on. Would it take a while to settle on a horizontal offset? I simulated a pendulum, and it turns out the answer is: no, it immediately has the correct offset! Very convenient for analysis. I'm attaching some of the simulated output to show that, where I've hit the pendulum with various amounts of force at various points in its cycle and always gotten that very immediate change in midpoint. (That this change is exact is not completely obvious from just looking at the picture, but analyze.py below is quantitative about it and agrees.)
The simulation is the attached pendulum.py . It passes basic sanity checks, like getting the period of oscillation correct, conserving energy when it swings without thrust, and looking like a sine wave. (It does not use this sin(θ) ≈ θ approximation, for anyone wondering about that being dangerously circular.)
The simulator outputs a CSV file that is about like RFPlumbers. It has three columns: time, horizontal displacement, and whether the thrust is being applied.
The code to analyze runs is attached below. It doesn't do any useful statistics yet -- it computes force but does not compute probability of being correct. You give it the pendulum mass and a CSV file. It tells you when and where minimums/maximums exist and what the thrust it derives from them are. It computes midpoints by averaging minimums and maximums that are adjacent and have the same thrust-vs-not condition.
Here is a sample run of the simulator and analysis with 10uN of thrust:
python pendulum.py --thrust_un 10 --thrust_start 5 --thrust_stop 15 --sim_stop 20 --mass 3 --length 3 --theta0 0.000007 | python analyze.py --mass 3
3480, 0.021000, 0.000000
5200, -0.020927, 1.000000
6940, 0.022968, 1.000000
8680, -0.020928, 1.000000
10420, 0.022969, 1.000000
12160, -0.020928, 1.000000
13900, 0.022968, 1.000000
15660, -0.021548, 0.000000
17400, 0.021547, 0.000000
19130, -0.021547, 0.000000
Active midpoints: mean=0.001020, variance=0.000000
Inactive midpoints: mean=-0.000000, variance=0.000000
Difference of means: 0.001020
Thrust = 10.002770 uN
With the actual data, I trimmed the run to seconds 24 through 50 to exclude the "RF on" section and just see what the HV command does. The result from analyze.py is 546 uN.
I also trimmed the run to cover seconds 0 through 30 to exclude the HV command and see what the "RF on" command does. The result from analyze.py is 26 uN. I am glad that this agrees with the 20-40uN result you got!
Anyone interested can reproduce those numbers with
python analyze.py --mass 3 < actual_ch2.csv
python analyze.py --mass 3 < actual_ch3.csv
-
#782 by ThereIWas3 on 26 Dec, 2015 21:59
-
I found a tool called OpenSCAD that will do 3D renderings of algorithmic design data. That is, you write a sort of program that draws things in 3D. I might be able to write meep code that dumps out whatever the model in meep is, so that openSCAD can draw it. This would be a way of verifying that the model you put into meep is what you think it is. (Meep's notation not always being obvious.)
This one is based on my understanding of SeeShell's blueprint.
-
#783 by RFPlumber on 26 Dec, 2015 22:24
-
Thank you. CSVs for 2 test runs attached. Ch1 is pendulum position (the value is in Volts, scale is 1V = 1000 um). Ch2 is High-Voltage on command (0 to 5 V change), Ch3 is RF on command (0 to 5 V change). Each run also includes 3 CSV files for Ch1 min, max and mid-point as-detected. Have fun!
Thanks for the CSVs!
I'm going to post my analysis.
...
With the actual data, I trimmed the run to seconds 24 through 50 to exclude the "RF on" section and just see what the HV command does. The result from analyze.py is 546 uN.
I also trimmed the run to cover seconds 0 through 30 to exclude the HV command and see what the "RF on" command does. The result from analyze.py is 26 uN. I am glad that this agrees with the 20-40uN result you got!
I am glad you ended up with the same numbers! I had a similar simulation done in Excel before starting this whole pendulum exercise. It was interesting to see how the actual amplitude can change (can either increase or decrease!) depending on the starting point (phase) of applying the force, but the mid-point of oscillations would always reflect the force correctly.
-
#784 by RFPlumber on 26 Dec, 2015 22:55
-
I am sure this has already been explained somewhere and probably more than once, but I just can't find it...
How to include pictures (which are attached to the post) into the middle of the post and also prevent the same pictures from displaying again at the end of the post?
I know there is an "img" tag. It requires a URL. If I just type the attachment name in there, it shows nothing. So I then go edit the post to update all the img tags with the actual URLs to attached pictures. Now those pictures start showing up fine, but they also all get displayed again at the end of the post... Given that there are posts which do not have this problem, I am definitely doing something wrong here... Please, advise. -
#785 by RotoSequence on 26 Dec, 2015 23:16
-
I am sure this has already been explained somewhere and probably more than once, but I just can't find it...
How to include pictures (which are attached to the post) into the middle of the post and also prevent the same pictures from displaying again at the end of the post?
I know there is an "img" tag. It requires a URL. If I just type the attachment name in there, it shows nothing. So I then go edit the post to update all the img tags with the actual URLs to attached pictures. Now those pictures start showing up fine, but they also all get displayed again at the end of the post... Given that there are posts which do not have this problem, I am definitely doing something wrong here... Please, advise.
If you prefer to have the pictures in-line with the post rather than at the end, try using an external image host, like imgur or photobucket or flickr. Of the three, imgur is probably the easiest and lowest hassle service. Once you've uploaded your image to your image host of choice, use the uploaded image's address between the image tags and voila! All set.
However, images wider than ~500 pixels will break the forums and their formatting. If they are too large, you should stick with the image attachment functionality and avoid in-line image posts. -
#786 by RFPlumber on 27 Dec, 2015 00:00
-
I am sure this has already been explained somewhere and probably more than once, but I just can't find it...
How to include pictures (which are attached to the post) into the middle of the post and also prevent the same pictures from displaying again at the end of the post?
I know there is an "img" tag. It requires a URL. If I just type the attachment name in there, it shows nothing. So I then go edit the post to update all the img tags with the actual URLs to attached pictures. Now those pictures start showing up fine, but they also all get displayed again at the end of the post... Given that there are posts which do not have this problem, I am definitely doing something wrong here... Please, advise.
If you prefer to have the pictures in-line with the post rather than at the end, try using an external image host, like imgur or photobucket or flickr. Of the three, imgur is probably the easiest and lowest hassle service. Once you've uploaded your image to your image host of choice, use the uploaded image's address between the image tags and voila! All set.
However, images wider than ~500 pixels will break the forums and their formatting. If they are too large, you should stick with the image attachment functionality and avoid in-line image posts.
Yes, with externally hosted images it is trivial.
However, it is definitely possible to refer inline to attached pictures. See this post for example: http://forum.nasaspaceflight.com/index.php?topic=39004.msg1465342#msg1465342
How do they do it?
-
#787 by DnA915 on 27 Dec, 2015 00:14
-
Hi All,
I just wanted to give an update on my search for a way to get the complex simulations needed within a reasonable machine. For those who have not read this part of the thread, we need to run the EM simulations out much further than they have been, but currently, we have no way to do it in a reasonable time period.
- Previously I pointed out the GPU (NVIDIA CUDA) driven B-CALM EM simulator which I think is a good choice. This paper was about 4 years old so I decide to dig into the specs. They were using a quad core top of the line 3Ghz processor for this. This is fairly nice specs even for today. However, as some might be aware, GPU hardware is advancing much faster as it uses parallelization vs higher frequencies. They tested on this hardware:
Tesla C1060 - 240 Cores @ 1.296GHz
These specs are not very good for todays mid to high range. We could get 2000-2500 cores at a similar clock speed now for only $300 -$400 (maybe even better). Int the paper, they said that the GPU version gave them a 30X boost in speed. In conclusion, I think its not far fetched to say that it may now be closer to a 300X boost in speed on a high end graphics card, assuming also we have some overhead with increased parallelization. This means that something in MEEP that might take a year to simulate may only take a day or so. If we have a multi-card setup, then this could get even faster, perhaps even near the 1000x faster mark with 3 cards linked.
Additionally, I found this program using GPU for FDTD: http://gsvit.net
Unfortunately for me, all my cards are ATI and all these programs use NVIDIA's CUDA language.
- David
-
#788 by DnA915 on 27 Dec, 2015 00:19
-
P.S. - If anone wants to drop 30K and solve the problem
http://www.hardwarezone.com.sg/tech-news-meet-highest-density-compute-accelerator-over-79800-cuda-cores
29,800 Cuda Core Machine - This might be close to 4000x faster than MEEPS -
#789 by VAXHeadroom on 27 Dec, 2015 00:43
-
I found a tool called OpenSCAD that will do 3D renderings of algorithmic design data. That is, you write a sort of program that draws things in 3D. I might be able to write meep code that dumps out whatever the model in meep is, so that openSCAD can draw it. This would be a way of verifying that the model you put into meep is what you think it is. (Meep's notation not always being obvious.)
That looks pretty close, but I think maybe the waveguides are too small. Can you post the OpenSCAD file please? I can help look at it and also I can use that as the basis for a POV-Ray model...
This one is based on my understanding of SeeShell's blueprint. -
#790 by RotoSequence on 27 Dec, 2015 00:53
-
it is definitely possible to refer inline to attached pictures. See this post for example: http://forum.nasaspaceflight.com/index.php?topic=39004.msg1465342#msg1465342
How do they do it?
Stuff like this?
[img ]http://forum.nasaspaceflight.com/index.php?action=dlattach;topic=39004.0;attach=1089416;image[/img ]
It looks like the embedded images are what you get when you right click -> view an NSF hosted image. -
#791 by aero on 27 Dec, 2015 00:56
-
Well ...
I feel really stupid today...
and since this thread is read by a large audience, I feel really, really stupid...
When I started with meep I was searching for energy as evanescent waves escaping through the small gaps in the construction of the frustum. As a consequence of the gaps being very small, quite high resolution was needed.
I quit searching for evanescent forces months ago and decreased the resolution modestly but still held the thought that the skin is thin so the resolution needed to be high. It dawned on me finally today that that is bogus.
If we are not concerned with the details of the E&M within the skin beyond the macroscopic model, then it seems to me there is no need to resolve the skin. Meep needs about 10 points per wavelength to resolve the EM fields. Attached is a center slice of a thick skinned Brady cavity at resolution 40. The meep wavelength is ~0.51 units giving ~ 20 points/wavelength. The skin is 1/2 wavelength giving 10 cells across it.
So its not a pretty cavity outline due to granularity and there are likely other issues but this is an approach to the meep run time issue that I should have thought of months ago.
Evaluations please.
-
#792 by ThereIWas3 on 27 Dec, 2015 01:32
-
A further idea for faster computation is using cylindrical symmetry. Although this constrains the shapes that can be used, initial experiments suggest a 100x speedup.
-
#793 by DnA915 on 27 Dec, 2015 01:46
-
Hi All,
I just wanted to give an update on my search for a way to get the complex simulations needed within a reasonable machine. For those who have not read this part of the thread, we need to run the EM simulations out much further than they have been, but currently, we have no way to do it in a reasonable time period.
- Previously I pointed out the GPU (NVIDIA CUDA) driven B-CALM EM simulator which I think is a good choice. This paper was about 4 years old so I decide to dig into the specs. They were using a quad core top of the line 3Ghz processor for this. This is fairly nice specs even for today. However, as some might be aware, GPU hardware is advancing much faster as it uses parallelization vs higher frequencies. They tested on this hardware:
Tesla C1060 - 240 Cores @ 1.296GHz
These specs are not very good for todays mid to high range. We could get 2000-2500 cores at a similar clock speed now for only $300 -$400 (maybe even better). Int the paper, they said that the GPU version gave them a 30X boost in speed. In conclusion, I think its not far fetched to say that it may now be closer to a 300X boost in speed on a high end graphics card, assuming also we have some overhead with increased parallelization. This means that something in MEEP that might take a year to simulate may only take a day or so. If we have a multi-card setup, then this could get even faster, perhaps even near the 1000x faster mark with 3 cards linked.
Additionally, I found this program using GPU for FDTD: http://gsvit.net
Unfortunately for me, all my cards are ATI and all these programs use NVIDIA's CUDA language.
- David
A fairly cost effective option if someone does not mind spending a few dollars: Amazon's lower spec (except the GPU) GPU option is .65 cents an hours. This contains a GRID K520 card which is about $4000 dollars. It is a duel GPU unit with a total of over 3000 CUDA cores running at about 800MHZ and 8GB of graphics memory. This would be about 300x faster than MEEPS if the stats stack up correctly.
-
#794 by Rodal on 27 Dec, 2015 01:49
-
A further idea for faster computation is using cylindrical symmetry. Although this constrains the shapes that can be used, initial experiments suggest a 100x speedup.
The geometrical axisymmetry of the frustum of the cone is presently not being exploited. However, assuming full axisymmetry would only produce fully axisymmetric electromagnetic modes. One would not be able to get the TM212 mode that NASA obtains in their experimental measurements for example.
A number of modes are not fully axisymmetric but display m-fold symmetry (where "m" is the first quantum number in TEmnp or TMmnp modes). The following images shows the lowest TEmn and TMmn modes, for arbitrary "p":
Only modes with m=0 are fully axisymmetric (for example TE012) . For m=1 one has to model half of the circular cross-section (and one can impose symmetry on the boundaries). For higher m>1 one has to model "smaller pie slices". So, it looks like one could at least save 50% of the mesh by exploiting axisymmetry
More problematic, it would preclude non-fully axisymmetric modes. To exploit axisymmetry one would have to determine what is the maximum number of poles around the circumference one wants to model: it would effectively set a pre-defined limit on the "m" and "n" quantum numbers that the model could model for TEmnp and TMmnp modes.
This is further complicated by the fact that Meep has revealed asymmetric modes not present in cylindrical cavities. Imposing axysymmetry would get rid of such asymmetric modes. For example, an asymmetric placement of an antenna, or an asymmetric placement of a waveguide can excite asymmetric modes in a real cavity, and it is useful for the designer to know this.
Actually, one of the greatest contributions of Meep analysis has been to make this asymmetric modes evident, and show how difficult it is to achieve axisymmetric resonant modes with antennas. -
#795 by Silversheep2011 on 27 Dec, 2015 01:57
-
Well ...
I feel really stupid today...
and since this thread is read by a large audience, I feel really, really stupid...
When I started with meep I was searching for energy as evanescent waves escaping through the small gaps in the construction of the frustum. As a consequence of the gaps being very small, quite high resolution was needed.
I quit searching for evanescent forces months ago and decreased the resolution modestly but still held the thought that the skin is thin so the resolution needed to be high. It dawned on me finally today that that is bogus.
If we are not concerned with the details of the E&M within the skin beyond the macroscopic model, then it seems to me there is no need to resolve the skin. Meep needs about 10 points per wavelength to resolve the EM fields. Attached is a center slice of a thick skinned Brady cavity at resolution 40. The meep wavelength is ~0.51 units giving ~ 20 points/wavelength. The skin is 1/2 wavelength giving 10 cells across it.
So its not a pretty cavity outline due to granularity and there are likely other issues but this is an approach to the meep run time issue that I should have thought of months ago.
Evaluations please.
Could be helpful
A technique I use for solidification simulation at my work when we run with a million nodes as the norm.
is to do the "roughing out work" on runs with 100,000 nodes size just to get a feel for what's happening thermally and to get some help with the rough sizing and riser placements usually say 90% time it works a charm especially for simple geometries works even better.( and yes, it looks a bit pixelated)
after that a further run or two at the 'million nodes' helps clean up any isolated details [but takes extra long 30 seconds now becomes 10 minutes]
Sometimes where extra detail is needed I will do 5 million nodes and let it run overnight.
As a side note of any interest if this frustum was a casting most of the thermal stress is happening at this lower corner and we would often stipulate an R5 to reduce it [ hot cracking or hot tears being the issues]
-
#796 by ThereIWas3 on 27 Dec, 2015 02:02
-
Do you suppose those asymmetric modes would be stimulated if the injected wave was itself axysymmetric? And would this be a good thing or a bad thing?
-
#797 by OnlyMe on 27 Dec, 2015 02:32
-
Well ...
I feel really stupid today...
and since this thread is read by a large audience, I feel really, really stupid...
When I started with meep I was searching for energy as evanescent waves escaping through the small gaps in the construction of the frustum. As a consequence of the gaps being very small, quite high resolution was needed.
I quit searching for evanescent forces months ago and decreased the resolution modestly but still held the thought that the skin is thin so the resolution needed to be high. It dawned on me finally today that that is bogus.
If we are not concerned with the details of the E&M within the skin beyond the macroscopic model, then it seems to me there is no need to resolve the skin. Meep needs about 10 points per wavelength to resolve the EM fields. Attached is a center slice of a thick skinned Brady cavity at resolution 40. The meep wavelength is ~0.51 units giving ~ 20 points/wavelength. The skin is 1/2 wavelength giving 10 cells across it.
So its not a pretty cavity outline due to granularity and there are likely other issues but this is an approach to the meep run time issue that I should have thought of months ago.
Evaluations please.
Could be helpful
A technique I use for solidification simulation at my work when we run with a million nodes as the norm.
is to do the "roughing out work" on runs with 100,000 nodes size just to get a feel for what's happening thermally and to get some help with the rough sizing and riser placements usually say 90% time it works a charm especially for simple geometries works even better.( and yes, it looks a bit pixelated)
after that a further run or two at the 'million nodes' helps clean up any isolated details [but takes extra long 30 seconds now becomes 10 minutes]
Sometimes where extra detail is needed I will do 5 million nodes and let it run overnight.
As a side note of any interest if this frustum was a casting most of the thermal stress is happening at this lower corner and we would often stipulate an R5 to reduce it [ hot cracking or hot tears being the issues]
It seems most design intent is toward future spherical end plates, which would eliminate the R5 issue at the large end. The small end extends spherically into the frustum... Would the extreme narrowing as the frustum/small endplate meet, eliminate the problem by the excluding resonant waves from reaching the small endplate side wall joint? -
#798 by RFPlumber on 27 Dec, 2015 02:58
-
JFYI, Attached are COMSOL simulations for the frustum (with coax coupling) I am going to build. It is now time for some sheet metal cutting and torch soldering... And then there will be the moment of truth.
D_big: 264 mm
D_small: 158 mm
L_center: 204 mm
TE012 freq: 2,323,xxx kHz COMSOL (vs. 2,402,xxx spreadsheet)
Loaded Q per COMSOL: ~37,000 (Yeah, sure. I wish)
Coupler:
Loop_d: 8 mm
Loop_w2: 8 mm
Loop_alpha: 40-50 degrees
Df: 0.77 (per spreadsheet)
-
#799 by aero on 27 Dec, 2015 04:10
-
Here is the link to Meep symmetries:
http://ab-initio.mit.edu/wiki/index.php/Exploiting_symmetry_in_Meep
My difficulty is understanding the source phasing, and how to do it. To make it work I have resorted to running lower resolution in full 3D, saving the images, then using the good old cut and try technique until the fields calculated with symmetry look the same as the 3D images. Then I feel somewhat confident in my higher resolution symmetric runs. It only works with the source on the z axis though, or maybe mirror symmetry with the source in either the x,z or y,z plane.
As for cylindrical symmetry, as far as I know that only works when the source is axially symmetric, that is, a point source or a dipole lying on the z axis. That is to big a constraint for our problems.
Of course, if cylindrical or spherical coordinates are useful for post processing, the csv file Cartesian coordinates can be transformed mathematically to whatever coordinate system is desired. Transforming the full .h5 file might be a way to identify the boundary of the conic section for those evaluations that need to know the boundary location. With the availability of meep on a virtual machine, (see the em drive wiki, meep section) it is almost trivial to generate your own set of .h5 files, ask VAXHeadRoom about the relative difficulty compared to post processing.
@VAXHeadRoom - I hope that's all right. If not, spank me.
