C James Elliott writes:
> In regards to the recent spate of concerns of data format, it
> might be helpful to include some views from generators of data
> whose structure evolves in time. I will sketch their structure.
> The first is a particle-in-cell code that describes accelerator
> configurations. When the particles are first populating the region
> near the cathode of the injector, they are stored in arrays of
> small size. During the parturation, the arrays grow in size.
> Later when some of the stragglers strike the wall and desist, the
> array size diminishes. A second such example is the finite element
> structure of the code TOSCA that is used for calculations of magnetic
> fields. That structure is of the extrusion variety. The (x,y)
> grid characteristics evolve with extrusion parameter z. A third
> example is in hydro codes where because of scale size changes,
> remeshing with more grid points is required.
Jim,
I'm not sure what "parturation" is, but the size of particle arrays
stored in netcdf format need not change even if the number of
particles change. You need to use the unlimited variable for all the
particles for all time. Just add a variable to specify the time and
then to process the data simply get all the particle "batches" for
each time. The final batch will be incomplete which could be handled
by a variable which contains the number of particles in a batch. I
see no need for adding variables for each time step (yuck!).
>
> Mike Jones solved the variable dimension problem by what I believe
> is an upwardly compatable modification. He simply increased the
> allowable number of arrays. He assigned new variable names to
> each time step, e.g. (x1,y1), (x2,y2),...(x777,y777). Note, however,
> netCDF is currently used only in the first problem. Earlier graphics
> packages were established for hydro and the proliferation of results
> is not always desirable. In the TOSCA case data archival is a major
> focus, but global
> data exchange is not a driving concern.
>
I don't understand the meaning of "proliferation of results".
There is a simple way to get finite element code data stored under
netcdf with simple conventions on the attributes. It would be nice to
get some "standard" extensions to attributes to allow for unstructured
grids to be stored. Such an extension is used by IBM's Data Explorer,
I believe.
David Forslund
Advanced Computing Laboratory
MS B287
Los Alamos National Laboratory
Los Alamos, NM 87545
Voice:(505) 665-1907
FAX: (505) 665-4939
EMAIL: dwf@xxxxxxxx
