dsmcFoam+: update dsmcVolFields

[timteichmann]

Hi,
this update should not change any computations. It does change the names of some fields and variables used in the calculation of the macroscopic fields.

• breaking change: rename dsmcRhoN and dsmcRhoNMean to dsmcN and dsmcNMean, also change the unit to 1 instead of 1/m³. This reports the actual number (instantaneous / averaged) of DSMC particles that are in each cell and is therefore no density. Actually, this is wrong even in the upstream official version of dsmcFoam in OpenFOAM(+). This is a breaking change because the IO field name was changed. Therefore e.g. the balanceParDict will have to be adjusted to the changed field name.
• I tried to name all fields that calculate cumulative values in a more streamlined way so that it is easier to follow what the code actually does by appending Cum to those variables
• Additionally, I prepended dsmc to all fields that calculate values based on DSMC parcels vs. fields that calculate values based on the (much larger) number of simulated particles (e.g. dsmcMCum_ vs. mCum_ for the cumulative mass of DSMC parcels vs. the cumulative mass of the "real" gas)
• To make clear what the variables represent I explained them in the section of the code where the actual computations are performed

example:
previous:
const scalar rhoNMean = rhoNMeanXnParticle_[cell] / (nAvTimeSteps*cellVolume);
vs.
const scalar rhoNMean = nCum_[cell] / (nAvTimeSteps*cellVolume);

where in the second case it is directly apparent that a cumulative number is divided by the number of averaging steps over which it was accumulated and the cell volume which results in a density. Whereas in the previous version one would expect (1/m³) / (1 * m³) = 1/(m³*m³) as a unit.

example 2:
previous:
UMean_[cell] = momentumMeanXnParticle_[cell] / rhoMMeanXnParticle_[cell];
vs.
UMean_[cell] = momentumCum_[cell] / mCum_[cell];

where in the second case it is directly clear that both values are cumulative and the resulting value therefore is the mean / average. The unit also becomes much clearer as kg m/s / (kg) = m/s whereas one would expect kg m/s / (kg/m³) = m/s / m³ in the previous version.

Obviously this is just my take on it.

Edit: Note that I did not update the tutorials to the new names (dsmcN(Mean) vs. dsmcRhoN(Mean)) as of yet. However, I would add this to this (or a follow-up) merge request you are willing to merge this.

Edit: Because it makes sense to add this here: This also adds all cumulative values to the readIn and writeOut functions so that averaging across many runs actually works.

[vincentcasseau]

Thank you very much, this was a huge work.

Edit: Note that I did not update the tutorials to the new names (dsmcN(Mean) vs. dsmcRhoN(Mean)) as of yet. However, I would add this to this (or a follow-up) merge request you are willing to merge this.

That would be great!

this update should not change any computations.

This makes me think that the PASS/FAIL test for DSMC cases could be improved. The random seed number number should be fixed for reproducibility. There would then be no need to introduce a tolerance to accommodate statistical scatter. I haven't implemented it because I am afraid users would copy-paste a set-up and thus use a fixed seed without knowing.

[timteichmann]

I will create a pull request for the tutorials in the next few days when I find the time.

On the random seeds: Yeah I also think this would be a good option. However, I also have no idea what would be the best option to implement this safely.. Also every small change to any method involving random numbers would then probably fail the tests, so maybe it is not the perfect solution after all?