Hi,
When running the periodic channel tutorial I encounter some issues which sounds quite peculiar. I’ve attached the complete log file but here just point out the issues:
1) On line 277 of the log, it’s written
--> FOAM Warning : Periodic handing is disabled because the domain is not fully periodic!
How can this be!!!
2) In solving the flow field, prior to each pressure solve, I get the following:
Pressure gradient source: uncorrected Ubar = 0, pressure gradient = 9054.97
--> FOAM Warning : Pressure gradient force is neglected in this model!!
Again I cannot really get this, so it means that the pressure grad force in model A is not computed, which then doesn’t make sense. On a side-note, where does Ubar come from?
3) On line 262, it goes over the switches for the dragforce, in which the treatForceDEM is set to false (default), but then a few lines later we get Using treatForceDEM true?
looking for treatForceDEM ...
treatForceDEM = false
looking for interpolation ...
interpolation = true
looking for scalarViscosity ...
scalarViscosity = false
Using treatForceDEM true!
4) a rather unimportant one is the mismatch warning I get between restart file version and LIGGGTS version on line 100? I recompiled the whole liggghts and cfdem with the latest releases, but still get this:
WARNING: Restart file version does not match LIGGGHTS version
Would appreciate it your input on this.
Best,
Ali
| Attachment | Size |
|---|---|
 periodicchannel_logfile.txt | 51.74 KB |
AliBlues | Wed, 02/22/2017 - 14:44
STRANGE ISSUES CONCERNING PERIODICCHANNEL TUTORIAL
Would appreciate it your input on this. Thank you.
alice | Wed, 02/22/2017 - 16:21
Hi Ali,
Hi Ali,
here are some answers to your questions:
@ 1: this warning can be ignored in this case, it is a left-over from another case, but has no effect here.
@ 2: as the pressure drop due to the channel flow is not part of the pressure field p (if you have a look at the pressure field in paraview you'll see that it does not drop over channel length) but considered as separate term, the calculation of the pressure gradient force (which is based on the field p) cannot consider it as well. Pressure gradients that do not occur due to the channel flow are still considered.
The Ubar is the average flow velcocity in stream direction and 0 for the first time step (it increases later on).
@3: If you have a look at the force models for pressureGradient and viscous force, you'll see that treatForceDEM is always set true for model A. (i.e. the flag is changed afterwards)
@ 4: did you compile the latest version of LIGGGHTS as library, and before recompiling CFDEMcoupling? (cfdemCompLIG or cfdemCompCFDEMall if you want to make sure that everything is compiled accordingly). In case you compile LIGGGHTS using make auto (or another makefile name) you only create the application which is used when you run LIGGGHTS "stand alone", the library which is included by CFDEMcoupling remains the old one.
Best regards,
Alice
AliBlues | Mon, 04/24/2017 - 10:30
Null inlet & outlet Faces!
Hi,
In the periodic channel tutorial, if I increase the number of processors to 12, so in decomposeParDict set n in simpleCoeffs to (2 2 3), and appropriately change the processor number to 12 in parDEMrun.sh and parCFDEMrun.sh (and perhaps not so important comment out "processor 2 2 1 " in DEM/in.liggghts_resume) , and run cfdemSolverPiso, I get the following warning for inlet and outlet faces:
--> FOAM Warning :
From function Foam::fieldValues::faceSource::initialise(const dictionary&)
in file fieldValues/faceSource/faceSource.C at line 437
faceSource volFlow_inlet: patch(inlet):
Source has no faces - deactivating
--> FOAM Warning :
From function Foam::fieldValues::faceSource::initialise(const dictionary&)
in file fieldValues/faceSource/faceSource.C at line 437
faceSource volFlow_outlet: patch(outlet):
Source has no faces - deactivating
faceSource volFlow_wall:
total faces = 1024
total area = 0.16
while it works fine for the wall. Now if run checkMesh in parallel, i get:
Checking basic patch addressing...
Patch Faces Points
wall 1024 1296
outlet 0 0
inlet 0 0
which is not the case for 4 processors:
Checking basic patch addressing...
Patch Faces Points
wall 1024 1254
outlet 64 108
inlet 64 108
There seems to be a bug perhaps not in CFDEM but inherent to OpenFOAM. Anyway to resolve this issue?
Thank you for your time.
Ali
AliBlues | Thu, 05/11/2017 - 12:40
NULL INLET & OUTLET FACES!
I would greatly appreciate a reply. Thanks for your time.
Best
Ali
j-kerbl | Thu, 05/11/2017 - 18:24
Hi Ali,
Hi Ali,
I tried to reproduce the error, but I couldn't.
I'd suggest you try a non-scripted step-by-step approach to this and start off with a fresh blockMesh. Next I'd check if decomposePar works properly.
Probably there is some kind of mix-up in your case, so it is best to run everything bit by bit with careful checking of all log files.
Cheers,
Josef
AliBlues | Mon, 05/29/2017 - 11:47
NULL INLET & OUTLET FACES!
Hi Josef,
Thank you for the reply. The issue still persists, and seems to be from OpenFOAM. If for now we forget about any coupling, and go to the CFD directory and run in the terminal:
>blockMesh
>decomposePar
>mpirun -np 4 checkMesh -parallel
Then output is :
Checking basic patch addressing...
Patch Faces Points
wall 1024 1254
outlet 64 108
inlet 64 108
Now, if I increase the number of processors to 12, so in decomposeParDict, change numberOfSubdomains to 12, and set n in simpleCoeffs to (2 2 3), and then running :
>decomposePar
>mpirun -np 12 checkMesh -parallel
then the output is
Checking basic patch addressing...
Patch Faces Points
wall 1024 1296
outlet 0 0
inlet 0 0
Which is strange. I checked this with the installation of other colleagues, and get the same result. I hope if you try this, you will get the same result. If so, then would you know what might be the reason. The strange thing is I don't get any errors while running simulations?!
Best
Ali