Many times I want to create beams, so I just crank up the Cos^N to a high value, but the beam energy profile will still be a distribution according to its temperature. Most of the time that’s fine, but now I wanted to look at modeling the scattering of a 40 keV beam of atomic hydrogen atoms through a background gas, using your new scattering features. But I need to set it to a fixed energy. Is there a back door way I can accomplish this? Also, will I be able to figure out the beam divergence if I use data from the particle logger?
The value is chosen so that it correpsonds to the mean value of the Maxwell-Boltzmann distribution:
v_avg=sqrt(8RT/(PI*m))
And thus the pressure values don’t change.
Incidentally, I discovered a missing square root in some recent versions of Molflow. To use this feature, please use this temporary version (download the artifact for your os), until the fix is published in 2.9.27.
I’m simulating a much higher energy beam going through a background gas, however I realized you don’t take into account the very different velocity distributions between the two. I don’t see where you specify the temperature of the background gas, so you must be using the same velocity distribution of my beam which I gave a Cosine^1E10 and temperature of 5.469E8 K for a the equivalent of a 60KV proton beam. While for the background gas I need it to be Maxwellian at 500K. I only see that you can change mass ratio, but nothing for a velocity distribution difference.
The scattering angle should be small when you transform from the center-of-mass frame into the lab frame because of the high velocity of the beam, but if you are using the same distribution for the background gas it scatters into large angles, which is what I see in my simulation.
I can maybe compensate for this in the mass ratio by also multiplying it by the ratio of the Vbeam/Vgas, but this would only work on average, and I still have no clue as what you use as the distribution…Maxwellian or Cosine^1E10, and temperature of the background gas to know what Vgas value to use.
In our current approximation of background gas, it is considered static, i.e. 0-velocity. Our reasoning is that in reality, you would have different directions (isotropically), therefore velocities should cancel out over a large number of collisions (the vectorial average of many random directions is 0).
If you have a suggestion how to do this better, I’m open. First I thought of randomly generating a direction and velocity to the background gas on each collision, but in that case many “collisions” would in fact not happen - for example if the background gas moves away from the simulated particle.
Conversion between the lab-frame and the center of mass frame can be done as a second step relatively easily.
By the way, in your example the temperature is in the 5E8 range, which we never thought of - the background gas scattering was created for CERN’s cathode sputtering (few thousands of Kelvins max).
I’ve spent quite some time looking into the problem.
You write: “The scattering angle should be small when you transform from the center-of-mass frame into the lab frame because of the high velocity of the beam” - are you sure of this?
I admit I used Claude (similar to ChatGPT) so take these with caution, but I got:
So it seems that the scattering angle, in lab frame or COM frame does not depend on the initial particle speed. This is not intuitive, so I asked about this explicitly:
I’m not a fan of asking AI physics questions and using them as “proof”, so I’m careful to whether it’s true. Yet, I’ve used this web applet to simulate the collision, and in the COM frame the angle is indeed independent of v1 pre-collision velocity.
So I understand that it seems unintuitional that extreme-high speed particles can turn back after a collision, but isn’t it a hard-sphere model flaw instead of a Molflow flaw?
I realized the physics for this high energy beam doesn’t fit the Molflow+ hard sphere model. Its deBroglie wavelength is much much shorter than the Bohr radius so the electron clouds don’t really interact. So the largest elastic scattering process left will be between the charged nuclei which is described by the classic small angle Rutherford scattering. I need to use another code, like CERN’s Geant4 for example. FYI, the deBroglie wavelength = Bohr Radius at 0.293eV (~3400K) for hydrogen. You might want to double check that your cathode sputtering can be modeled as a hard sphere.
As for the rest, you are correct that the scattering angle doesn’t depend on the velocities. Going from the center-of-mass to the lab frame will make the scattering angle smaller. How much depends on the mass ratio, not the velocities.
I’ve also thought about whether it’s valid to assume v=0 (projectile/stationary target model). I never got around to setting up the math to see if the scattering angle after you average over the gaussian background using center-of-mass and relative coordinate systems gives you the same answer as if you took v=0. I think it is easier to either prove/disprove this geometrically by taking symmetric pairs of background gas particles to show how the scattering angle averages out to give you the same scattering angle with v=0…or not.
I started to draw out some geometries on my whiteboard and looking at paired combinations. I’m 60% convinced that it does make a difference for a projectile and gaussian background gas. I think it shifts the distribution of scattering angles from both the large and small angles toward 90 degrees (from the direction of the projectile). I can also see in my drawings how I can recover the extreme cases too. 1) Vprojectile = 0 → background gas scatters uniformly. 2) Vprojectile >>Vgas → standard scattering cross-section described by the hard sphere. 3) if both projectile and gas are gaussian then it produces uniform scattering on average. So I’m 90% convinced now.
So if this is the case you would need to give the background gas a temperature. For each scattering event you would need to generate a random velocity based on the temperature and use that in your scattering calculations rather than assume v=0.
