wiki:NumSimFeedback

Version 1 (modified by lawrence, 14 years ago) (diff)

--

This page summarises email feedback on NumSim.

Feedback yet to be dealt with

None.

Feedback that has been dealt with

Responses to responses are shown in bold.

Response 1:

1 My main concern is that ModelType? and ModelConfiguration? overlap in an unclear way, so I would replace them with an ExperimentCategory? and ModelComponents?. (Consequential changes definite in V006) 1 I also think that ModelComponents? such as "Atmosphere" need to be complex types, so that the software searching can distinguish between hydrostatic/non-hydrostatic and wet/dry, for example. (Consequential changes maybe in V007)

Response 2:

1 What is the scope of NumSim (and is NumSim the best name?). We originally designed it thinking of trying to capture a fairly broad class off earth system models. Should we try and make sure it can also cover a description of numerical processing code that might be applied to geophysical data? For instance could it (should it, would people try to use it...) to describe say satellite retrieval algorithms? We already allow data assimilation products. I don't think we have to necessarily deal with this now but do we want this to be a future possibility? (Scope now discussed in documentation) 1 Something related to this that I have wondered about for a while is does this carry over to other fields (astrophysics models, abinitio chemistry models). Again this isn't something we have to deal with now. The only place where this matters now is in the name. Our current scope is Earth System simulations - not all numerical simulations. So I'd be inclined to change the name (NumESSim?) (Don't agree, see scope in docs) 1 If we want to allow for possible future application elsewhere should 'model' become 'simulator' and 'boundaryConditions' become 'simulatorInput'? (Boundary conditions for simulations make more sense in terms of differential equations. The point about model is well made, but feels repugnant. Postponed to discuss in V008). 1 You have a comment on the wiki about turning initial conditions into attributes or subelements of the model. I don't understand why you want to do this? I would have thought the better thing would be to do a way with initial condition and turn it into a special case of boundary condition (or simulatorInput). (Still under discussion but unlikely ) 1 I like the idea of including the EnsembleStatistics? - its going to be important for things like cp.net and QUMP data going to UKCIP. That said do we want to introduce it now given we haven't attached anything to it (I don't think). Shouldn't it be delayed until a later version? For one thing should some of the ensemble statistic information sit with the data itself - this is a pdf of summer time uk temperatures is a description of the data - not the simulation/simulator. Or have I misunderstood what you want to do with EnsembleStatistics??(There are two sorts of statistics, this argument is to be used where. for example, something that looks like an integration is in fact a climatology aka ensemble average, but the point is well made that other classes of data products should be described in the data description not this section. Explanatory text added to docs) 1 Can we allow more than one ensembleType? Rather than just use EnsembleType:GrandEnsemble? (*Yes, in V006*) I always thought it was better to be explicit and say EnsembleType: InitialCondition, EnsembleType: PerturbedPhysics, EnsembleType: MultipleForcing 1 Can you expand the sentence at the bottom of 'Schema Description'. I don't really understand it. As you know this is so mething I've had concerns over in previous versions.(fixed in docs) 1 As you note there may be standard ways of referencing external uri's especially in the case where they are dictionaries. (should !NamespaceURI be an attribute for instance - this looks a bit more like what GML does with CRS doesn't it?) (in hand) 1 The version I have doesn't expand Component - either in the doc or the schema. The example suggests we can now nest components - which is great. My only real concern here is how different model and component need to be. (V005 schema certainly does have expandable components, but the doc is at fault. Fixed)