View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0002837 | OpenFOAM | Bug | public | 2018-02-08 13:13 | 2018-02-12 10:27 |
Reporter | eaxan3 | Assigned To | will | ||
Priority | normal | Severity | major | Reproducibility | always |
Status | resolved | Resolution | fixed | ||
Platform | GNU/Linux | OS | Ubuntu | OS Version | 15.04 |
Fixed in Version | dev | ||||
Summary | 0002837: Lagrangian Particles - Incorrect amount of mass still being injected if parcelsPerSecond 'too large' | ||||
Description | Hi I'm trying to reproduce an experimental case, that I've been able to setup within Fluent and get decent results - however I would like to simulate this case using OF. The case is a simple rectangular duct with a cross flow of 90 m/s with particles being injected to form a film. I have a fixed flowrate (hence massTotal) and a fixed RosinRammler size distribution that I need to follow. Ideally for this case (based on Fluent simulations) I need to inject roughly 10 million parcels per second. If I use 10 million parcelsPerSecond, a huge amount of the distribution is not injected due to the variable nP (in InjectionModel.C) being below 1. To fix this I have to reduce the parcelsPerSecond to approximately 100,000 - this severely limits the accuracy of the solution as the interaction with the flow field is not captured. For example my RosinRammler distribution covers particle diameters from 1e-05 m to 2.7e-4 m, with the reduced no. of parcels per second I can capture this distribution. However at 10 million parcels per second the largest diameter injected is approx 1.4e-4 m - and half of the distribution is not injected. | ||||
Steps To Reproduce | Due to my large case files I cant upload these here, however I have run a test case using the aachenBomb tutorial, where I have modified the sprayCloudProperites to match my injection characteristics. This sort of demonstrates the problem Run the aachenBomb tutorial case as normal, just replace the sprayCloudProperites with attached. Note: you dont need to run for as long in the tutorial, only 0.001s flow time is really needed | ||||
Additional Information | I understand that this bug has been flagged before and was fixed, although I have noticed other forum users encountering similar problems too. However the 'fix' seems to be reducing the no. of parcels per second. | ||||
Tags | Lagrangian, particle tracking, sprayFoam | ||||
|
sprayCloudProperties (3,644 bytes)
/*--------------------------------*- C++ -*----------------------------------*\ | ========= | | | \\ / F ield | OpenFOAM: The Open Source CFD Toolbox | | \\ / O peration | Version: 5 | | \\ / A nd | Web: www.OpenFOAM.org | | \\/ M anipulation | | \*---------------------------------------------------------------------------*/ FoamFile { version 2.0; format binary; class dictionary; location "constant"; object SprayCloudProperties; } // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // solution { active true; coupled true; transient yes; cellValueSourceCorrection on; maxCo 0.3; sourceTerms { schemes { rho explicit 1; U explicit 1; Yi explicit 1; h explicit 1; radiation explicit 1; } } interpolationSchemes { rho cell; U cellPoint; thermo:mu cell; T cell; Cp cell; kappa cell; p cell; } integrationSchemes { U Euler; T analytical; } } constantProperties { T0 300; // place holders for rho0 and Cp0 // - reset from liquid properties using T0 rho0 780; Cp0 4187; constantVolume false; } subModels { particleForces { sphereDrag; } injectionModels { model1 { type coneNozzleInjection; SOI 0.0; duration 1; massTotal 0.001945; parcelBasisType mass; injectionMethod disc; flowType flowRateAndDischarge; outerDiameter 0.0005; innerDiameter 0; position (0 0.0995 0); direction (0 -1 0); parcelsPerSecond 1e+05;// Change to 1e+07 for second case! flowRateProfile table ( (0 0.001945) (1.000000 0.001945) (1.000001 0.0000) (1000 0.0000) ); Cd constant 0.9; thetaInner constant 0.0; thetaOuter constant 10.0; sizeDistribution { type massRosinRammler; massRosinRammlerDistribution { minValue 1e-5; maxValue 2.7276e-4; d 1.4965e-4; n 3.7559; } } } } dispersionModel none; patchInteractionModel standardWallInteraction; heatTransferModel none; compositionModel singlePhaseMixture; phaseChangeModel none; surfaceFilmModel none; atomizationModel none; breakupModel none; // ReitzKHRT; stochasticCollisionModel none; radiation off; standardWallInteractionCoeffs { type rebound; } singlePhaseMixtureCoeffs { phases ( liquid { C7H16 1; } ); } } cloudFunctions {} // ************************************************************************* // |
|
Your injection setup specifies a number of parcels larger than the number of physical particles. The code, as it stands, does not permit a parcel to represent less than one particle (presumably this is considered unphysical). These two requirements are contradictory. How do you suggest that this is resolved? |
|
Yes I agree with you and understand that this is true, I was wondering I guess if there is a fix around this at all or whether this is just how OF tackles Lagrangian injections. I know what Fluent does (and StarCCM although I'm not 100%), is that where you have a fraction of a particle in one parcel (ie nP = 0.5), then two parcels will be injected to make nP = 1. Although I'll be honest I cant figure out how those parcels are then tracked etc. I guess the point is that Fluent permits parcels with less than one particle. I've noticed that there's the delayedVolume written into the InjectionModel.C and I thought this may be a solution to this, although modifying this doesn't seem to affect the end result? |
|
No, delayed volume doesn't fix this. All it does is store how much hasn't been injected so that future time-steps can recover by injecting more. It ensures the correct amount of mass, but invariably, the future time-steps recover the delayed volume by injecting smaller diameters, so it wrecks the distribution. If nP is 0.5, then doubling the number of parcels will result in nP = 0.25. I don't know why we don't permit parcels with less than one particle. Have you tried removing the restriction? At about line 505 of InjectionModel.C, replace "if (pPtr->nParticle() >= 1.0)" with "if (true)". Does it run as you would expect then? |
|
Sorry I didn't explain that clearly. nP changes based on the diameter of the particle right? So for larger diameter particles nP reduces and for smaller diameter particles nP increases. nP is essentially the ratio of the average volume each parcel can hold, divided by the volume of the particle being injected What I was trying to explain was that for a given particle, if nP = 0.5, then one parcel would only represent 0.5 of a particle. Which OF cant do. For this given particle, you could then represent it, if you have a separate step where you create an additional parcel. So that just this one particle is then represented by 2 parcels - that are coupled together. Sort of like a child parcel for it. Not simply just doubling your total no. of parcels per second. To answer your second question, I tried previously replacing the code (although not with what you said). I didn't have any success. I will try again with what you stated. |
|
I went and ran a case, replacing the if statement with "if (true)" and the results are still the same whereby the particles still dont get injected however the incrementers such as no of parcels added still go up - which is as expected I guess |
|
|
|
|
|
I'm afraid I don't understand your explanation. I can't see how a child parcel helps. Adding another parcel will always reduce nP. We need to increase it if the lower limit of 1 is to be maintained. If you wish to convince me, I think you will have to contribute an implementation. In any case, I think the lower limit is probably unnecessary. If we consider the parcels to be a statistical approximation of the particulate flow, then it might be reasonable to want to simulate more elements than there are physical particles. Removing the restriction fixes the problem for me. Attached are some before and after images of the distribution in the modified aachen bomb tutorial, after 0.001 s. As an added benefit, this change means that the delayed volume handling is no longer necessary. I've pushed the change to dev as commit 1a7a489c7. |
Date Modified | Username | Field | Change |
---|---|---|---|
2018-02-08 13:13 | eaxan3 | New Issue | |
2018-02-08 13:13 | eaxan3 | File Added: sprayCloudProperties | |
2018-02-08 13:13 | eaxan3 | Tag Attached: Lagrangian | |
2018-02-08 13:13 | eaxan3 | Tag Attached: particle tracking | |
2018-02-08 13:13 | eaxan3 | Tag Attached: sprayFoam | |
2018-02-08 15:56 | will | Note Added: 0009286 | |
2018-02-08 16:43 | eaxan3 | Note Added: 0009287 | |
2018-02-09 15:04 | will | Note Added: 0009292 | |
2018-02-09 17:03 | eaxan3 | Note Added: 0009296 | |
2018-02-10 11:17 | eaxan3 | Note Added: 0009298 | |
2018-02-12 10:26 | will | File Added: before.png | |
2018-02-12 10:26 | will | File Added: after.png | |
2018-02-12 10:27 | will | Assigned To | => will |
2018-02-12 10:27 | will | Status | new => resolved |
2018-02-12 10:27 | will | Resolution | open => fixed |
2018-02-12 10:27 | will | Fixed in Version | => dev |
2018-02-12 10:27 | will | Note Added: 0009302 |