[Go-essp-tech] DRS clarification

Thu Sep 9 13:24:54 MDT 2010

  Hi all,

If a coupled model is unchanged except to run with prescribed SST's, its 
name won't change.  A truly coupled model can't do AMIP runs; only when 
you replace its interactive ocean with prescribed SSTs do you get an 
AMIP run.  Thus, you will never have two different models to separate 
and there is no difficulty.

Hope this isn't too confusing.

best regards,
Karl

On 9/9/10 4:03 AM, martin.juckes at stfc.ac.uk wrote:
>
> Hello Karl,
>
> Sorry to raise another DRS issue – but following the last telco I’ve 
> been looking at the experiment setup in more detail in order to write 
> some code which will identify the “requested” data. Charlotte has also 
> shared with me some METAFOR discussions which, I think, concluded that 
> a coupled model which is run in atmosphere only mode will do so under 
> the same name.
>
> Thus, we may have data from model=ACCESS, expt=amip for both coupled 
> and atmosphere-only modes. As far as I can see, the only way these can 
> be separated in the DRS is by treating the atmosphere only version as 
> a physics perturbation. Would you agree with this interpretation, or 
> have I missed something?
>
> If this is the case, I think we should add a sentence or two to 
> explain this usage in the DRS document,
>
> Regards,
>
> Martin
>
> *From:* go-essp-tech-bounces at ucar.edu 
> [mailto:go-essp-tech-bounces at ucar.edu] *On Behalf Of 
> *stephen.pascoe at stfc.ac.uk
> *Sent:* 09 September 2010 11:24
> *To:* taylor13 at llnl.gov
> *Cc:* go-essp-tech at ucar.edu
> *Subject:* Re: [Go-essp-tech] ESGF Telco today 2010/09/07
>
> Hi Karl,
>
> I agree we don't have time to discuss this further.  If you can send 
> Martin and I the editable version of the DRS document we will 
> incorporate the changes necessary and feed it back to you to publish.  
> I think any further discussion needs to be done on a document that 
> brings together all the issues.
>
> Incidentally, there is a distinction between "variable_table" and 
> "variable/table".  The former implies a single DRS component with 2 
> parts and the second is 2 separate DRS components.  The DRS document 
> at the moment implies the former *in some circumstances*.  Looks like 
> we are settled on 2 components.
>
> I also want the DRS document to reflect the various different 
> encodings of DRS components.  There are several and many omit several 
> components:
>
>  1. NetCDF filename created by CMOR
>
>  2. NetCDF attributes created by CMOR
>
>  3. DRS directory structure
>
>  4. THREDDS publication-level dataset_id
>
>  5. TDS URLs
>
> Stephen.
>
> ---
>
> Stephen Pascoe  +44 (0)1235 445980
>
> British Atmospheric Data Centre
>
> Rutherford Appleton Laboratory
>
> ------------------------------------------------------------------------
>
> *From:* go-essp-tech-bounces at ucar.edu 
> [mailto:go-essp-tech-bounces at ucar.edu] *On Behalf Of *Karl Taylor
> *Sent:* 08 September 2010 20:20
> *To:* go-essp-tech at ucar.edu
> *Subject:* Re: [Go-essp-tech] ESGF Telco today 2010/09/07
>
> Dear all,
>
> We probably shouldn't spend any more time on this.   Either proposed 
> solution seems to solve the probelm, so maybe we go with "group 
> think", unless someone can point out some practical implication that 
> that choice will make more work for someone (especially the users of 
> the archive).
>
> best regards,
> Karl
>
> On 9/8/10 10:34 AM, Gavin M. Bell wrote:
>
> Suggestion....
>
> Hi Stephen,
>
> Can you please make the second to last token, namely: 
> <variable>_<table>, be like the other tokens in the taxonomy.  
> Specifically make it <variable>/<table>.  When parsing this, it makes 
> it a bit difficult to look for this new delimiter.  It complicates 
> things a bit.  Does it also mean that "_" are not allowed as a 
> character in any of the other bits of the taxonomy.  The regex becomes 
> a real pain and "regular" parsing is even worse.  It would make 
> everything quite a bit simpler if it was like the others. i.e.
>
> cmip5/<product>/<institution>/<model>/<experiment>/<frequency>/<realm>/<ensemble>/<version>/<variable>/<table>/<file>
>
> Furthermore, is this structure saying that we are always going to be 
> using "cmip5" as the root of this taxonomy?
>
> Please let me know your thoughts.  If you can accommodate this it 
> would be great!
>
> On 9/7/10 3:17 AM, stephen.pascoe at stfc.ac.uk 
> <mailto:stephen.pascoe at stfc.ac.uk> wrote:
>
> Today we plan to discuss the DRS directory structure and prerequisites 
> for starting replication tests between DKRZ and BADC.  I am putting 
> together an agenda at the link below, it's still evolving but comments 
> welcome.  Telephone details are also below.
>
> Thanks,
>
> Stephen
>
> **Agenda: 
> **http://***proj.badc.rl.ac.uk/go-essp/wiki/CMIP5/Meetings/telco100907
>
> **Telco details:**
>
> 16:00 BST, 17:00 CEST, 8:00 PDT, 9:00 MDT, 11:00 EDT.
>
> +01 (925) 424-8105 access code 305757#
>
> ---
>
> Stephen Pascoe  +44 (0)1235 445980
>
> British Atmospheric Data Centre
>
> Rutherford Appleton Laboratory
>
> -- 
> Scanned by iCritical.
>
>
>
> -- 
> Gavin M. Bell
> Lawrence Livermore National Labs
> --
>   
>   "Never mistake a clear view for a short distance."
>                       -Paul Saffo
>   
> (GPG Key -http://**rainbow.llnl.gov/dist/keys/gavin.asc)
>   
>   A796 CE39 9C31 68A4 52A7  1F6B 66B7 B250 21D5 6D3E
>
> -- 
> Scanned by iCritical.
>
>
> -- 
> Scanned by iCritical.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ucar.edu/pipermail/go-essp-tech/attachments/20100909/76dfc5bf/attachment-0001.html 