Rookie
Forum Replies Created
-
Posts
-
Dear Adrian
It’s not terminated, it’s when I turn off parallelism that I get these problems, it outputs the image from step 0 and the simulation doesn’t move, it doesn’t break. Normally gnuplot itself doesn’t have problems due to serial mode. I guess it could be because of this gnuplot problem or the simulation slows down when parallelism is turned off. It could be that gnuplot is not suitable for non-parallel use in this code?
Best Regards,
RookieDear Adrian
Yes, it outputs the image from step 0, and also as you said, this prevents the simulation from continuing. I just want to experiment more with what the code does, so I’d better remove that part of the code then.
Best Regards,
RookieDear Max
I’m having a similar problem, after I add these lines to my code：
vtmWriterStartTime.write(iT);
SuperEuklidNorm3D<T> normVel(velocity);
BlockReduction3D2D<T> planeReduction(normVel, {0, -1, 0}, 600, BlockDataSyncMode::ReduceOnly);
// write output as JPEG
heatmap::write(planeReduction, iT);// write output as JPEG and changing properties
heatmap::plotParam<T> jpeg_Param;
jpeg_Param.name = “velocity”;
jpeg_Param.contourlevel = 5;
jpeg_Param.colour = “blackbody”;
jpeg_Param.zoomOrigin = {0., 0.};
jpeg_Param.zoomExtend = {1., 1.};
heatmap::write(planeReduction, iT, jpeg_Param);if I run it in parallel it runs fine, but if I don’t I get this error:
“./channel/imageData/data/_EuklidNormphysVelocityiT0000000.p” line 21: Matrix does not represent a grid
“./channel/imageData/data/_velocityiT0000000.p” line 27: Natrix does not represent a gridBut the picture for this step is actually output.Is it that the code can only run in parallel?
Best Regards,
RookieDear jan,
Is the method you are talking about using c++ to read the files directly and post-processing, I have tried using Python to process the vtk files before. But I wanted to do more data processing then I chose Paraview to process the data. In parallel fluid is integrating vti file to vtm file and particle is integrating vtu file to pvd file, I was able to make it work after changing the filename issue in the pvd file based on the reported error. Thanks anyway for your continued help.
file=”data/particles_iT1467675iC00007.vtu”/> change into file=”particles_iT1467675iC00007.vtu”/>
Best regards，
RookieI know why this problem occurs, I have to load all the vtu files in this timestep one by one and can’t just load the folder, is there any other way to solve it.
Dear jan,
I’m happy to report that I implemented periodic boundaries for the particles. But I’ve run into another problem which I guess could be the parallel setting. With the old particle system, if I set it to parallel, the fluid would simulate correctly, while the particles would not be generated correctly at the inlet, and in the picture is the difference between whether I use parallel or not. With parallel turned on the particles are only generated and moving in one of the blocks, even with new particle system the particles are only generated in the first block in the bottom right corner.
https://postimg.cc/gallery/vsjHcY9
I switch to the code below in parallel:
CXX := mpic++
PARALLEL_MODE := MPIBest regards，
RookieDear jan,
It is true that this 2 refers to the material, since I chose the channel flow, I assume that setting 1 or 2 will give the same value. There are also some problems in my compiled code. There is no movement of particles after they are generated at the entrance. I guess it may be caused by too many settings I changed at one time.I am using stokes drag and periodic boundaries first to verify that periodicity is correct.
Best regards，
RookieDear jan,
Are you talking about the selection of materials in compilable code? The periodic boundary does not select materials, because I see in the source code he is judged according to geometry, and the material has nothing to do with it. I set up the particles to bounce with the wall, where I set up material 2.
T dT = converter.getConversionFactorTime();
std::set<int> reflBMat = {2};
auto materialreflectBoundary = std::make_shared<SimpleReflectBoundary3D<T, PARTICLE>>(dT, superGeometry, reflBMat);
supParticleSystem.addBoundary(materialreflectBoundary);auto materialperiodicBoundary = std::make_shared
< PeriodicBoundary3D<T, PARTICLE>
> (superGeometry, true, true, false);
supParticleSystem.addBoundary(materialperiodicBoundary);My fluid is periodic in both the x and y directions, are you worried that my fluid is not periodic? Because the results haven’t come yet, and I’ll be the first to let you know if I succeed.
Best regards，
Rookie
