dump2vtk for cyclic boundaries

Asked by Kahlil Fredrick Cui on 2018-06-23

I would just like to raise a question on the vtk file generation using dum2vtk when using cyclic boundaries. It seems that the number of particles detected and indicated in the vtk files are fewer than the actual particles in the checkpointer files. They also become progressively lower in the succeeding vtk files. As a result, when I use paraView, the number of particles displayed are also fewer and some disappear as the animation progresses. Maybe dum2vtk only reads one of the checkpointer files? If so is there an additional call or command that i need to implement to fix this?

Just to be clear, I implement dump2vtk as follows: dump2vtk -i <checkpointer> -o <outfile> -rot -t 0 1000 1000 and I am using Esys 2.3.2.

Thank you for your time!

Question information

Language:
English Edit question
Status:
Solved
For:
ESyS-Particle Edit question
Assignee:
No assignee Edit question
Solved by:
Kahlil Fredrick Cui
Solved:
2018-07-12
Last query:
2018-07-12
Last reply:
2018-06-27
SteffenAbe (s-abe) said : #1

Particles disappearing from a simulation can happen (particles moving outside the computational domain), but normally the number of particles in the produced vtk _should_ be the same as in the dump files.
How big are your dump files? And can you upload 2 or 3 time steps somewhere so I can have a look at them?

Steffen

Hello Steffen,

Thanks for answering. I did read in the tutorials that dump2vtk should be able to stitch together data from 2 check pointers, which is why I really don't understand what's happening. I also noticed this happen to non-cyclic boundary simulations. For this particular simulation, I only have 3541 particles. The very first vtu files only register 2400 particles. At the very end the vtu files register only 836 particles.

I have uploaded some of the files here:

https://drive.google.com/drive/folders/170OS_4pdLgw256vS3axLdsvFi3TiDrMG?ogsrc=32

For any problems accessing them I can gladly email them to you.

Once again, thank you.

Hello!

Any advise on this one would be very much appreciated.
Thank you!

Hello!

I think I may have found the reason behind the dump2vtk problem. Since I am very fond of making geo files andd importing them again and again in different esys codes, I forget that the ID generation of an esys code will not mind the existing particle IDs from the imported geo file. Because of this, I get 2 or three particles with the same IDs. I realize that the dump files arrange the particle positions in order according to the IDs and so only one of the duplicated IDs will be read resulting to an apparent loss of particles.

I hope this helps to anyone who makes the same clumsy mistake as I did.