CPEX 0046: Particle Data




  1. from Robert Bush: If I understand correctly, the information about particles is stored in DataArray_t entities under ParticleSolution_t. I think we need to indicate at a minimum the types of information that might be stored, or better yet, define any required variables, as well as optional information (and then allow user defined as well of course). For example, I assume that for each particle you would want to store its location (Particle_X, Particle_Y, Particle_Z) and perhaps Particle_Size.

    Another question – do you see the ParticleNumber as fixed as a solution evolves, or will it change with iterations? Related, do you envision allowing particle breakup or agglomeration, and how would this affect the structure, if at all. I can envision that ParticleSolution_t would represent an instantaneous status of particle locations, and accompanying software would compute travel, breakup, etc, and write a new ParticleSolution_t. In that case, do we store all of the ParticleSoluton_t nodes in time, or only keep the latest? Does this imply that we need to require a time or iteration stamp as a required variable? I guess that the rest of the file represents a time instance, so the ParticleSolution_t could also represent this instant in time. I am a little worried about the software implementation if the size of the node continually changes, but perhaps we have that sorted out now…

  2. From Marc Poinot: Yes, quite important topic we need to add into CGNS.
    But… maybe we already have a large part using the NODE elements?
    Is it complete?
    No, the missing items and questions are:
    The ParticleSolution_t is for a set of particles into a Zone_t, there is an implicit ordering of particles, what if the particle goes into another Zone_t?
    Can’t you use the NODE element type as a support for these particle identification? So that the FlowSolution_t would use the NODE index to store actual particle data?
    Moreover the coordinates would be available with existing SIDS in a nice consistent way.
    If you do not use the NODE element type, then maybe we would need an ParticleRange item to add an offset to the Particles’ indexes?
    Missing File Mapping
    Missing MLL API extension
    Missing an example showing for example some particles with some data such as speed, diameter…
    I cannot see how you would define a set of RED particles colliding with a set of GREEN particles?
    Do we have to add an enumerate to identify tracers vs actual physical particles?
    Is there any thoughts about relationships with chemical stuff? What about Mass exchange, Thermal radiation, Surface tension… ?
    Does it fit with CGNS ideas?
    Yes, the particles are required, however we must add this topic in a consistent way with existing data structures.
    Required doc changes present?
    No, except the SIDS description for ParticleSolution_t and ParticleCollisionModel_t which are ok.
    The variables names can be listed the same way the SIDS/Annex A presents variables.


Thomas Hauser


Scot Breitenfeld

Fix versions