Custom Query (116 matches)

I encounter the following problem : my run freezes when I define bounds lon and bounds lat via xios_set_domain_attr function (no problem without bounds definition). Then, no problem when I put in my iodef.xml :

<variable id="optimal_buffer_size" type="string">performance</variable> <variable id="buffer_size_factor" type="double">2.0</variable> <variable id="min_buffer_size" type="int">10000000</variable>

It looks like bad estimation of buffer size...

Salut Rémi,

J'ai investigué un peu, et le problème est assez sérieux. Tout se passe dans la routine CTemporalFilter::apply

  CDataPacketPtr CTemporalFilter::apply(std::vector<CDataPacketPtr> data)
  {
    CDataPacketPtr packet;

    if (data[0]->status != CDataPacket::END_OF_STREAM)
    {
      const bool usePacket = isOnceOperation ? isFirstOperation : (data[0]->date >= nextSamplingDate);
      if (usePacket)
      {
        if (!tmpData.numElements())
          tmpData.resize(data[0]->data.numElements());

        (*functor)(data[0]->data);

        nextSamplingDate = nextSamplingDate + samplingFreq;
      }

      const bool outputResult = isOnceOperation ? isFirstOperation : (data[0]->date + samplingFreq > nextOperationDate);
      if (outputResult)
      {
        functor->final();

        packet = CDataPacketPtr(new CDataPacket);
        packet->date = data[0]->date;
        packet->timestamp = data[0]->timestamp;
        packet->status = data[0]->status;
        packet->data.resize(tmpData.numElements());
        packet->data = tmpData;

        isFirstOperation = false;
        nextOperationDate = nextOperationDate + opFreq;
      }
    }

    return packet;
  }

Lors du test :

const bool outputResult = (data[0]->date + samplingFreq > nextOperationDate);

Dans notre cas, on a freq_op = 2 ts, timestep=1h et freq_ouput=1 mo. Le flux de sortie l'opérateur temporel sera généré le 30/01 à 23 h car 30/01 23:00 + 2h > 01/02 00:00. Donc le serveur reçoit un packet à la date : 30/01 23:00 et en déduit que le prochain flux valide sera le 30/02 23:00 (+1 mo) ce qui pose un problème dans le cas Grégorien et met un bazar pas possible.

En fait il faudrait que le flux soit envoyé au serveur le 01/02 00:00, mais ce flux ne pourra pas être déclenché à ce moment là puisqu'on envoie tous les 2 pas de temps. C'est un peu Cornélien...

Tu peux aller voir sur ADA (tu connais ?) sur lequel j'ai un cas test à disposition.

/workgpfs/rech/psl/rpsl565/DEBUG_NEMO

Tu peux jouer avec le freq_op pour voir les différence entre 1 ts et 2ts (ou plus)

Fais moi part de ton sentiment sur la question.

Merci

Yann

le flux de sortie est généré correctment mais il n'est pas à la bonne date, car il va être généré

Global/local attributes defined for a file are not reported in Time Series files. Example :

<file name="file1" output_freq="1d" timeseries="both" >

<variable id="project_id" type="string" > CMIP6/CMIP6 </variable> <field field_ref="soce" name="soce">

...

The file "file1.nc" contains :project_id = "CMIP6/CMIP6" ; whereas in TS file "file1_soce.nc" there is no : :project_id = "CMIP6/CMIP6" ;