View Issue Details

IDProjectCategoryView StatusLast Update
0002265OpenFOAMContributionpublic2016-10-05 17:11
Reportervikramaditya91 Assigned Tohenry  
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
PlatformGNU/LinuxOSOpenSuSEOS Version12.3
Summary0002265: icoUncoupledKineticParcelFoam does not work with SRFForce
DescriptionI have two errors to report in the icoUncoupledKineticParcelFoam usage with fluid flow results from SRFPimpleFoam.

1) When the icoUncoupledKineticParcelFoam is used with the SRFForce in the constant/kinematicCloudProperties file, one gets the error

    request for SRFModel SRFProperties from objectRegistry region0 failed
    available objects of type SRFModel are

this can be corrected by adding these lines in the createFields.H file, with an if condition to activate only if the SRFForce is turned on

    Info<< "Creating SRF model\n" << endl;
    autoPtr<SRF::SRFModel> SRF(SRF::SRFModel::New(Urel));


2) The icoUncoupledKineticParcelFoam does not work with the flow-field from SRFPimpleFoam (rotating frames of reference). The problem arises because one is observing from a rotating frame of reference. The solver should read Urel instead of U in the createFields.H file because the drag should be calculated as the speed of the particle relative to the fluid which is : Urel(particle) -Urel (fluid) and not as Urel(particle)-U(fluid). The latter is currently happening, so I suggest to make these changes in the createFields.H file:
a) to read Urel instead of U
    Info<< "Reading field Urel\n" << endl;
    volVectorField Urel
    (
    IOobject
    (
    "Urel",
    runTime.timeName(),
    mesh,
    IOobject::IF_PRESENT,
    IOobject::NO_WRITE
    ),
    mesh
    );

b) When it is constructing the kinematic cloud, to read Urel and not U.
I suggest changing all other places from U to Urel in the createsField.H file as well, but this is critical in my opinion:
    Info<< "Constructing kinematicCloud " << kinematicCloudName << endl;
    basicKinematicCollidingCloud kinematicCloud
    (
    kinematicCloudName,
    rhoInf,
    Urel, //changed from U to Urel
    mu,
    g
    );
    
Steps To ReproduceThe case I have attached does not have the fluid flow results. Run SRFPimpleFoam upto 0.1 second and then I suggest running icoUncoupledKineticParcelFoam on it. You will get the error I have mentioned in 1.

To demonstrate the problem I mentioned in 2, I suggest you turn off all other forces and only keep sphericalDrag on in the kinematicCloudProperties file. You would see that the particles follow U and not Urel.
Additional InformationI had read that the NonIntertialFrame does not work very well either. Have not investigated into it.
TagsicoUncoupledKineticParcelFoam, Lagrangian, SRFForce

Activities

vikramaditya91

2016-09-23 12:45

reporter  

rotor2D_trial2.tar (768,000 bytes)

henry

2016-09-23 14:23

manager   ~0006914

icoUncoupledKineticParcelFoam is not an SRF solver but you can create an SRF version if you wish. It would probably be easier to use MRF which is supported and sufficient for most purposes.

vikramaditya91

2016-10-05 17:04

reporter   ~0006964

As suggested, I made an SRF version of the icoUncoupledKineticParcelFoam solver and placed them in a github repository at

https://github.com/vikramaditya91/OpenFOAMVik/tree/master/myScripts/icoUncoupledKinematicParcelSRFFoam

Thanks

Issue History

Date Modified Username Field Change
2016-09-23 12:45 vikramaditya91 New Issue
2016-09-23 12:45 vikramaditya91 File Added: rotor2D_trial2.tar
2016-09-23 12:45 vikramaditya91 Tag Attached: Lagrangian
2016-09-23 12:45 vikramaditya91 Tag Attached: icoUncoupledKineticParcelFoam
2016-09-23 12:45 vikramaditya91 Tag Attached: SRFForce
2016-09-23 14:23 henry Assigned To => henry
2016-09-23 14:23 henry Status new => closed
2016-09-23 14:23 henry Resolution open => no change required
2016-09-23 14:23 henry Note Added: 0006914
2016-10-05 17:04 vikramaditya91 Status closed => feedback
2016-10-05 17:04 vikramaditya91 Resolution no change required => reopened
2016-10-05 17:04 vikramaditya91 Note Added: 0006964
2016-10-05 17:11 henry Status feedback => resolved
2016-10-05 17:11 henry Resolution reopened => fixed