Limitation/Bug in the Density Calculation

[alan (Dr Alan Van Drie)]

I accidentally ran a simulation overnight, so I was expecting a very smooth density profile along a transparent facet I had running down the length of an azimuthal symmetric tube. The gas is very Maxwellian. I got two big bumps in the curve.

compared to the raw hits

So obviously this means a single hit will a Vperp = very very very close to zero at that location had a very large outsized contribution to the density calculated at that point. The problem in general is you can’t calculate the density on a flat surface of particles trajectories parallel to that surface, it’s impossible. Unlike a PIC simulation which has a volume you don’t have this limitation. There should be cutoff on how large a 1/Vperp is allowed, which would throw out those particles with trajectories that are too parallel for the calculation to be valid. This would not be an absolute value since who knows what temperature and distribution of gasses someone is using, but rather a flexible one that would look at the distribution and throw out those that are in the 1% or 0.1% of the tail for example. I bet a cutoff with a much much smaller % than that would have thrown out these trajectories for this Maxiallian gas . If I had a more beam-like gas flowing down the tube, then I think I would have many more such outsized events, but knowing the limitations of calculating density on flat surfaces I would have never used an analysis facet for density in that orientation for a beam-like gas.

So I wouldn’t really call this a bug, it’s just a limitation of flat surfaces. However, I think a distribution tail cut-off scheme could fix the problem. If keeping track of the distribution is not possible then maybe comparing the particle’s Vperp to V and doing a relative velocity cutoff is an easier way to do this.

Cheers,
Alan

[maarton (Marton Ady)]

Yes, this problem is known, and maybe it’s even easier to demonstrate with textures.

A simple pipe’s pressure texture, nice and smooth:

Now switching to density for the exact same simulation state:

Even the autoscaling is off, because of a few texture cells with high values:

Your analysis is correct, it’s the near-parallel hits that give an “infinite” contribution to the density value. I already do filtering in Molflow for texture autoscaling, to filter out tiny cells (compared to the full rectangles), so your filtering idea - this time for denisty - seems good - of course I have to check edge cases, for example calculating density on a facet parallel to a jet. I’ll do a bit of tinkering and will try to make a filter that rejects outliers but doesn’t affect overall density values.

Thanks for the suggestion, Marton

[alan (Dr Alan Van Drie)]

I’ll go back into my notes and see if I can derive a reasonable cut off. The density calculation depends on the time spend in box of volume Facet Area x thickness D, where D goes to zero. For a pure parallel trajectory the time is limited by the not by D/Vperp anymore but by ~(Area)^0.5/Vpara. I think this is probably the starting point, but I need to go back and look at my notes to make sure the other 1/D term which cancels out this D is not a problem.

Is it possible to get the distribution data of n, Vperp or 1/Vperp? I’ve never tried this as I though you get some limited number or do you just keep a running average?

Best,
Alan