View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0002265 | OpenFOAM | Contribution | public | 2016-09-23 12:45 | 2016-10-05 17:11 |
Reporter | vikramaditya91 | Assigned To | henry | ||
Priority | normal | Severity | minor | Reproducibility | always |
Status | resolved | Resolution | fixed | ||
Platform | GNU/Linux | OS | OpenSuSE | OS Version | 12.3 |
Summary | 0002265: icoUncoupledKineticParcelFoam does not work with SRFForce | ||||
Description | I 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 Reproduce | The 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 Information | I had read that the NonIntertialFrame does not work very well either. Have not investigated into it. | ||||
Tags | icoUncoupledKineticParcelFoam, Lagrangian, SRFForce | ||||
|
|
|
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. |
|
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 |
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 |