Custom Query (116 matches)

Attached files do fix it

In domain.cpp, for the case of a rectilinear domain, completeLonLatClient uses lonvalue_1D with an implicit assumption that the distribution also is recti-linear (i.e. that each MPI tasks does process a rectangle in the lat-lon space)

This does not apply when data_dim=1 and the distribution follows another scheme.

The attached version of domain.cpp, domain_new.cpp, is a proposal for an alternate convention in that case : lonvalue_1d and latvalue_1d are then interpreted as providing arrays which are parallel to the data arrays (which is more intuitive in that data_dim=1 case)

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é