Dear All,
I am trying to "put together" automatically all the "processor" folders (from "processor 0" to "processor 576" in /home/....../CFD) in order to have just one folder to open in Paraview and see all my simulation data together....... I am following the instructions of Paul (Wed, 03/14/2018 - 12:57) from a previous post: https://www.cfdem.com/forums/paraview-visualization-hpc-simulation-modif...
Which means trying to use:
- This command
- reconstructPar
- Or alternatively this ones
-
touch case.foam
paraview case.foam
and use the Case Type Decomposed Case.
Both do not work now, and especially for the reconstructPar command I get the message here after reported.... Any idea/suggestion on how to fix this issue ?
Best regards,
Limone
[user@user_limone CFD]$ reconstructPar
/*---------------------------------------------------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: 3.0.x |
| \\ / A nd | Web: www.OpenFOAM.org |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
Build : 3.0.x-ac3f6c67e02f
Exec : reconstructPar
Date : Jun 04 2018
Time : 13:13:45
Host : ".........................."
PID : 138674
Case : /data/......................../CFD
nProcs : 1
sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster
allowSystemOperations : Allowing user-supplied system call operations
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time
Reconstructing fields for mesh region0
Time = 0.01
Reconstructing FV fields
Reconstructing volScalarFields
p
Ksl
voidfraction
rho
Reconstructing volVectorFields
stored_U
Us
U
Reconstructing surfaceScalarFields
phi
Reconstructing point fields
No point fields
Reconstructing lagrangian fields for cloud particleCloud
--> FOAM FATAL ERROR:
cell, tetFace and tetPt search failure at position (-0.0464913 -0.0207366 0.0302518)
for requested cell 0
If this is a restart or reconstruction/decomposition etc. it is likely that the write precision is not sufficient.
Either increase 'writePrecision' or set 'writeFormat' to 'binary'
From function void Foam::particle::initCellFacePt()
in file /home/appuser/OpenFOAM/OpenFOAM-3.0.x/src/lagrangian/basic/lnInclude/particleI.H at line 735.
FOAM aborting
#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::error::abort() at ??:?
#2 Foam::reconstructLagrangianPositions(Foam::polyMesh const&, Foam::word const&, Foam::PtrList const&, Foam::PtrList > const&, Foam::PtrList > const&) at ??:?
#3 ? at ??:?
#4 __libc_start_main in "/lib64/libc.so.6"
#5 ? at ??:?
Aborted (core dumped)
paul | Tue, 06/05/2018 - 08:24
The IOModel is broken in
The IOModel is broken in CFDEMcoupling. Try one of the following things:
a) Not reconstruct the lagrangian data from OpenFOAM.
reconstructPar -noLagrangian
and instead use vtk dumps from LIGGGHTS, preferably with dump_modify dumpname binary yes to write binary dumps.
In this case, just disable outputting lagrangian data in the OpenFOAM time directories by setting IOModel off; in constant/couplingProperties.
b) Write binary files in OpenFOAM. This reduces the data generated by a simulation by about 2/3 in my experience.
writeFormat binary; in system/controlDict
Min Zhang | Fri, 06/15/2018 - 20:27
Hello Paul,
Hello Paul,
I am very interested in this post since I am keeping having this reconstruct problem... Not only for the CFDEMcoupling simulations, but also for the PURE OpenFOAM simulations.
In my case, for a single simulation case, for some time steps, it has this reconstruct problem, but for some time steps, it doesn't.
(1) I am wondering what is the substantial reason for this?
(2) What do you mean by IOModel is broken?
(3) According to your suggestions, I should do the following things:
(a) In the CFD (OpenFOAM) side:
writeFormat binary; in CFD/system/controlDict -------> which is to reduce the simulation data.
IOModel off; in CFD/constant/couplingProperties -------> which is also to reduce the simulation data since the particle properties data has been output by the DEM side.
(d) In the DEM (LIGGGHTS) side:
dump_modify dumpname binary yes -------> which is also to reduce the simulation data.
Is it correct?
Thanks and best regards,
Min
limone | Tue, 06/05/2018 - 16:17
reconstructPar
Thanks a lot Paul!
I did not understand two small things:
(a.1) By using "vtk dumps from LIGGGHTS, preferably with dump_modify dumpname binary yes",
dump dmp all custom/vtk 1000 ../DEM/post/dump_liggghts_run.*.vtk id type type x y z ix iy iz vx vy vz fx fy fz omegax omegay omegaz radius
dump_modify dmpvtk binary yes
(a.2) If I use "dump_modify" as in (a.1), should I also disable the IOModel with "IOModel off; in constant/couplingProperties" ?
In other words should I use/apply (a.1) and (a.2) together ?
(b) I followed your advice and a simulation is running with the following setting (fingers crossed then..):
application cfdemSolverPiso;
startFrom startTime;
startTime 0;
stopAt endTime;
endTime 5;
deltaT 0.0005;
writeControl adjustableRunTime;
writeInterval 0.01;
purgeWrite 0;
// writeFormat ascii;
writeFormat binary;
writePrecision 6;
writeCompression uncompressed;
timeFormat general;
timePrecision 6;
runTimeModifiable yes;
adjustTimeStep no;
maxCo 0.1;
Best regards,
Limone
paul | Wed, 06/06/2018 - 08:18
a.1 you named your dump dmp,
a.1 you named your dump dmp, so the dump_modify should be
dump_modify dmp binary yes
a.2 the dump_modify is optional and reduces a lot. IOModel off; merely says, that the particle info should not be written into the OpenFOAM time directories as well; this would be just duplication of information, which is already written by LIGGGHTS in the form of a dump.
-> yes do both :)
b) looks good to me.