Hi,
I implemented my own Particle-In-Cell (PIC) simulator and I would like to use VAPOR to visualize the particles along with the Eulerian wind fields. The current data collection particles reader is very preliminary. I’m wondering what’s the plan for enhancing the particle reader? If I would like to implement my own particle reader, what are the rules I should stick to? The page on creating a Data Reader is empty now.
Thanks,
Cheng
Hi,
Right now we have plans for the DCP renderer to draw more complex glyphs for the particles. Could you elaborate on what you mean when you say that it’s preliminary? If there’s a deficiency that you think we could improve, please let us know.
If I would like to implement my own particle reader, what are the rules I should stick to? The page on creating a Data Reader is empty now.
This gets pretty complex which is why the “coming soon” label is on this page. I would recommend trying to use the DCP format before this, and we may be able to address issues that you raise. @clyne @StasJ thoughts?
Hi,
Thanks for the prompt reply. Yes, the DCP format is a little bit inconvenient now. The major problem I have with is that “If the number of particles varies between timesteps, every timestep must be in its own file since each NetCDF file can only define a single length for a dimension.”
The number of particles will change during my simulation. It becomes inconvenient to store thousands of output files if each timestep is stored in one single file. Also, does DCP support particle ID so as to track individual particles?
Thanks,
Cheng
@stasj will need to comment on the limitations of the current DCP format and what might be involved in supporting varying numbers of particles.
If addressing these shortcomings within the DCP is not practical because of limitations with NetCDF, a bespoke format and associated reader is certainly a possibility. Implementing a new reader is largely a matter of deriving from the “DC” class. The existing DC* classes are good exemplars, the most relevant being the DCP class. Before doing down this road it would be good to get input from @stasj about any barriers that might occur supporting the missing features that you desire. Hopefully, all that is needed is a more general file format, not changes to internal data structures, etc.
The limitation of one file per timestep if the number of particles varies is within the NetCDF format on which DCP is built rather than DCP itself. This can technically be worked around however at that point you would just be storing raw data in NetCDF unrelated to the NetCDF format and you may be better off using a custom binary format like John suggested.
Your FS should have no problem handling thousands of files but if it is an issue, you can store all your time steps in a tar ball and use archivemount to access the files.
Vapor does not support integer data at the moment so it would be unable to support a form of particle ID without modification.