On 11.11.2010 14:02, Bruce Wright posted on behalf of Dave Thomson: > In response to Chris Barker (2/Nov): We certainly vary the time > step between particles in our models but usually as a sub-step. > I agree there is no strong need to be able to store the substeps.
I also think this is an acceptable "limitation" with our models. We sometimes have multiple time steps when multiple (sub-)models run in parallel (and interact with each other), but this isn't necessarily "sub-stepping". In any of these cases, the _output_ time step (which is what we would store in a netCDF file) is not necessarily the same as the models' time steps. (Eg., we let the model calculate at 5 minute intervals, but we might choose to record the results maybe only once every hour.) It would be great if a CF data set would support multiple independent time scales in the same file, because then we could archive results of multiple models together when they actually have been running together. (They are dependent on each other.) Common dimensions, variables and meta information could then be easily shared and consistent. However, it is not critical if we would have to resort to one netCDF file per time scale. What would provide a "critical" limitation for us, however, would be a requirement that the time steps have a constant interval between them (time step length == constant). I have cases here were they do vary. > Response to Jon Caron (4/Nov, later post): 20K particles is very > small for us. 4M is not uncommon and this is likely to increase > in the future. This should definitely be taken into consideration in the "design" of CF. We generally experience that the number of particles is pushed to the limit of what the user can be patient enough to wait for given the available machine resources at any specific point in time. (The model is often run on regular desktop or laptop computers.) Since 4M and beyond is already indicated, there's at least no reason to accept a 32-bit limitation in indexing of a CF-conformant file. > Response to Ben Hetland (4/Nov): "if one wants to jump directly to > particle p at timestep t, then a simple prop(index(t)+p) should do the > lookup" assumes that all particles are stored at each time step. In > practice for a long run with continuously emitting sources, particles > are created and destroyed. Yes, this is a good point! I was implicitly assuming that 'p' would be the index within the range of the stored number of particles at the given time 't' only, but realize this might not always hold true when referring to a "particle p" in general. We also have particles created and destroyed like you mention, but then the index slots in the arrays are often reused. I.e., we cannot in general say that particle p at time t1 is the same as particle p at time t2. Thanks for your comments! -- -+-Ben-+- Opinions expressed are my own, not necessarily those of my employer. _______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata