Ongoing work

Factorisation of altimetry updates

Please refer to ticket 1484188.

This section summarise which altimetry update snippets are found where in the code and when they are invoked. This aims at factoring them out and rationalise altimetry update around as few code variants and semantic invariants as possible.

Edition of topography elements

In the classes TYCourbeNiveauEditor, TYEmpriseEditor, TYPlanEauEditor we find the same altimetry update pattern.

In the slotKeyPressed() methods of the tree classes:

((TYSiteModelerFrame*)_pModeler)->getSite()->updateAltimetrie();
((TYSiteModelerFrame*)_pModeler)->getSite()->updateAltiInfra();
((TYSiteModelerFrame*)_pModeler)->getSite()->updateGraphic();
_pInteractor->updateGL(); // ??? to be excluded

In the TYCourbeNiveauEditor::endCourbeNiveau() and in the TYPlanEauEditor::endPlanEau() (but not in the TYEmpriseEditor::endEmprise()):

// On altimetrise aussi le sous-site (si s'en est un !)
if (!pSite->getRoot()) { pSite->updateAltimetrie(true); }

// On met a jour l'altimetrie globale du site
TYProjet* pProjet = getTYApp()->getCurProjet();
if (pProjet)
{
    pProjet->getSite()->updateAltimetrie(true);
    pProjet->getSite()->updateAltiInfra(true);
    pProjet->updateAltiRecepteurs();
    pProjet->getSite()->getTopographie()->updateGraphicTree();
}

In contrast in TYSolEditor::endSol() methods:

for (unsigned int i = 0; i < tabPts.size(); i++)
{
    tabPts[i]._z = 0.0;
    pSite->getTopographie()->getAltimetrie()->updateAltitude(tabPts[i]);
}

Warning

The main display problem for ground material is likely to come from here !!!

With receptors update

In TYPickEditor::showPopupMenu():

// On altimetrise aussi le sous-site (si s'en est un !)
if (pSiteParent && !pSiteParent->getRoot()) { pSiteParent->updateAltimetrie(true); }

// On met a jour l'altimetrie globale du site
TYProjet* pProjet = getTYApp()->getCurProjet();
if (pProjet)
{
    pProjet->getSite()->updateAltimetrie(true);
    pProjet->getSite()->updateAltiInfra(true);
    pProjet->updateAltiRecepteurs();

    pProjet->getSite()->getTopographie()->updateGraphicTree();
}

is very similar to (in TYSiteFrame::contextMenuEvent()):

if (pSiteParent)   // Non NULL uniquement pour les courbes de niveau et les plan d'eau
{
    // On altimetrise aussi le sous-site (si s'en est un !)
    // WIP
    if (!pSiteParent->getRoot()) { pSiteParent->updateAltimetrie(true); }

    // On met a jour l'altimetrie globale du site
    TYProjet* pProjet = getTYApp()->getCurProjet();
    if (pProjet)
    {
        pProjet->getSite()->updateAltimetrie(true);
        pProjet->getSite()->updateAltiInfra(true);
        pProjet->updateAltiRecepteurs();

        pProjet->getSite()->getTopographie()->updateGraphicTree();
    }
}

Only updateAltimetry()

In TYOpenElementDialog::openElement():

// Directement site courant, la "place" etant libre
LPTYSiteNode pSite = TYSiteNode::safeDownCast(pElt);
if (pSite)
{
    getTYApp()->setCurSiteNode(pSite);
    pSite->updateAltimetrie();
}

The most complex one

In TYSiteNode::update():

// Mise a jour de l'altimetrie du site principal
updateAltimetrie(force);

// Altimetrisation des infrastructures du site
updateAltiInfra(force);

// Mise a jour de l'acoustique des elements du site
updateAcoustique(force);

// Et celle des sites inclus
for (unsigned short i = 0; i < _listSiteNode.size(); i++)
{
    TYSiteNode* pSite = TYSiteNode::safeDownCast(_listSiteNode[i]->getElement());

    if (pSite && pSite->isInCurrentCalcul()) { pSite->update(force); }
}

// Si le site est dans un projet, on altimétrise les points de controle
if (_pProjet)
{
    TYCalcul* pCalcul = _pProjet->getCurrentCalcul()._pObj;
    assert(pCalcul);
    pCalcul->updateAltiRecepteurs();
}

1484188

https://extranet.logilab.fr/ticket/1484188

TODO

Transformation of the scene and Triangulation

To take into account the impact of the weather (temperature and wind gradient) on the propagation of the rays, tympan launches 20 curved rays from one of the sources. The trajectory of those curved rays is computed using a 4th order Runge-Kutta approximation. Those curved rays are used to build a transformation sheet (see below) which reflects how the weather impacts the altitude of the rays.

Left:Transformation sheet, Right: Transformed scene

The triangulation algorithm used to build the transformation sheet only uses 2D coordinates and ignores the z-axis. As we can see on the figure below, when the gradients are too high the curved rays wrap onto themselves modifying the topological order of vertices in the x,y 2D plane. Since the triangulation ignores the z-axis it connects vertices that are very close in the x,y 2D plane but far apart on the z-axis. This produces a very chaotic transformation sheet. It can go as far as creating holes in the sheet which are responsible for the weird rays going through the ground that have been occasionally produced by the simulation.

Curved rays and their corresponding transformation sheet

The approximation of the weather’s impact also presents the problem of only being valid for rays launched from a source close to the one used for producing the curved rays used as a frame for the transformation sheet. As we can see on the figure below, the transformation results in a deep hole in the scene. Rays launched from outside this hole will follow a wrong trajectory not reflecting the impact of the weather.

Simulation summary and diagnostic

So far the statistics on the rays (number of valid rays, invalid rays, number of rays invalidated by each selectors etc…) have been hard coded and which is not flexible. It could be useful to have an object regrouping these kind of statistics and capable of producing a report.

Displaying the rays processed by the ray tracing algorithm with the possibility of selecting them according to some criterion (src/rcpt, valid/invalid, which selector invalidated, number of events etc…) could be helpful when investigating the behavior of the simulation. Moreover, some comments could be attached to the events of the rays to give information on the ray’s journey.

The ids of the sources and receptors in the scene are different from the ones returned by the results of the simulation. This makes the analysis of the results unnecessarily difficult.

Performances

The performance tests have shown that most of the computation time is spent computing intersections. It might be worth investigating if the intersection methods of the various shapes can be optimized.

The page http://www.realtimerendering.com/intersections.html contains a lot of resources on this subject.

Besides, both the accelerators and the ray tracing algorithm could be parallelized to improve the performances.

Co-Planarity Selector

Finish implementing the co-planarity selector.

This selector rejects a ray if the face if its ith event is co-planar with the face of the ith event of any of the other already selected rays that have the same event signature.

Tests Anime3D

The following modules lack unit tests:

• DefaultCurvrayEngine

• Geometry_modifier

• Lancer

• TYAnime3DAcousticMode

• TYAnime3DAcousticPathFinder

• TYAnime3DConversionTools

• TYAnime3DRayTracerSolverAdapter

• TYAnime3DSolver

Linear Algebra/Geometric computations:

The geometric computations in 3D space are done with an ad-hoc library. Although no critical bug has been discovered through the unit tests, it would be better for Tympan to rely on one of the proven linear algebra/geometric computation libraries.

Here is a list of some of the most popular libraries:

Library	Advantages	Downsides
GMTL	Simple API Fast	Focused on graphics rendering
Eigen2/3	Clean API Fast	No graphics rendering
IMSL	Very Fast	No geometric specific methods Not free
NT2		Not as fast as the others Poorly maintened/documented
LAPACK	Stable and proven	Poor API

More information on this topic can be found at the following adresse:

• https://en.wikipedia.org/wiki/Comparison_of_linear_algebra_libraries

• https://stackoverflow.com/questions/1380371/what-are-the-most-widely-used-c-vector-matrix-math-linear-algebra-libraries-a

• https://scicomp.stackexchange.com/questions/351/recommendations-for-a-usable-fast-c-matrix-library

Miscellaneous:

The purpose and inner workings of the path difference option is still a mystery. It is used to invalidate some intersections, but the reason behind it are not documented and the code does not help infer the physical problem it tries to solve nor the theory it is based on. It should be studied further or simply removed from the code.

The DiffractionPathSelector also lacks theoretical motivation. Although its code is clear enough to understand what it does, we still do not know what its purpose is. Besides, it is redundant with the constraints applied to intersections when they are validated (pathDiffValidationForReflection and pathDiffValidationForDiffraction methods of ValidRay), therefore rays meeting the rejection conditions of this selector should have been eliminated before reaching the selector manager.

The DiffractionAngleSelector presents the same curiosity.The diffracted rays are already filtered at the generation step with the same conditions. Therefore, as for the DiffractionPathSelector, its unclear why the DiffractionAngleSelector finds any ray to reject.

Documentation’s TODOs

This section lists all ..todo:: markers through the developers’ documentation.

Todo

test with both altimetry and buildings

(The original entry is located in /home/docs/checkouts/readthedocs.org/user_builds/codetympan/checkouts/latest/doc/data_test/geometry/index.rst, line 41.)

Todo

Double check when the mesh refine operation appears

(The original entry is located in /home/docs/checkouts/readthedocs.org/user_builds/codetympan/checkouts/latest/doc/meshing.rst, line 277.)

Todo

document me once written

(The original entry is located in /home/docs/checkouts/readthedocs.org/user_builds/codetympan/checkouts/latest/doc/meshing.rst, line 286.)

Todo

Best practices. How can you do.

(The original entry is located in /home/docs/checkouts/readthedocs.org/user_builds/codetympan/checkouts/latest/doc/testing.rst, line 108.)

Todo

Keep the branches name and policies up-to-date.

(The original entry is located in /home/docs/checkouts/readthedocs.org/user_builds/codetympan/checkouts/latest/doc/tools.rst, line 33.)