Custom Query (115 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (73 - 75 of 115)

Ticket Resolution Summary Owner Reporter
#127 fixed Pb with index with indexed_output on 3D fields rlacroix aclsce
Description

Indices of points of compressed 3D fields by using "indexed_output" field attribute are not correct :

int grid_T_moor_3D_points(grid_T_moor_3D_points) ;

grid_T_moor_3D_points:compress = "deptht y x" ;

grid_T_moor_3D_points = 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14,

These values are not correct. Note that indices are correct with 2D fields.

#45 fixed problem including a file containing a context in iodef.xml ymipsl jgipsl
Description

Following exemple does not work :

iodef.xml :

<?xml version="1.0"?>
<simulation>
  <context id="xios">
    <variable_definition>
      <variable_group id="buffer">
            buffer_size = 80000000
            buffer_server_factor_size = 2
         </variable_group>
      <variable_group id="parameters">
        <variable id="using_server" type="boolean">false</variable>
        <variable id="info_level" type="int">0</variable>
      </variable_group>
    </variable_definition>
  </context>

  <context src=".context_orchidee.xml"/>

</simulation>

context_orchidee.xml :

  <context id="orchidee">
    <field_definition src="./field_def_orchidee.xml"/>
    <file_definition src="./file_def_orchidee.xml"/>

    <domain_definition>
      <domain id="domain_landpoints"/>
    </domain_definition>

    <axis_definition>
      <!-- Vertical axis and extra dimensions in sechiba -->
      <axis id="veget" standard_name="model_level_number" long_name="Vegetation types" unit="1"/>
      <axis id="laiax" standard_name="model_level_number" long_name="Nb LAI" unit="1"/>
      <axis id="solth" standard_name="model_level_number" long_name="Soil levels" unit="m"/>
      <axis id="soiltyp" standard_name="model_level_number" long_name="Soil types" unit="1"/>
      <axis id="nobio" standard_name="model_level_number" long_name="Other surface types" unit="1"/>
      <axis id="albtyp" standard_name="model_level_number" long_name="Albedo types" unit="1"/>
      <axis id="solay" standard_name="model_level_number" long_name="Hydrol soil levels" unit="m"/>
      <!-- Vertical axis and extra dimensions in stomate -->
      <axis id="PFT" standard_name="model_level_number" long_name="Plant functional type" unit="1"/>
      <axis id="P10" standard_name="model_level_number" long_name="Pool 10 years" unit="1"/>
      <axis id="P100" standard_name="model_level_number" long_name="Pool 100 years" unit="1"/>
      <axis id="P11" standard_name="model_level_number" long_name="Pool 10 years + 1" unit="1"/>
      <axis id="P101" standard_name="model_level_number" long_name="Pool 100 years + 1" unit="1"/>
    </axis_definition>
  </context>

The same example works if putting the contents from the file context_orchidee.xml directly into iodef.xml instead of including the file by src.

#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é

Note: See TracQuery for help on using queries.