Changes between Version 1 and Version 2 of NumSimFeedback


Ignore:
Timestamp:
06/03/06 09:44:34 (14 years ago)
Author:
lawrence
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • NumSimFeedback

    v1 v2  
    1111Response 1: 
    1212 
    13  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''') 
    14  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''') 
     13 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''') 
     14 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''') 
    1515 
    1616Response 2: 
    1717 
    18  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''') 
    19  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''') 
    20  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'''). 
    21  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 ''') 
    22  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''') 
    23  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 
    24  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''') 
    25  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''') 
    26  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''') 
     18 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''') 
     19 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''') 
     20 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'''). 
     21 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 ''') 
     22 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''') 
     23 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 
     24 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''') 
     25 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''') 
     26 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''')