<html>
  <head>
    <meta content="text/html; charset=ISO-8859-15"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    I meant indeed the data providers, AFAIK some typical
    post-processing corrections are not generating new tracking_ids. But
    I might be wrong.<br>
    <br>
    I think the best place for this to be checked would be in the
    publisher itself. I assume the tracking id is a column attribute in
    a DB table. If that's the case it might have already a unique
    constraint or it could be added easily, but that is something Bob
    certainly knows better.<br>
    <br>
    Thanks,<br>
    Estani<br>
    Am 25.09.2011 19:25, schrieb Karl Taylor:
    <blockquote cite="mid:4E7F6413.1010203@llnl.gov" type="cite">
      <meta content="text/html; charset=ISO-8859-15"
        http-equiv="Content-Type">
      <font face="Times New Roman">Hi Estani,<br>
        <br>
        I'm not advocating using the tracking_id to test whether two
        files are identical.  I'm suggesting that for most users, they
        will be able to use it to determine whether they have the latest
        version of a particular file, as opposed to some earlier
        version.  It's true that you can modify a file without changing
        the tracking_id, but I'm pretty sure all but a tiny number of
        users will download the files and never modify them.  Whether or
        not a user alters files, new files available from the CMIP5
        archive will have tracking_ids that the user doesn't have
        locally, so if they are interested, they can download the new
        files.<br>
        <br>
        The above assumes that data *providers* take care to generate a
        new tracking_id when they generate a file containing new data. 
        Is this a risky assumption?  Couldn't the CMIP5 QA procedure
        check whether a file has the same tracking_id as any other file
        in the system?<br>
        <br>
        best regards,<br>
        Karl<br>
        <br>
      </font>On 9/25/11 2:49 AM, Estanislao Gonzalez wrote:
      <blockquote cite="mid:4E7EF93E.8000808@dkrz.de" type="cite">
        <meta content="text/html; charset=ISO-8859-15"
          http-equiv="Content-Type">
        I recall a problem that when altering the file with some tools
        (cdo?) the tracking id wasn't automatically changed.<br>
        Are we sure that the same tracking id point to the same file
        now? <br>
        Is the previous not a problem anymore?<br>
        <br>
        Thanks,<br>
        Estani<br>
        Am 24.09.2011 18:17, schrieb Karl Taylor:
        <blockquote cite="mid:4E7E027D.50405@llnl.gov" type="cite">
          <meta content="text/html; charset=ISO-8859-15"
            http-equiv="Content-Type">
          <font face="Times New Roman">Dear all,<br>
            <br>
            Concerning:<br>
          </font><br>
          On 9/24/11 4:35 AM, Estanislao Gonzalez wrote:
          <blockquote cite="mid:4E7DC078.5000700@dkrz.de" type="cite">
            <pre wrap="">2) checksums
They are the only reference to the outside that a data node give of the 
changes a file suffered from one version to another, i.e. for 
replication we use that information to retrieve only files that change 
from one version to another. The same principle could be applied for 
tools designed for end users.
</pre>
          </blockquote>
          <br>
          without disputing that checksums should be mandatory, I want
          to point out that a user who has lost the checksum associated
          with a file he has downloaded shouldn't have to recompute the
          checksum to determine whether his file is a copy of a file
          residing at the datanode.  Recall that recorded in each netCDF
          file is a unique tracking_id, which I'm almost positive is
          also in the thredds catalog.  It will certainly be quicker for
          the user to read the tracking_id and then check whether it
          matches the latest version.  I think we want to maintain
          tracking_id as an option for checking whether new files exist
          in a new version.<br>
          <br>
          best regards,<br>
          Karl<br>
        </blockquote>
        <br>
        <br>
        <pre class="moz-signature" cols="72">-- 
Estanislao Gonzalez

Max-Planck-Institut für Meteorologie (MPI-M)
Deutsches Klimarechenzentrum (DKRZ) - German Climate Computing Centre
Room 108 - Bundesstrasse 45a, D-20146 Hamburg, Germany

Phone:   +49 (40) 46 00 94-126
E-Mail:  <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:gonzalez@dkrz.de">gonzalez@dkrz.de</a> </pre>
      </blockquote>
    </blockquote>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 
Estanislao Gonzalez

Max-Planck-Institut für Meteorologie (MPI-M)
Deutsches Klimarechenzentrum (DKRZ) - German Climate Computing Centre
Room 108 - Bundesstrasse 45a, D-20146 Hamburg, Germany

Phone:   +49 (40) 46 00 94-126
E-Mail:  <a class="moz-txt-link-abbreviated" href="mailto:gonzalez@dkrz.de">gonzalez@dkrz.de</a> </pre>
  </body>
</html>