It seems to me if you set the mass of background collisional gas equal to the simulated particle’s mass, then you can simulated self scattering of the simulated particles so along as you give a mean free path consistent with the gas density after scattering.
However, you can only give one background gas for the entire simulation which limits the usefulness of this new feature. If you could set the background gas per structure for example, then one can set up a geometry where the density changes over a volume. For example, I need to simulated transitional flow along simple round pipe that exits into a vacuum. Divide the length of pipe into 10 structures each with its own collisional length. Starting with the collisionless density to calculate the inital mean free path, and then loop through simulations to recalculate the new density until the simulation converges to a consistent density profile.
Thank you for the feedback, indeed a mass ratio of 1 is equivalent to self-scattering.
We were contacted by an other commercial player who might be interested in a per-structure background gas feature. Let us get back about this in a few weeks.
The automatic updating of densities across simulations (in short, iterative simulations) is very hard to integrate so would need to be done manually, at least first.
I just assume the iterative step would be done as call to the CLI inside a script, not as a built in feature. You could also do this as a “collisional” facet, which would be equivalent to a scattering path inside a structure, which is bound by facets going from one structure to another. In either case if you want an accurate model, you need the gap between facets to be less than n/grad(n)
Probably the feature would be a list of structures, each allowing scattering on/off and with individual free path and mass parameters. I’ll think it over, thanks for the suggestion.
Hello, Marton,
Currently, the background gas is static, right? Wouldn’t self-collisions need to take into account the gas temperature? My understanding is that, currently, a high number of collisions eventually reduces the particle’s speed as it transfers some of its momentum to the background gas, while self-collisions would on average tend to maintain a consistent temperature. Is it possible to give a certain temperature to the background gas, and would it change anything?
right now there no temperature to be set directly for the background gas: the input data in the collision menu asks for a pre-calculated mean-free path, so temperature goes into that via the usual MFP formula. Anyway, this is just an initial try to model sputtering of Nb on Cu cavities, not necessarily a perfect way to do it, certainly not to replace more precise DSMC calculations. When finalized (and validated by comparison to measured data) it will give a way to compare different sputtering deposition configurations, with the final, detailed analysis carried out via other dedicated software.
Some users may find it useful in order to model different physical devices, I’m not restricting this to PVD.
Currently, at every collision, MolFlow calculates the new angle and velocity of the simulated particle. It indeed assumes that the background gas is static.
I made a graphical calculator demonstrator to see the new angle (in purple) and new velocity (in light blue). The X axis is the “collision parameter”, 0 would be head-on collision and 1 would be at a distance of r1+r2 (barely slipping off the side of the target)
The m slider adjusts the mass ratio (simulated gas / background)
As we can see from the light blue curve, you’re right, a molecule can only lose speed, that’s why eventually it’s destroyed when it reaches the cutoff velocity (it enters a random Brownian motion).
It would be nice to extend the model from the current “obstacle course” to a real intermolecular simulator. However, I have a lot of questions, that would need investigating:
From the perspective of a flying particle, how often is it hit by the background gas?
Are faster background gas velocities overrepresented in collisions? In case of wall collisions, they are - fast particles hit the side of a box more often than slow ones.
What is the direction? Is it uniformly random, or again, is it overrepresented by particles coming heads on?
As Roberto mentioned, adding this feature was to enable sputtering simulations, where the working gas is much faster than the background. If you have insights or you think the theory of intermolecular collisions is well explained somewhere, I welcome your input. As long as collisions can be simulated statistically, without partitioning the volume to small cells, anything can be added to MolFlow.
Yeah, there are definitely a lot of questions to answer. Some of them have already been answered, notably using kinetic theory of gases. The fastest background molecules going in the opposite direction from the considered test particle would definitely be more represented, while those moving in the same direction. Basically, it’s like the test particle checks collision independently with every dv_x,dv_y,dv_z in the background gas, with the differential collision frequency being proportional to \vect(v_p-v_g). So yeah, the collision frequency is a weird integral of the form \iiint d\theta dv d\phi v^2 sin(\theta) exp(-v^2) V_rel, with V_rel=v_p^2+v^2-vv_pcos(\theta), where v_p is the test particle speed and \theta the possible angles between it and the colliding particle’s propagation.
That part at least was integrated before, see for example https://ntrs.nasa.gov/api/citations/19670007224/downloads/19670007224.pdf
which gives (p8) a formula for the collision frequency between gases with different temperatures and drift velocities (take n1=1 and T1=0 to have a single particle with a given velocity).
More visually, the probability for the particle to hit a background molecule with a given speed is proportional to said speed in the particle’s frame. Below is a graph (red on the color wheel corresponds to molecules going in the same direction as the test-particle and cyan for molecules coming head-on). The dashed circles have the same relative velocity, and as such the same interaction probability.
I fear the problem would be to assign probabilities to each possible background velocity for each collision, which might slow dramatically the simulation (I don’t really know how much, but that seems like something that would take some computational power).
I hope this can help you at least a bit, and thank you for your fantastic work.
Jeremy
