Custom Query (116 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (25 - 27 of 116)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Ticket Resolution Summary Owner Reporter
#84 fixed abort in XIOS cause dead lock with MPI mhnguyen ymipsl
Description

When exception is launch from XIOS, it terminates with abort() call. It may be a mistake with MPI run under some environment since de MPI library doesn't catch the abort and transfer the information to the other MPI processes.

Try to replace abort() in exception.cpp by MPI_Abort

#93 fixed problem when freq_op differrent of 1ts rlacroix ymipsl
Description

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é

#105 fixed Implement grid type gaussian for interpolation ymipsl ymipsl
Description

Actually gaussian grid are considered like unstructured, ie edge are geodesic line (a great circle on the sphere). When interpolation is performed, interpolation error is increasing near the pole. Gaussian grid must specifie to the mapper that vertex on same latitude are linked with a small circle (like regular lon lat grid)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Note: See TracQuery for help on using queries.