2018-08-19 20:29 BST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0002837OpenFOAM[All Projects] Bugpublic2018-02-12 10:27
Reportereaxan3 
Assigned Towill 
PrioritynormalSeveritymajorReproducibilityalways
StatusresolvedResolutionfixed 
PlatformGNU/LinuxOSUbuntuOS Version15.04
Product Version5.0 
Target VersionFixed in Versiondev 
Summary0002837: Lagrangian Particles - Incorrect amount of mass still being injected if parcelsPerSecond 'too large'
DescriptionHi

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 ReproduceDue 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 InformationI 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.
TagsLagrangian, particle tracking, sprayFoam
Attached Files
  • ? file icon sprayCloudProperties (3,644 bytes) 2018-02-08 13:13 -
    /*--------------------------------*- 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
    {}
    
    
    // ************************************************************************* //
    
    ? file icon sprayCloudProperties (3,644 bytes) 2018-02-08 13:13 +
  • png file icon before.png (197,705 bytes) 2018-02-12 10:26 -
    png file icon before.png (197,705 bytes) 2018-02-12 10:26 +
  • png file icon after.png (263,784 bytes) 2018-02-12 10:26

-Relationships
+Relationships

-Notes

~0009286

will (manager)

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?

~0009287

eaxan3 (reporter)

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?

~0009292

will (manager)

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?

~0009296

eaxan3 (reporter)

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.

~0009298

eaxan3 (reporter)

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

~0009302

will (manager)

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.
+Notes

-Issue History
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
+Issue History